The next draft of the Web Content Accessibility Guidelines 2.0 probably will not require HTML content that conforms at Level A to be fully valid. The following is my rationale for agreeing to this.

(Disclaimer: I am not speaking for my present employer — neither W3C nor WAI. Nor was I present at the face-to-face meeting where this was decided. I have been a participant in good standing of the WCAG Working Group for almost five years.)

A little background: the W3C is a technical standards body. It is not a policy body. It can make validity a technical constraint — and did, with XHTML and the application/xhtml+xml MIME type. But it cannot make validity the law of the land.

The Web Accessibility Initiative, however, is not so cut and dried. WCAG, the crucible in question, is the basis for actual government policy in a large number of countries and smaller municipalities. It is also a measure of accessibility among developers who know nothing about accessibility other than it is required of them, as well as those who use it as a goodwill gesture toward users with disabilities. It’s all things to all people, and that’s the very problem we face.

Those who have seen fit to malign the W3C for stopping short of validity need to dial down the rhetoric a few notches. To hear some of the commentary, this is a travesty, the greatest step back for the Web since blink. How distasteful, they say, for the WCAG Working Group to roll over for their corporate masters so shamelessly.

Would that it were that easy. Few, if any, of those who argued against validity as a mandatory element did so out of self-interest. Rather, the concern was that it limits the applicability of the spec across the range of content already available, and that jumping through this particular hoop is not strictly necessary. It’s not, as has been (ex)claimed, a vote for tag soup. It’s a pragmatic decision — and pragmatism is valued over idealism where policy is concerned.

This debate is happening on a fault line between technology and policy. This is not liberal vs. conservative, even in the Jon Postel sense. Those who are arguing for validity in this point seem not to realize that this is a vote for authoritarianism. What you do for users with disabilities, this argument goes, is not as important as passing this binary test. Who would be champing at the bit for their Java code to be evaluated by a government body? Then why is this desirable for HTML?

Think about the ramifications of making valid code a legal requirement. Say you’re a Web designer. You leave out a semicolon in a Â on your home page.

You move a fragment of code from a place where it is valid to where it is not.

You redesign your CMS templates. The CMS happily churns out whatever fragments are in its database, blithely unaware of whether it is valid in context.

You use a feature that requires an additional attribute not found in HTML 4.01, which improves the experience on some browsers and does no damage on others.

You use the default code to embed Flash content.

Do you really want to be liable for these errors, even if they don’t actually damage overall accessibility?

WCAG has to apply to all content found on the Web, constrain itself to accessibility flaws at the document level, and be compatible with policy implementations. We can’t specify something that’s overly broad, lest people get the wrong message (for example, that validity equals accessibility, full stop — still a popular myth). All we can do for this document is to ensure that its guidance is sufficient to increase accessibility without overreaching, and hope that it maintains hull integrity when organs of policy evaluate its feasibility.

I have said it a million times now, and I’ll say it a million more: accessibility is process, not product. If this were the Web Development Process Accessibility Guidelines, and validity were the question, I would sign off on it in a heartbeat. In fact, I requested the addition of validity to the Authoring Tool Accessibility Guidelines 2.0, which I co-edit. And that’s where it belongs: not at every author’s doorstep, but in the products they purchase and use.

As process, validity is a no-brainer. It’s one of the first things I teach. I am a staunch advocate of standards-based design. Accessibility in seven words: “Write valid code, and use metadata well.”

But process is much harder to legislate, and blanket guidelines are hard to keep clean. If it can’t be proven that validity itself improves the accessibility of all Web content, then the case for WCAG’s promotion as a policy vehicle is called into question. WAI is not a Trojan horse for other interests; it is focused on increasing access to the full breadth of the Web by users with disabilities, and nothing more.

So, then. That’s how a standardista comes out against validation. I’m not, as I have been accused of, playing devil’s advocate here. I genuinely believe the lowest conformance level of WCAG 2 is the wrong place to require validity.

Here’s the comment box. Flames against me will be deleted and users will be banned without warning. People on my buddy list are not immune. Play nice.

18 responses to “A principled argument”

WCAG WG has already been told that it screwed up its handling of the whole issue. An argument for retaining validity at Priority 2 is not difficult to make. Modulo some peevishness, you already made it here and on the WAI-GL list. But the braintrust in Brussels didn’t. Apparently they’re not such great communicators after all.

