This is hardly a new topic of discussion amongst web developers – designing accessible web sites that take advantage of the latest technological advances in scripting and browsers has long been a challenge embraced by the community. Many years ago, when the W3C’s Web Accessiblity Initiative (WAI) was first released, my non-developer manager (at a previous place of employment) asked me: “Why, other than it’s the right thing to do, should we worry about making our site accessible?” It was a good question then, and it’s a still a good question.
The WAI, developed by the same group responsible for defining what XHTML is, in addition to guidelines and techniques for accessibility defines several levels of accessibility. Measuring accessibility is somewhat tricky. It’s like measuring the effectiveness of an essay, how well did you get your point across – you know it when it happens but a formal rubric is more challenging. That’s where the levels help.
Interestingly, some of the most simple methods for achieving a base level of accessibility, also makes for a stable, content rich website. What’s the secret? Follow standards and write your XHTML in a semantic manner. When your underlying code is clean and ordered, and you use stylesheets to keep the presentation seperated form the content, you are 90% of the way toward fulfilling the Level 1 accessibility guidelines.
Ah, but what is semantic markup, especially in the face of a web application? Quite simple, headings are headings and lists are lists. When it comes to semantic markup, it’s time to remember back to grammar school and outlines. Once you’ve got the sections of your pages defined, you can work on giving them headings, and presenting your information. Even in forms, you’ve got an expected pattern for the data entry. Let the semantic markup show the structure by using lists (ordered lists work great). The CSS file will take care of making it look good.
There’s a great discussion regarding this techique in A List Apart, issue 218.
Based on the services we offer, it is not unusual that our visitors may be system administrators, working remotely at a terminal on an *NIX machine, with no access to our service except via a lynx browser or by using a smart phone– but they surely do need to access our application. And it just so happens that a lynx browser is very similar to how a screen reader would approach presenting a site to a visually impaired visitor. User agents available today both as assitive technology, and as aides to our even more mobile society, are numerous. By maintaining a policy to write valid XHTML/CSS, seperate content from presentation, and use scripting only for augmenting the experience we know that our applications will be accessible to everyone.
It just so happens that fulfilling the Level 1 and many of Level 2 checkpoints for accessibility, we’ve made our site useable for all of our customers. And that is why we care about making our site accessible. Because a site that is accessible to all is just good business.