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.

Conclusion

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.

Many of us would be happy to swap a requirement for validity for a requirement for semantics if your esteemed Working Group would knock off its contention that semantics don’t exist, or, if they exist, are untestable, or if they are testable, are limited to certain technologies only (like the technologies used on 99% of the Web), or, if they are not so limited, are unstatable because somebody else already uses the word “semantics” to mean something trivially different.

Get your Working Group on the same planet as standardistas and then the standardistas will be flexible.

The pros and cons of requiring validation have been summarized at least three times on the WAI-GL list, including by me. We already have validation as Level 2 in WCAG 1.0. It could be left there in WCAG 2.0, because it has demonstrably not harmed any implementation of any significance and has been beneficial in other ways.

A lot of the people who are opposing validity as a requirement of any sort in WCAG 2 work for giant companies whose software cannot output valid code. I wish they’d at least admit that. (Those people also stack the face-to-face meetings.)

If people *really* want or need to change the requirement, which there is no solid reason to do that I can see, why not just:

1. require that document semantics be followed in every technology that has semantics (e.g., use semantic HTML and semantic tagged PDF; use {h1}, not {font size=”3″}{bold} [sic])

2. require that elements not be improperly nested in technologies that have such a concept (so a sequence like {font}{p}{body} would be illegal, but IBM’s cherished tabindex on table headers wouldn’t be)

There. You now have a Plan B.

Yes, crappy CMSs would have to be updated, but the updates would be relatively minor compared to ensuring that nobody’s user-contributed product review on an E-commerce page ever contains a stray ampersand.

Separately, if you want valid code to improve on the Web, let’s get *one device*, just one, to comply with ATAG. Then twist arms so that other devices comply with it.

Matt, I totally respect you and hear the sense in your viewpoint. I’ll admit though, that with all my heart, I still want to see validity at Level 1. Why? Because I don’t want to wait another 5+ years to get it up to Level 1 where it belongs.

As for the issues that conflict between accessibility and validity, my goodness, couldn’t we just publish a concise explaination of those exceptions (where accessibility needs to trump validity)?

Yes, I know that validity doesn’t fix all the problems. But to me it is the core of the solution. In my mind, there are 3 pieces to this puzzle:

Thank you for taking a leadership role and bolding putting down your convictions in an open forum. I imagine you are covered with bruises from this battle. In my heart I know, that WCAG 2.0 will move us forward toward our goal of universal accessibility.

I fully agree with your post. As you may know…
In standard world there are process standards and product standards. As a process standard, I’d like validation would be a best-practice. As a product feature, I can’t see why validity should be required as *mandatory* to accessibility.

There may be validity error that nothing has to do with accessibility, but a lot with old tools that manage the site. If we want web to be valid, we should operate a suasion to CMS and framework maker. But to require validity as a feature, even by law (as we unfortunately have in Italy) will result not in a process improvement, but in a run to demonstrate that code is valid (or in an escape from law), and stop.

Process is the key, not feature. There’s the same difference between usability prescriptive guidelines (“all link must be blue”…) and User centred design (observe user and find better solutions).

I agree that valid code is not a meaningful endpoint in and of itself, however semantic markup cannot be separated from code validity. As noted by Andy Budd in his comment to the earlier post, the impact of invalid markup on accessibility varies. Omitting then end tag of an element will both be invalid markup and skew the semantics of the document; while not encoding an ampersand will have a less dramatic impact. Using a proprietary element or attribute may do no harm, but, in the long term will yield little benefit, if it is not supported by assistive technologies (such as screen readers).

If new methods of making content accessible are proposed by vendors, then they can put forward suggestion to the appropriate W3C working group. A unilateral approach is counter to the spirit of enabling equal access.

Validation (as an outcome) is one way of recognising that content must be authored to shared standards if accessibility initiatives are to succeed.

In my opinion, at Level 1 should be the things that really make your site more accessible. Like meaningful alt-text and using headings. But does making a page validate make it more accessible?

The only thing, I can come up with, is that when you make a web page, and for example you forget to close the h1 element at the beginning of the page. One browser (where you test your page in) might handle the situation just fine, while in some other browser (which runs only in BeOS), the whole page will appear in enormous font.

Well… big font size won’t hurt that much… the page might be still quite accessible. But if the invalid markup crashes a browser, then it certanly harms accessibility.

But on the other hand, some browsers might crash just because of some sort of valid markup. Maybe you *must* make you site invalid, just to avoid it crashing certain browsers?

I think, that weather we place the validity requirement on the Level 1 or Level 2, simpli comes down to question: which is more important – accessibility or validity? If we have validity on Level 1, then we say: your site can’t be accessible if it’s not valid. When we have it on Level 2, then we say: you can make your site even more accessible when it validates.

well said….there are billions of discrete Web resources in existence today. in the first level, your site should be accessible though. and it depends on what browser you’re using or compatible with your site. Validity on the other hand is a diffrent case.

Semantics are certainly a more important point than validity, although one would hope for both.
In the real world, where not everyone is as fastidious as us, both validity and semantics get lost in the race to get home and have a beer.
The thing that validity has going for it is – it is testable and fairly easy to achieve.

I am neutral on the subject of web accessibility litigation, but I am perplexed that you correlate this to â€œwe donâ€™t want laws affecting our code.â€ Would you really deny that 99% of the value of the WCAG comes from being adopted into statute? Could this be why you and I canâ€™t agree on the primacy of validity?

I see the logic in this disagreement. Unvalidated code can be just as accessible as validated code. Requiring valid code for accessibility is not a logical step; itâ€™s a step in a different direction. While valid code is a strong recommendation and can help accessibility, it should not be required.

For people who are starting out in web design, I feel that validity as a part of accessibility is an easier concept to explain. It certainly doesn’t harm accessibility when validating code and can help ease people into the mindset of ensuring their code does meet with requirements.