My sadness is actually that it sent a loud message to people that validation is a crock. Whether they intended it that way is a bit beside the point, people who don’t know better will use the demotion of validation argument as an excuse to not even bother. I think I understand most of your article, and I’m hopefully not a crusader because I don’t really know enough yet to go crusading, but I can’t really get the process and product thing you mention. But this is a hard one and is going to become quite an emotive topic in the next month as different entities speak out.

While I don’t believe for a minute validation is accessibility – it’s still the first rung of the ladder. And I’m losing track a bit because it’s becoming clear accessibility means different things to different people in this conversation…

No doubt I’m one of the one’s saying it’s a bad day for the web – if I’m wrong then it needs to be demonstrated at a level I understand. And I’m willing to listen. Have you possibly thought of the implications that any sign of a backward step sends to those that say web standards and accessibility are a crock? And is a site with 199 validation errors on it’s home page now kosher?

I’m not having a go at you (re: last paragraph) but I’m obviously not understanding the finer points of WCAG. Should I even bother? I’m a bit disheartened really. As a developer I have to wonder if every man for himself isn’t the future web of tomorrow after all. Have I backed the wrong horse in my business judgement? I may stop meeting validation requirements myself if they are considered unimportant and just go back to the old ways – currently I get cut out of collaboration jobs because of my standards methodology. I apologise for the long comment, its the flu making me ramble.

I don’t think anyone at WAI or on the WCAG working group is saying that validation is unimportant, but that in the grand scheme of things, it’s not *AS* important as other things when you’re talking about accessibility.

Priority 1 *has* to be about the things that are going to cause the biggest impact to disabled users, and while validation is important and certainly helps that, the odd unencoded ampersand or whatever isn’t going to make that site completely inaccessible.

Priority 2 is the right place to put it. Important – yes, but not essential for the site to be considered accessible.

Accessibility and standards compliance are complimentary things, but not the same. If you want to be standards compliant, you write valid code. If you want to be accessible, you confirm to the WCAG guidelines. If you want to provide quality sites that are backwards and forward compatible and able to be used by the widest possible audience, do both. It’s really not that difficult a concept.

If WCAG forced everyone to make code valid as part of priority 1, then far too many people wouldn’t bother with it, and use it as an excuse to not be compliant, claiming that accessibility is too difficult to achieve.

Think about it from an end user’s perspective for a minute – if you can now access a site you couldn’t previously access, do you really care if there’s a couple of ampersands unencoded?

Nope.

Is the world going to come to an end as a result?

Nope.

Does that mean that “you”, as a developer, designer or coder shouldn’t do your best to make sure the code is well formed and valid?

“WAI is not a Trojan horse for other interests; it is focused on increasing access to the full breadth of the Web by users with disabilities, and nothing more.”

I think you’ve hit the nail firmly on the head. Too many people think Web Content Accessibility Guidelines and WAI is about making content available to all people on all devices – and its that perception that’s behind the steadfast determination that validation be a critical issue.

I think the more correct statement in regards to validation is that invalid markup is indiscriminate, it doesn’t treat disabled people with significantly worse than non-disabled people. I suggest the evidence behind wanting valid markup to be a priority 1 needs to prove that disabled people are clearly worse off than non-disabled people when exposed to it.

Joe Clark’s statement that two screen reader vendors have acknowledged that their products handle valid markup better than invalid markup is an excellent argument for the inclusion of valid markup as a priority 2 item (or whatever the WCAG2.0 equivalent of that is), it also implicitly suggests that invalid markup is being handled, possibly no worse than other mainstream browsers.

Being one of those who complained about this I appreciate you letting everybody know why it was done. I also agree with your reasons. Thanks for clearing things up.

I am still worried that it will send a message to those who do not care – and there are many of them – that it’s OK to skip validation and use HTML/CSS/JavaScript/whatever that only works in IE/Win. That could then lead to sites being accessible to users of assistive devices that rely on IE/Win’s HTML parsing but inaccessible (or accessible but unusable) to those who use Firefox or Safari or any other browser that follows web standards more strictly than IE/Win.

