The only method to truly discover whether or not content is accessible, is from usability studies that include people with a range of disabilities. Accessibility consultants can offer advice for best practice. Automated accessibility checkers can identify common mistakes in the markup. Neither are guarantees that the content is accessible.
Author: Roberto Scano
Automated accessibility validation tools are really useful for a quick spot check of any obvious mistakes in markup. It's important to remember that that's all they are; they in no way signify that the content is accessible. There are many points that cannot be automated, such as ensuring that the alternative text for images is appropriate, and many other issues. The problem is compounded with CSS, as validators do not check the CSS when evaluating a document; they just check the markup, and leave many issues that cannot be automated as user checks. It is the developer's responsibility to ensure that the user checks are addressed before making any claim to conformance to the Web Content Accessibility Guidelines 1.0 (WCAG 1.0).
The following WCAG 1.0 checkpoints apply to CSS, and could be missed when relying on automated validation.
- Checkpoint 2.2
Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen. [Priority 2 for images, Priority 3 for text].
- Checkpoint 3.4
Use relative rather than absolute units in markup language attribute values and style sheet property values. [Priority 2]
For example, in CSS, use
emor percentage lengths rather than
cm, which are absolute units. If absolute units are used, validate that the rendered content is usable
- Checkpoint 7.2
Until user agents allow users to control blinking, avoid causing content to blink (i.e., change presentation at a regular rate, such as turning on and off). [Priority 2]
CSS Zen Garden is an example of a website that makes a claim of being accessible to Triple A of WCAG 1.0. I'm not singling out CSS Zen Garden as an example of a website that advocates bad practice; CSS Zen Garden is an inspirational website that brilliantly demonstrates the power of separating content from presentation, and I have nothing but the greatest respect for Dave, and the many talented designers who have their work published in the garden. I only use CSS Zen Garden as an example, as it recently came up for discussion on an Italian web accessibility discussion list.
Even ignoring the CSS issues, CSS Zen Garden wouldn't meet WCAG Triple A. We don't intend to perform a complete accessibility review of CSS Zen Garden, but even a cursory glance reveals abbreviations that haven't been defined.
If your design doesn't work in at least IE5+/Win and Mozilla (run by over 90% of the population), chances are we won't accept it.
For triple A, IE and Win should be marked up as an abbreviation and an acronym respectively. The point is, there is more to accessibility than pointing to an automated accessibility validator.
There is a parody of CSS Zen Garden, which is truly awful. The link for the accessibility validation misleadingly contains the URL for the real CSS Zen Garden, which is a shame as there are a couple of automated accessibility errors highlighted by Bobby that could easily have been addressed. Still, it does highlight why automated validation is no indication as to the accessibility of the document, as the design, which obviously has accessibility issues, are not amongst the errors flagged by Bobby.
Whilst typical validators do not check CSS for accessibility, the CSS analyser on Juicy Studio (currently being ported to PHP) checks potential colour contrast issues, and that relative units of measurement are used as property values. Roberto has an Italian version of the CSS Analyser, along with a tool that tests for flickering in animated gifs.