When Usability and Accessibility Conflict

In February 2008, I was fortunate enough to attend Baa Camp. The gathering was something that is hard to describe, and this is not the goal of this post :) During Baa Camp, I led a discussion arround usability, accessibility, and possible conflicts between the two. Most often people think that if a system is designed to be usable, it’ll automatically be accessible. And often, increased usability does increase accessibility. But sometimes, techniques used to increase usability decrease accessibility. A prime example is the use of AJAX "tabs".

We’ve all seen these tabs. They’re great (for sighted users). They allow much content to be on a page, but hidden until the user clicks on a particular tab, at which point the content assigned to that tab gets displayed. Using such a technique, we can present blocks of content to the user, without cluttering the page too much. Good stuff.

But the problem is, all too often, implementation of these techniques don’t take into account keyboard only navigation. Unless a user physically clicks on the tab, the content change will not be triggered. Another problem is that it relies on javascript. This is not as much of an issue as it was even just a few years ago, but then, there are unexpected barriers here – a growing number of corporate firewalls block javascript, so a user may have it enabled in their browser, but they won’t be able to get the content because of corporate firewalls. And a third problem is due to the very nature of AJAX, reloading content without reloading a page. Blind users relying on screenreading applications have no way to tell that content has been reloaded. When the link is activated, content changes but the page doesn’t reload, hence the screenreader stays mum. These applications don’t usualy just do nothing when a link is activated, so the user thinks the page is loading very very slowly. So they go to the top of the page, and think it’s the same page, with the same title, and the same content, and won’t scroll down the page to see the "new" content, because they don’t know it’s there! And we can’t depend on the blind user and screenreader relying on being able to access the content because they can’t use javascript – more and more screenreaders handle javascript correctly! There are ways to circumvent the first and second issues, but the third is more difficult.

This is a clear example of a usability feature getting in the way of accessibility. So, what’s the answer then? In this case, I’m not sure. There’s always an answer, a trick, a way to make it work.

But the lesson here is more about planning feature implementation, thinking about the consequences of each bell or whistle we put on a site. And if you plan for this from the beginning, you’ll avoid heartaches and costs later on during development!