Maybe I missed something but I thought the guidelines were about accessibility not legislation. If something is going to cause a certain type of accessibility issue then it should be placed at the appropriate level. It’s then up to the various governments, courts etc to decide the legal implications, not you.

The problem is, a site either validates or it doesn’t. Unfortunately accessibility isn’t so black or white. Badly mangled code can cause all types of user agents to fall over. However one unencoded ampersand isn’t likely to do any harm. So one type of validation error may be a priority 1 issue while another may be a priority 2, 3 or not an issue at all. As such, maybe blanket validation isn’t the answer, but some other test for the accessibility of your code.

That’s of course assuming we’re talking about documents served up as text/HTML. Obviously when XHTML docs start to get served up as XML, then validation is unquestionably a priority 1 issue, if it’s a badly mangled doc or simply an unencoded ampersand.

As I said, WCAG is all things to all people. It’s not an attractive situation to be both a guide on Web accessibility and a vehicle for policy. If I had to stand in a crowd of developers, I would tell them thou shalt produce valid code! — but I wouldn’t make a law out of it if I were king of the world, because I’m wary of unintended consequences.

(And when XHTML gets served as XML, then validity doesn’t need to be specified, because it can’t function otherwise. Those are my favorite kind of constraints, because they’re self-enforcing.)

Roger:

Validity is important to accessibility, of course, but, as above, it’s better to evangelize, influence and train the users somehow to produce valid code than to yoke them into it. I think it’s better to show people it’s in their self-interest to be valid than to say authoritatively that for all content in the world, validity is a basic minimum requirement.

A lot of people have raised the point that the set of things that aren’t specified in Level 1 are therefore “not important” for accessibility, and that bugs me. We’re not talking about what is important, we are talking about what is mandatory — that without which accessibility is effectively impossible to a group of users. It’s a complicating factor that we have levels at all, because it lets people think too little about what they could do and focuses them on what they have to do. It’s like judging figure skating or gymnastics: unless you have comprehensive, rigid criteria, what you come up with is too subjective to be useful. (And then you have to give out two gold medals, when clearly the Canadians were superior.)

I wrote back in 2001 that someone should write the O’Reilly book on Web accessibility, and I still think that’s needed. Of course, that’s usually the reason people become Web accessibility authors. They want to effect change in the process with which content is created — and that is where I think people should learn what is important and what is not. In fact, I think there should be a big disclaimer at the beginning of WCAG 2: “If this is your first time reading about Web accessibility, stop now and go read this introduction.” (I think something like this is actually the plan.)

Our biggest problem among content producers is ignorance, both benign and willful. Generically ignorant content producers reading WCAG 2 for the first time will dutifully read all of the requirements without learning any of it, and fail to produce anything really useful. Those people are best served getting walked through the what and why, to become more aware of what we’re trying to solve. They’ll adopt validity on their own as a core methodology because it saves them from a lot of hassle with the rest of the Guidelines (among other benefits). But you have to convert tag soup producers in a way that makes sure they stay converted. In a situation like that, influence is a better tactic than coercion, both for the rate of adoption and the goodwill we need from the developer to make sure their product doesn’t still totally suck.

Thanks for that rundown it helps put some stuff into perspective on this end. I’m not sure that unencoded ampersands are the only thing that stops validation though… and I thought WCAG were only guidelines and not mandatory or law anyway. This seems to be creeping in that it’s law. If it is it’s news to me, here at least. But your reasoning made reasonable sense. My concern is the message that it sent to my competitors, I won’t name a friend, who turned around and said that they were right and that the bar is meaningless. It justified his original position. Anyway I’ll admit the conversation is probably way over my head here…

Matt:

No I wouldn’t make a law out of it either because accessibility is a moving target… I’ve only ever understood WCAG to be a recommendation. Laws change too slow to be flexible enough to address these areas. I don’t think the spec was ever a yoke as such but rather something to aim to try to achieve. It’s a Norty Pig business policy to try to meet these guidelines as best we can. We also make web standards sites by policy as well. Validation is a key throughout the development process because it saves us time and money debugging for one thing. I guess it’s true I may be smearing the line between my web standards practise and accessibility practise.

I particularly found pixeldiva’s explanation gave me a better understanding of what’s behind the move. While I still don’t fully agree that it’s a step forward I can see that it was more than hash cookies that inspired it lol. Also, I admit again, the level of conversation is probably way over my head here… but I’m learning.

