The validity of documents on the web is by no means an absolute measure of its accessibility. Validity does, however, provide a solid structure on which to build accessible content. With this in mind, why does the Web Content Accessibility Guidelines (WCAG) working group consider validity to be an ideal, rather than a fundamental principle to guide us to tomorrow's Web?
Author: Gez Lemon
- WCAG Meeting in Brussels
- Is Validity Important?
- Accessibility and Validity
- Dealing with Broken Markup
- UPDATE: WAI Summary
- Further Reading
WCAG Meeting in Brussels
The W3C's Web Content Accessibility Guidelines (WCAG) working group recently had a face-to-face meeting in Brussels. One of the topics under discussion was whether or not to keep Guideline 4.1: Use technologies according to specification. Currently, the level 1 success criteria for this guideline requires that content is valid according to its DTD, Schema, or other tests described in the specification, with a get out clause for backwards compatibility, or compatibility with assistive technology. Following a vote, they resolved to change the get out clause to the following:
Except where the author has documented that a specification was violated for user agent compatibility (including compatibility with assistive technology).
Is Validity Important?
The working group have decided to keep the guideline, but have decided to move the success criteria to level 2, with the following rationale.
- That well formedness and validity can benefit accessibility. However, forcing strict adherence to the specification can sometimes inhibit accessibility. (Also, validity of any declared specification in and of itself doesn't guarantee accessibility because you could create your own specification and be valid to it.)
- If forced to strictly use specifications you might be restricted from doing things you want to do that would not be harmful to accessibility.
- Current WYSIWYG and CMS tools do not necessarily generate valid code, making it difficult or impossible for many authors to meet this SC. (We cannot force authors to do manual coding to conform to WCAG.)
- There are very strong commercial pressures for tools to include features that are not strictly part of public specifications.
- We differentiate between well formedness and validity. Well formedness can benefit accessibility. Validity can benefit accessibility though there may be issues. Therefore, for now we have moved validity to level 2. We will also investigate well formedness and expand it at level 1.
How they intend to re-define well-formedness so that it applies to SGML languages like HTML remains to be seen. I've asked for clarification, but as yet I've only had a partial response (I will provide links when the W3C Mail Archives are updated). It's also strange that they're prepared to redefine a term like well-formed, which has an established meaning, but unable to use the word, 'semantic', because the word is used elsewhere in the W3C.
Accessibility and Validity
I don't understand how a W3C recommendation could passively endorse the violation of other W3C recommendations, which is what they are doing by moving validation as a requirement with a get out clause to level 2. If there are supposedly valid reasons as to why a specification needs violating, there is a strong army of people who would be more than happy to find standards compliant methods to make it work. No one is claiming that valid documents guarantee accessibility, but it is definitely a step in the right direction. It is possible to create valid but inaccessible content, but there is a far greater risk that an invalid document will be inaccessible.
Testability is a fundamental software engineering principle. Invalid documents cannot be fully tested, as the output cannot possibly be known as it depends on the error correction capabilities of user-agents, which varies from user-agent to user-agent. We also need to consider user agents that aren't so widely used, and tomorrow's user agents. Almost all developers consider backwards compatibility, but forwards compatibility is often overlooked. Valid markup is just the foundation. Adding accessibility features to valid markup is likely to ensure that content is accessible on today's and tomorrow's web. Moving the success criteria for this guideline to level 2 means that vendors of content management systems that generate broken markup, can legitimately provide their goods claiming the generated markup conforms to WCAG 2 level 1. I don't follow this rationale, particularly as there are content management systems that do generate valid markup. There are also authoring tools that can be used to ensure content is valid, such as XStandard and eWebEditPro, along with tools like Tidy that can be used to clean up invalid markup. Even mainstream editors like Macromedia's Dreamweaver and Microsoft's Visual Studio 2005 can be configured to generate standards compliant markup.
Dealing with Broken Markup
The reason the web is in the state it is at the moment is because browsers work incredibly hard to rectify markup mistakes. If Internet Explorer, still the most dominant browser on the web, suddenly rejected the rubbish that was thrown at it, would the majority of the web still be invalid? Occasionally, I can't help thinking that a lot of people in the web development industry are incredibly myopic. It works, so why does it need changing? It works to an extent on today's technologies, but broken markup is broken markup.
Assistive technology manufacturers would be able to provide much better tools if they were guaranteed that the underlying markup is valid. As they can't get this guarantee, they typically sit on top of browsers that have somehow managed to make sense of what was given to them, knowing that they're at least working with a structured document tree, even if it is slightly broken according to the relevant specification. Why would they do this? Because an incredible amount of work has to go into being able to parse content that is so unstructured, so it's worth riding on the back of browsers like Internet Explorer that is not only the most dominant browser on today's web, but also has adequate funding to be able to invest in parsing almost anything thrown at it to see its competitors off.
But what happens when Microsoft decides it no longer wants to invest in its browser? A year ago, that was the situation we were in. Today, Microsoft has made a commitment to make their browser more standards compliant. What that means in terms of existing content, and how much of a commitment they intend to make remains to be seen, but the point is we shouldn't be in a position that we're relying on one company's commitment to web standards. The whole point of the web was to make an interoperable system that made content available to everyone. The way forward is to demand valid markup, as although it offers no guarantee for accessibility, it's a far more solid foundation from which to build accessibility.
By itself, no content management system will ever be able to create accessible markup, for the same reasons a validator could never ensure the accessibility of a document. The only way to ensure that content is accessible is to understand the underlying principles, and apply them sensibly. If we want a better web, which would be a web that was usable by people regardless of any disabilities they may or may not have, adding those principles on top of valid markup is fundamentally the most sensible way forward. To my mind, WAI should be advising on the way forward, not condoning and propagating the problems of today's web.
UPDATE: WAI Summary
Following the discussions about the impact of validity on accessibility, the WCAG 2.0 Working Draft 30 June 2005 has no success criteria for guideline 4.1 until a consensus has been reached, and have summarised the issues for further debate.
- A Principled Argument
- Liberal Vs. Conservative
- Web Standards Vs. Accessibility
- Interview with Judy Brewer (Director of the Web Accessibility Initiative)