Accessibility and usability
In: Columns > Keep It Simple
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.
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:
- 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”
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?”
-> “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.
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.
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?
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.