New Accessibility Guidelines Part IV: Robustness
Editor’s Note: The World Wide Web Consortium recently approved new accessibility guidelines. Passed in December 2008, the new “Web Content Accessibility Guidelines 2.0” is the official recommendation for web accessibility for the disabled.
The new guidelines focus on four fundamental principles:
1. Is it perceivable?
2. Is it operable?
3. Is it understandable?
4. Is it robust?
This article addresses “robustness,” and is part four in a series discussing the impact of WCAG 2.0 on your website.
The fourth principle of the Web Content Accessibility Guidelines requires new web documents to be “robust.” Robustness, future-proofing, user-agent independence, accessibility-supported: All are terms that suggest the same basic idea that your documents should follow standard, supported models for web document types. In many ways, this is the simplest and most testable requirement of the WCAG, but the details can be quite complicated.
The entire text of this principle collapses down to “validate your HTML,” if you look at it in the simplest manner. From a practical perspective, it requires site authors to compose documents according to standard specifications and validate them.
It’s actually a little more complicated than that; but as long as you’re working in standard HTML, this summary is pretty accurate.
All around the web you’ll run into the standard recommendation that web page authors should use valid HTML document types to create accessible, standard-compliant web documents. This long-standing recommendation is founded in the desire for a robust document, although the exact benefits of validation are not always well understood.
Validation Does Not Make a Document Accessible
There are many accessibility suggestions that state you should validate your document in order to improve accessibility. This is not, however, precisely true. Validation does not, in itself, ensure any level of accessibility. Validation does not equal accessibility and invalid code does not automatically lead to an inaccessible site. While it’s certainly true that authors who take the effort to validate their documents are probably more attentive to issues that impact accessibility, it’s by no means a guarantee.
In keeping with the fact that validation does not make a document accessible, WCAG 2.0 does not actually require validation for documents to be considered in conformance with accessibility guidelines. Rather, it requires documents to meet certain specifications of the document markup languages. Since these requirements are easily discovered through document validation, validating your page is the easiest way to test these criteria.
The most difficult part to explain about WCAG 2′s approach to document type conformance is what types of invalid code are acceptable and which are not. WCAG 2 cares more about proper closure of elements, appropriate nesting, and avoidance of ID collisions than about the use of an invalid element. Preserving the internal logic of the markup is important; using all the right markup tags is preferred, but not critical.
Remember, in HTML, the ID attribute is intended to be a unique identifier; no ID attribute value should appear in a document more than once.
Through the rest of this article, I’ll refer to the practice of checking conformance with the “robustness” criteria as validation, despite the fact that it isn’t technically accurate.
Why Validate HTML Code?
So why validate? Why do so many accessibility consultants and web accessibility guideline documents recommend that your web pages meet standards for valid, well-formed HTML or XHTML?
It’s to make them “robust.” Creating a document that meets a published standard for the language it’s written in is essentially future-proofing it. Even if your website works perfectly in all existing browsers, with all existing screen readers, and any other current assistive technologies, the use of non-standard methods and technologies means that you’re not using the methods developers are striving to support.
When developers create new browsers or assistive technology, they look to the language specifications for HTML and XHTML to determine how they will make the information available to users of their software. When you follow those specifications, you’re working with the goals of future software developers. If you ignore them, you’re making life harder for the developers. At some point, you’ll be depending on technologies that common software has decided not to support.
To build a robustly supported accessible website you can’t just validate your HTML and stop there; you also need to be using supporting languages which are themselves accessibility supported.
What Is Accessibility Supported?
Accessibility supported means that the technology can be used with assistive technologies. Delving even more deeply, it means that the creator of the technology – (e.g. Adobe, creator of Flash) – has programmed elements into its technology which assistive technology (e.g. screen readers) can use to access the information in the technology.
What Technologies Are Accessibility Supported?
Managing website robustness is a tricky practice of carefully balancing the specifications of a language with what will provide the best practical experience for users of assistive technology. Although validation isn’t actually required, it’s a good way of checking to see whether there are any errors in your page that will cause problems for your customers with disabilities. You can play it safe by using highly-supported technologies such as HTML and CSS. But rich media technologies such as Flash or Silverlight are not forbidden. If you do choose to use them, however, you’ll need to understand their levels of support for assistive technology.