Identifying Accessibility Errors

Date: March 16, 2005

As part of the development of the Evaluation And Repair Language (EARL) the WAI ER group has been looking at methods of identifying content that causes accessibility problems. Several methods have been discussed on the ER mailing list and these include:

Another method that hasn't been discussed on the list is to embed markup within the document to identify items that are causing accessibility problems. This could take the form of "id" attributes or "title" attributes on elements. For every element that was causing an accessibility problem a unique id attribute would be added so the element could be easily found later. The problem with this approach is that most authors would not allow extra code added to their document just for accessibility testing purposes.

Use Cases

Listed below are two use cases that require accessibility errors be identified.

1) An author creates web content and then runs it through a software program that detects accessibility errors. The software program identifies several problems and produces a report informing the author of the results. The author reads the report and fixes the errors.

2) An author creates web content and uses a software tool to check for accessibility problems. The software tool identifies items within the document that are possible problems and requires human judgement. The author makes judgements about the content and the software tool records the judgements so they will not be needed each time the content is tested. (example judgement: All text within the image is in the alt text.)

Requirements

  1. All accessibility problems can be identified - both machine testable and human testable problems.
    Example machine testable problem: img is missing an alt attribute. Example human testable problem: all text within image is in alt text
  2. Accessibility problems can be identified without adding anything to the source document.
  3. Accessibility problems can be identified even if the source document has been modified.

Discussion

In the first use case the error can be identified using XPointer. It's been noted that XPointer may break down when used on poorly formed HTML documents but that should not be a problem. The WCAG 2 is requiring, at level 1, that documents be valid[1] so XPointer will work. It would also be helpful to record line numbers. If the document has been modified the error may still be detected by running the original test process that identified the problem.

In the second use case XPointer will not work because the document may be modified and all XPointer expressions are compromised. The use of general XPointer expressions may provide some identification but it's unlikely that a general identification mechanism will work and provide the persistence required.

The second use case requires the use of identifiers that are specific to the accessibility requirement. For example the accessibility requirement that text within the image be in the alt text requires that the image and its alt text be stored as the identifiers. The identifiers, in this case, can be the name of the element (img), the image (src attribute) and the alt text (alt attribute). If the document is modified the image can still be found using these identifiers. Other attributes if present, such as 'id' attributes, could also be used.

For another example I'll use the accessibility requirement that alt text for images used as anchors describe the link destination. In this case the identifiers need to be the name of the element (img), the image (src attribute), alt text (alt attribute) and the anchor element (href attribute) that contains the image.


[1] Use technologies according to specification.

Editors: Chris Ridpath, Gabriele Bartolini