As a small business making decisions to invest in following best practise, unlike my competitor, I do naturally wonder on occasion if I’ve made the right decision. Learning takes time and that is money. My competitors are better financed, have more work and are better established. I’m the trenches at about mud level so I go unnoticed perhaps and survive on the edge of going broke. My views, although ordinary, and probably not entirely right, are those of ordinary folk.

Hopefully in time it will be proven that you’re entirely right Matt and I hope so. I really do. I’ve put a lot on the line in the real world for the standards movement that simply won’t pay off if we get a web in the future that doesn’t evolve or move forward. So perceived backward steps scare me.

“invalid markup is indiscriminate, it doesnâ€™t treat disabled people with significantly worse than non-disabled people.”

Are you sure about that? Invalid markup punishes niche user-agents more than mainstream user-agents, simply because niche products don’t have the resources to spend all their time working around bugs and don’t have the clout to get web developers to test in them.

If invalid markup treats niche user-agents significantly worse than mainstream user-agents, then surely the niche user-agents many disabled people use will be worse off than their fully-abled mainstream counterparts?

Invalid code isn’t *intrinsically* inaccessible, it’s the fact that accessibility is a niche market that makes invalid code less accessible.

I also take issue with this:

“Think about the ramifications of making valid code a legal requirement. Say youâ€™re a Web designer. You leave out a semicolon in a on your home page.

You move a fragment of code from a place where it is valid to where it is not.

You redesign your CMS templates.”

… and so on. All of that is the same: where on earth is QA in your publishing process? Surely at least *some* QA is necessary to fulfil legal requirements? And isn’t finding things like typos and missing semicolons about as basic QA as you can get?

People often don’t realise the very important difference between validity and well-formedness. Well-formedness should be absolute, validity is something to strive for: an unfortunate by-product of UA evolution.

So long as well-formedness is a requirement for conformance, then frankly I’m happy.

Just to show that Matt’s examples aren’t far-fetched, here’s my experience. I work on a local government website. It has an well-recognised award for its accessibility, it’s totally standards-based and every page I’ve tested validates as XHTML 1.0 Transitional. Almost.

It’s built using ASP.net, and ASP.net puts a script tag in every page which uses the old “language” attribute instead of “type”. Does that affect its accessibility? Absolutely not. Does it affect our accessibility ranking in an annual national survey, which is read by senior managers and released to the press? Yes, it does.

They rate us as WCAG A, not AA, which doesn’t look good when we proudly boast our accessibility award. If we didn’t even make it to A thanks to that little script tag, it wouldn’t be fun.

Validity is important and we do all we can to achieve it, but it’s not WCAG’s job to enforce it.

Incidentally, ASP.net 2.0 claims to be XHTML compliant, so that should solve our problem. Here’s hoping…

Roger I think there will always be alot of confusion over what is valid vs well-formed but disagree that it would make more sense with an example that is invalid but well-formed.And I dont know how many times I ve said the same thing alough not a million times but your right accessibility is process, not product.But in the end I agree with Mo “So long as well-formedness is a requirement for conformance, then frankly Iâ€™m happy”

I can’t understand why it isn’t possible to have a middle ground. Whether as a Level 1 or Level 2 priority, there should be a guideline that reads something like:

“Any deviations from formal grammars must be proven to have no diliterious effects.”

That is almost a circular definition, but does at least make it clear that validation is important, while still allowing deliberate extensions and/or deviations. It also fits the style of WCAG 2 better than that of WCAG 1

I have now read a number of these posts after comming here from Joe Clarks “To Hell with WCAG 2.0”

I must say though that one thing I am having problems with is following your position. I find myself thinking you are pro-something, then hit a clear anti-something, have to go back, not follow what is being said, and jumpt ot the conclusion to decide your psition and go back to read again… LOL

Maybe it is because I was forced up early, and spent three hours reading things refferenceing WCAG 2.0 and am suffering burnout. Maybe no one but me is having this problem.

Either way I do find these posts as being very worthy of reading and bookmarking… guess it just needs to be done with a clear head. So keep it up, I end to be opinionated and have been taught so to speak by many commenting here. So I am enjoying seeing “the other side” and having to re-think much of what I held for true and right.