Can checklist accessibility be harmful?
Accessibility checklists based on WCAG or Section 508 guidelines were intended to help make Web sites accessible. These checklists are meant to ensure that the process of accessibility checking is done consistently and comprehensively. So how can accessibility checklists be harmful?
What's wrong with accessibility checklists?
The wrong tool for most users
In the hands of accessibility experts, accessibility checklists are useful. Unfortunately, these checklists have been incorporated into automated accessibility checkers that are used by those with little or no accessibility training. Checking accessibility is a process that does not lend itself to automation. Most accessibility issues require manual checks and so training and experience in the field of accessibility is required, or tools must be tailored to specific accessibility-checking tasks.
Below is a screen shot of an automated accessibility checker from a popular authoring tool showing the large number of checks that need to be performed manually. Without the training necessary to do this, users will simply skip over anything that is optional and that they do not understand, because many users assume that if they don't understand something then it must not apply to them.
Accessibility checkers based on checklists cannot check for many common accessibility problems
Accessibility checkers based on checklists give non-expert users a false sense of accomplishment. For example, the most common accessibility problem is incorrectly written alternate text for images. The mere presence of any type of alternate text at all will cause most accessibility checkers to give a pass to the checkpoint that requires alternate text for images, even if the alternate text causes compression problems as shown in this example:
<p>I <img src="heart.gif" alt="Image of a heart." /> you!</p>
And the same accessibility checkers will raise an error if alternate text is left blank, even when it is appropriate to have a blank value for an image, as shown in this example:
<p><a href="#top"><img src="up.gif" alt="" />Top of page</a></p>
Checklists are making accessibility a frustrating experience
For many authoring tool vendors, accessibility checkers based on checklists are a convenient alternative to building interfaces that encourage authoring accessible content in the first place. This is because accessibility checkers are easy (i.e. inexpensive) to incorporate into products and allow these vendors to market their tools as being compliant with accessibility standards.
For content authors, the frustration arises from the fact that the same authoring tool vendors provide authors with tools that undermine accessibility by creating markup that applies formatting to content when what is required is semantic (i.e. accessible) markup, such as headings. Content created in this way will therefore fail accessibility checkers.
Prime culprits are color pickers and font selectors as seen below:
These color pickers and font selectors generate semantically barren content such as the following that is devoid of accessibility:
<span style="color:red;font-size:20px">Breaking News</span>
As a result, authors become resentful towards accessibility checklists and impatient with the principle of accessibility, because they are punished for using color pickers and font selectors that they were initially encouraged to use.
So what is the alternative to accessibility checklists?
The solution is authoring tool interfaces that encourage the creation of accessible content in the first place, and that let authors review what they have written much as an assistive technology would process the same content. Authors can then easily make and review any accessibility adjustments that are necessary.
User interfaces that encourage accessible authoring
The following are just a few examples of how authoring tools can encourage accessible authoring:
- Color picker and font selector tools have got to go
- Once color pickers and font selectors are removed from authoring tools, content authors are far more likely to use accessible markup such as headings.
- Make users select the type of table they are creating
Until an acceptable alternative for layout tables comes along, when a content author creates a table, make them choose between a data table and a layout table.
- Use proper labels
The way that fields are labeled can influence what users type into those fields. For example, are you more likely to enter alternate text for an image (correct) or a description of an image (incorrect) in a field labeled "Image description" below?
- Make users specify how they intend to use images
Encouraging users to avoid accessibility by letting them turn off accessibility features such as the prompt below is not the answer, and does not help authors create more accessible content:
Instead, when inserting an image, the user should be prompted to decide if the image is used for decoration or not. When used for decoration, the UI would prevent alternate text from being entered. When used for non-decoration purposes, then alternate text would be required before the image can be saved.
Display content for review the way assistive technology may see it
A machine working through a checklist cannot determine if content makes sense. Only a human can do that. So let's give the human the ability to view content the way users of assistive technologies may view content. For example, the following screen shot shows an authoring interface using images and a data table. Both images have alternate text, but is the alternate text likely to be useful or confusing given the way it is written?
The screen shot below has the answer to that question. It displays the same content in a way an assistive technology might see it. The alternate text for both images is displayed in place of the images and it becomes readily apparent that the alternate text is not accessible. Both alternate texts need to be edited if the sentences they appear in are to make sense to an assistive technology user. The data table is also displayed, in linear fashion as an assistive technology may process it, and here the headers are properly associated with the appropriate content cells, ensuring that the table does make sense to a user of assistive technology.
Displaying content the way that an assistive technology might see it is preferable to using an accessibility checker not only because it is far more engaging for authors, more empowering; it is also the only way to spot some accessibility issues (such as comprehension problems) that checklists simply cannot spot.
Conclusion
For most users, checklist accessibility is not useful and may even be harmful. Automated accessibility checkers based on checklists can be confusing and can fail to identify common accessibility issues that can affect comprehension of content. A better alternative is to build tools which encourage the authoring of accessible content in the first place, and which reveal the content being created as an assistive technology might see it, allowing authors to really understand what accessible content is, and to make any necessary corrections to achieve it.
Comments are closed for this article.