Accessibility and usability
By Peter-Paul Koch
published on February 18 2004
At the moment we Web developers are learning the basics of accessibility, as once we mastered the basics of usability. However, in my last column I hinted at a potentially dangerous “accessibility vs. usability” question. The time has come to study this question in more detail.
First, let’s repeat the principles:
- Ideally, any site should be accessible. Any device should be able to access the content and navigation of any site.
- Ideally, any site should be usable. Though basic usability is ascertained by clear texts, unambiguous forms and a simple navigation, adding some JavaScript and CSS can dramatically improve a site.
We see the outlines of a problem here. Does building a perfectly accessible site mean all usability extras should be perfectly accessible, too?
I think few people will disagree if I answer “No”. To me, saying “Yes” means “If it doesn’t work in screen readers we can’t use it”, and that approach would take perfect accessibility a step too far.
A usable site
Just saying “No” doesn’t solve the problem, though. We need a more detailed and balanced view.
Take a long and complicated hierarchical navigation, like the 185+ links of my own www.quirksmode.org. When I created it, I had to satisfy basic accessibility (“can my visitors navigate my site under all circumstances?”) and basic usability (“can my visitors find the links they need among the 185+?”).
I decided on a twofold navigation:
- Usability: I’d use a three-level hierarchy in the navigation frame of my site. It would use JavaScript to open and close blocks of links, so that the user could choose the level of detail for himself. This high-end navigation would be full of extra usability features hard to mimic with XHTML alone.
- Accessibility: I’d also use a directory navigation. The homepage would contain a table of contents that led to the tables of content of the site sections. This navigation would always be accessible.
The content pages didn’t contain any generic navigation, just some inline links to related pages. There was no sitemap. Besides, I used frames. I added a bland noframes link to the homepage, but otherwise didn’t do much to make noframes visitors feel welcome.
So the bare-bones accessible navigation worked like this:
“Welcome, sort of”
-> “Homepage, primary TOC”
-> “Secondary TOC”
-> “Content page”
-> errr…
I assumed visitors would use the Back button to go back from the content pages to the TOCs.
An accessible site
After the site had gone online I started doubting my solution. Was the accessible navigation too bare-boned? Was the gap between accessibility and usability too large?
To enhance the bare-bones navigation I’d have to add hard-coded footer links to all content pages. Traditional footer links include “Home”, “Sitemap”, and maybe “Copyright”. Copyright is not important to me, and I didn’t have a sitemap. That left me with “Home”. I duly added it to every content page.
Then it struck me that I already had a sitemap! The navigation page I used in the high-end view already contained all the information a sitemap needs. That reduced the question from my entire site’s accessibility to the accessibility of one single page.
I recoded the page so that it offers a serviceable, simple sitemap as primary view. Then I added a new behavior layer that switches the page to navigation frame view if it happens to end up in my navigation frame.
I added a “Sitemap” link to all page footers, upgraded the noframes entrance to something slightly more useful… and wondered whether it was enough.
Now the bare-bones navigation worked like this:
“Welcome! Homepage or sitemap?”
-> “Sitemap”
-> “Content page”
-> “Homepage or sitemap?”
I left the TOCs in place. I suppose some users will like them better than the sitemap or the high-end navigation. Together, the sitemap and the TOCs solve all accessibility issues… don’t they?
Which leaves me where I am at the moment. Did I find a balance between accessibility and usability? I’m not sure. You can judge for yourself by using my site in a W3C DOM capable browser (except for Explorer Mac), and in an older browser.
Questions
The delicate balance between accessibility and usability needs more thought. At the moment I don’t see any answers, only a few questions, one possible rule, and a potential danger.
The rule is “Accessibility should not restrict usability”. If your site badly needs a few advanced JavaScripts to make the navigation or a form more usable, don’t hesitate to add the scripts.
Yes, it will make the difference between the high-end site and the low-end site larger, yes, it will mean that people with uncommon browsers will see a less-usable site, but that’s inevitable… isn’t it?
Of course the navigation or the form should also be accessible without JavaScript. “Accessible” doesn’t mean “perfectly usable”, though. Accessible simply means that it is possible to use the navigation or the form.
But where do we draw the line? When can we say that the accessible view of the site becomes unusable, or that the usable view of the site becomes inaccessible? At the moment I don’t know, but I hope other people will take up these questions and will start answering them.
Accessibility vs. usability?
Finally, I see a potential danger. Some people, let’s call them accessibility zealots, might redefine these interesting questions as an “accessibility vs. usability” match, as “Should your site be accessible, or should it be usable?”.
I feel we don’t gain anything by asking these questions, or by giving simple-minded, useless answers like “Accessibility is the only road to salvation”. This sort of silly ideology would drown out the balance we’re looking for.
Few people would object to usability, and my fears may be unfounded. However, I think potential accessibility zealots would disagree not with the purpose—a more usable site—but with the tool—JavaScript.
Therefore any possible “accessibility vs. usability” danger is related to the future of JavaScript. My next column will discuss these two problems in more detail.