A few weeks ago I watched a live web conference in which the open source Plone content management system was put through its paces by a blind person using a screen reader (JAWS). Two important issues stuck with me, since they affect most websites, are quite serious, but do not seem to be very widely known.
Popups are usually inaccessible
(Ticket 12123) Popups (by which I mean dynamic overlays rather than popup browser windows) are usually inaccessible. For example, in Plone the login button invoked a login form inside an overlay. Popups are also commonly used for modal dialogs. It is common practice to put popup DIVs at the end of the HTML body, but this means screen reader users are usually not aware of their appearance, nor have any way to get to their contents. (Especially if they do not contain forms; forms in popups are still accessible via JAWS “forms mode”.)
There are two alternative solutions:
- The trigger element should have an anchor link to the popup contents.
- The popup should be inserted in the markup immediately after the trigger element.
Both have some associated problems, but I prefer the first solution and will try to implement it in future.
Form field help should be part of the label
(Ticket 7212) In the commonly-used “forms mode” in JAWS, the screen reader reads only labels, legends, input fields, select fields and textarea fields, but no other elements in the form, such as paragraphs, DIVs, etc. That means any help text (usually positioned below or alongside the field) is ignored. This also applies to validation error messages.
The recommendation is to include the help text inside the LABEL element, and use CSS positioning to put it in the right place in the layout. (I can see how this can cause problems where the text should appear above or below fields.)
Update: Here’s an example (see also the ARIA enhancements, not quite reliable cross-platform according to the associated Alistapart article)
Update 19/10/2011: This article recommends the use of aria-describedby for both help text and validation message. It advocates telling users of non-ARIA supporting screen readers to upgrade (but claims that JAWS has supported it since version 10 in 2008)
It was good to see a content management system take accessibility so seriously. Here are some more tickets.