Web accessibility is a hot topic nowadays. Many articles have been written about the topic, so that there’s no shortage of information should you want to design an accessible website that at least aims to be usable by all, regardless of any disabilities. This, after all, is a good thing, since if public buildings are mandated to be accessible by the disabled, shouldn’t public websites be as well?

Necessarily accessible

In fact, many governments, both at the upper and lower levels, have been mandating accessibility for public websites. In the United States, there’s Section 508, and in Europe, they’re working on making it mandatory. Here in Canada, I don’t think there’s any federal law on it, though I might be mistaken. However, in Ontario, I believe the ODA applies, or will apply, to most institutions that receive government funding, including universities, which is all the more reason for them to adopt standards.

Doing it right

Designing an accessible website is not particularly hard, but it does take some extra planning. Not being a public institution, I’ll admit I haven’t taken accessibility to heart, as there are many things I could do to improve it. Thankfully, there are plenty of resources out there. The Web Accessibility Initiative is a good starting point, and the Watchfire WebXACT tool will help evaluate your site for accessibility. My site fails horribly right now, however, it wouldn’t be too hard to fix this, but I just haven’t bothered because I’m not aiming to reach everyone; a weak excuse, but an excuse nonetheless. With a good platform like WordPress, site-wide changes aren’t hard to implement, and structured blogging, a sort of microformat, could help even more.

In essence, making an accessible website is closely related to making your site semantically sound. The two aren’t exactly the same, but if you use semantic markup and get used to it, making things accessible becomes a lot easier. Every web designer (and also web developers) should be aware of this, and take these best practices to heart. If I were to design a site for a company or any institution that aimed to reach out to as many people as possible, I would definitely factor in accessibility and semantically sound markup from the beginning, despite the extra planning it would take. Any time you spent in during this stage would more than make up for any extra time you’d have to spend converting a poorly-designed site to be accessible.

The other side of accessibility

However, one aspect I think is often missed out on is the other side of web accessibility; what I mean by this is that not only must content be accessible, but the ability to produce content should also be accessible to all, regardless of their technical knowledge about web standards.

In the past, this was almost impossible. Before there were WYSIWYG editors, people had to write HTML by hand, something not everyone can do. Even when people did know how to use HTML, it was not always used correctly, and rarely with accessibility in mind. The dawn of WYSIWYG editors did not improve this at all, as most of them tended to produce a tag soup of HTML that was rarely valid, much less accessible. (Versions of Microsoft Frontpage are perhaps a good example.)

Thus, the web turned into a jumble of unsound pages and examples of the ineffective use of HTML, and later, XHTML. I don’t believe this was the fundamental fault of the authors, as I don’t believe everyone who wants to publish content on the web should have to understand all the details of XHTML – after all, does the author of a book usually have to understand all the intricate details of book publishing? I believe the fault lay with the lack of an easy-to-use editor that could produce structurally sound markup.

Thankfully, things are getting better. Ever since web accessibility standards were clearly defined, there have been movements to make publishing well marked-up content easier on the web. Firstly, many online blogging services offer fairly easy-to-use editors, and the next version of Word will support blogging, and hopefully, valid XHTML output. TinyMCE, a WYSIWYG editor written entirely in JavaScript, can be used with WordPress and Drupal, popular blog and CMS platforms, respectively. It effectively provides a word-processor-like interface for document creation, and should greatly improve people’s ability to easily publish web content within a CMS without having to burden a tech services department.

Let’s hope these editors continue to improve to increase accessibility, on both sides of the coin.