Notes from Everett Zufelt's talk on web accessibility, with Drupal 6 and 7 as examples

Everett Zufelt is a blind accessiblity consultant and web programmer living in Ottawa, Ontario. He has worked for the Canadian National Institute for the Blind, and the consulting company Open Concept, and has been an active reviewer of the Drupal 7 accessiblity efforts. In his talk at Drupal Camp Montreal in October 2009, Everett responded to a wide number of questions in a wide ranging discussion. Some general notes follow. To read more about accessibility efforts in Drupal, see his blog on the Open Concept webpage.

Update: An audio recording of this presentation is available thanks to sfyn at riot-nrrd.info.

Accessibility

Accessibility, like making a site multilingual, takes time, money, and expert review. In addition, it is a very broad term; as consultants, we cannot meaningfully promise to make a site "accessible" to everyone, but can instead promise to make it conform to a specific accessibility standard or guideline. A series of such guidelines have been created by experts in this field, including the W3C's web content accessibility guidelines (which they separate into priority levels 1, 2, and 3) and the US Section 508 regulations. These levels allow different levels of accessiblity to be delivered for different budgets. A site conforming to level 1 will be usable by most computer users, possibility with significant difficulty or annoyances. A site conforming to level 2 will be usable by most users. Level 3 will be out of budget for the typical client and Zufelt normally only recommends it to clients with specific needs.

Screen readers

It's not necessary to buy one to test user experience. OS X ships with a screen reader (although currently Mozilla doesn't work with it), the Orca project is available for Gnome on Linux, and the open source NVDA screen reader (nvda-project.org) is available for Windows and is supported by many large software companies. That said, 75% of people using a screen reader use JAWS, a commercial product for Windows. It's also important to note that a person who does not actually require a screen reader to use a computer will have a completely different user experience than someone who does, so simply testing a site with one does not in count as performing a proper accessibility test. But if you decide to do this, you should at least turn the screen off!

Accessiblity was listed as an important area of concern in Drupal 7, along with other usability improvements, but in fact this came relatively late in the development process and the main achievement was to raise awareness of accessibility as an issue. However, Drupal in general is a very good platform on which to build an accessible website, because almost all output goes through a theme function, so at least an accessible theme can be built, for example as a Zen fork. (Open Concept in fact did this.)

In general, making something accessible involves properly using semantic layout. For example, using UL and LI tags instead of BR and IMG for lists will make the content much easier to understand for a screen reader. The majority of accessibility issues stem from poor website design and when fixed result in better user experience for all.

It's not possible to simply detect whether a user is using a screen reader. Screen readers are user agents like any other but typical use a web browser like IE or Firefox to load webpages and provide them a pointer to the DOM. As a result, it's impossible to simply detect screen readers and send different content for them specifically (but see the CSS trick mentioned below).

Drupal

Specific critical problems which remain in Drupal 7: dragable table rows, using groups of radio buttons or checkboxes without a containing fieldset, and the simpletest module. Some of these are usable if Javascript is disabled but screen readers do use Javascript like any other user agent! A good short term solution would be to allow users to disable Javascript for a particular widget like the dragable table rows. Vertical tabs and navigational tab strips are also broken but can be fixed by adding explanatory text which is not set to the class element-hidden (because screen readers respect display: none and visibility: hidden) but rather to Drupal's element-invisible class; this sets the height and width of an element to zero which means that screen readers and other user agents not using CSS will see the text. (For the CSS rules, see this patch from drupal.org issue #473396.) An example of where this is needed it the highlighted tab which displays the Drupal version number at api.drupal.org; the only way for someone using a screen reader to know which version of Drupal the current page is written for is to check the URL.

Finally, while code freeze has already been announced for Drupal 7, webchick has said that accessibility specific bugs can always be submitted and patched.