Validity and accessibility guidelines are like matter and antimatter: you probably don’t want to be there when they collide.
In June, I wrote a principled argument for leaving HTML validity out of the set of minimum requirements for accessibility set forth in the Web Content Accessibility Guidelines 2.0. My position hasn’t changed one iota from what I wrote back then. (Or, for that matter, since I wrote about why we don’t want laws affecting our code.) I didn’t expect that would be the final word, and naturally, it hasn’t been. Last week, the topic was raised again, following a recent face-to-face meeting I attended. Validity remains the elephant in the room, as Gez Lemon put it, and the rift between those who want it as the first priority and those who don’t widens each time it is discussed.
The latest draft has validity at level 2. As it stands, this is apt to be resolved only after a vote is taken, the dissenting parties file a formal objection, and the matter is decided by the W3C Director. Until that happens, I know that I am wasting my time attempting to fight a religious war on the list, so I will try to leave my thoughts here, and from this point on will attempt to stay out of the on-list scrum.
Accessibility is a process
I’ve said it a million times. Furthermore, I’ve said that there is no sustainable means of producing invalid content with a reasonable level of accessibility over time without valid, semantic HTML coding practices. A document describing the minimum requirements of an accessible design process or workflow must include valid, semantic coding as the core element.
However, WCAG is not that document. It is not a document about process. It is a document that measures outcomes. That is, conformance to WCAG is a measure of the accessibility of the final artifact, not the thought or actions that went into it. It is tempting to force people into valid coding practices by constraining their output, but it is as likely as not to happen that developers will instead consign validation to a final step, as most do with accessibility already, and the result will not be closer to our goal of valid, semantic content, but merely ugly code that has been run through HTML Tidy. It won’t eliminate tag soup; it will only ensure that such tag soup is strained.
Validity isn’t really the minimum
I am using the same phrase over and over again (valid, semantic content) because validity is not sufficient at the code level for the needs of accessibility. You can create a valid document that still uses line breaks and bullet images to represent an unordered list. You can create a valid document nested layout tables and hundreds of instances of the
font element. In fact, it wouldn’t take a rocket scientist to create a completely non-semantic HTML document that renders perfectly in a visual browser but makes no sense in a screen reader. (Hint: style random elements to look like other elements.)
We anticipate much of this in the WCAG document, and some guidelines fill in the gaps. But how can you tell the readers of WCAG that semantic freshness is as important as the technical constraints of validity? That one is merely more testable, and that we as participants of the working group consider the two to be part of the same strategy, does not mean that the rest of the world will agree. We risk exalting validity because of its concreteness over the real prize of being semantically correct, instead relegating it to the manual checks everyone ignores when they run an accessibility evaluation tool.
It’s a big Web out there
There are billions of discrete Web resources in existence today. My desire is to publish a specification for which measurably increased accessibility is achievable for all of them. But sometimes, making a tag-soup site valid isn’t technically possible. You may be importing content of an unknown state into your own resource. That content may be from a component you don’t have access to, or the output of an old (or even new) piece of third-party software that has bogus attributes. And maybe you introduce a validity fault yourself because your blog editor doesn’t catch an invalid fragment as it comes in. (Most don’t.) These seem like little edge cases, but I run into them over and over again, in the real world, in November of 2005.
We can talk all day about how we’ve had five or six or eight years to get to where validity is an expectation. But the landscape tells us that hasn’t happened: most content is invalid, most authoring tools still happily produce invalid content; and most of the people who produce HTML regularly would not be able to tell you what validity means. We can say that validity is possible, and that is true. We can say that it is feasible in all situations, and that is true enough for me to agree. But what we cannot say is that the tools and the people who use them are ready to be held to account for universal validity, when all evidence is to the contrary.
It is easier for assistive technology to deal with valid code, as it is with other user agents. But it’s an imperfect world out there. The assistive technologies themselves today require the presence of invalid code (i.e.,
embed) to enable accessibility features of Flash. (Techniques exist to get around this in a valid fashion, but invalid code will continue to be injected into otherwise valid sites as long as
embed is a part of the output of the Flash authoring tool.) In fact, Freedom Scientific invented an attribute named contexthelp unilaterally, introducing support for it in JAWS 5. If WCAG 2 required validity as a minimum requirement, it would set the stage for vendors to claim that WAI is declaring functional accessibility best practices to be inaccessible, thereby putting theory above reality. It would say bad things for WCAG’s adoption if users with disabilities were to complain that doing so would cause harm to their real-life access needs.
Even if validity were specified, browsers and ATs wouldn’t suddenly be able to refuse to process non-standard code. If they did, they’d be blocking users from accessing a large majority of the content that’s out there. So we can’t argue that it would make the lives of AT vendors any easier; we can only say that the outcomes will be more predictable overall.
So, what am I going to do about it? Lots of doing, hopefully, and not a lot more talking.
The Web Standards Project Accessibility Task Force is going to be working on various materials to support WCAG. I hope to be more specific about this in the very near future. We will show valid, semantic approaches to common and advanced accessibility problems, as proof that they can be done without magic. I’m hoping that we will have lots of code to be taken freely and applied to solving problems that are often solved inaccessibly, the most common in my mind being forms validation. For the purposes of our work, validity is not something which will be compromised. One of my most vocal opponents on validity in WCAG, Gez, is also on the Task Force, and while he’s not the only one in the Task Force who disagrees with me on that, I’m pretty sure all of us agree about our own output.
I have already stated that I think WCAG should state clearly in the document that valid, semantic coding is practical and applicable to all HTML content created today, but it is only beneficial for accessibility if it is an integral part of the process that created it. Running a validator after the fact is not good or thorough enough. We have to find a way to explain to people who fall under the scope of this document that changing processes and asking questions every day is the way to ensure sustainably accessible output. In that context, forcing the construct of validity may even act to obscure the overall goals of the specification. It’s a difficult position to defend, and I have had my name dragged through the mud for taking it. I hope somewhere in here a few people can see the sense in it.