Standards-wielding maniacs
The advent of web standards has created a new breed of self-proclaimed experts. Wielding the W3C online validator tool they attack webmasters, site owners and and anyone without the Xhtml logo in the page footer. However, changing your website to make it pass thorugh the W3C validator does not guarantee accessibility.
Standards has become an easy battelaxe. They are clearly written, define a specific set of rules and are therefore easy to test. However, as you might have noticed from my previous writings, it is not that simple. I have met many webmasters that have complained about the amount of phone calls, e-mails and marketing material they receive from companies that want to make their website accessible. Many of these have just run the website in question through the W3C online validator.
The problem here isn’t about standards. Anyone who can read can make a website follow one or more standards. The problem here is that it is possible to make an inacessible website even if you are following e.g. the Xhtml standard. Making your website pass through the W3C validator does not guarantee accessibility.
Many organisations have made the wrong decision to hire standards-fanatics to change their website only to see that accessibility has in fact decreased. Sure, the website passes through the validator, but have you LISTENED to what it sounds like for someone using a screen reader? This is what separates good consultants from bad ones.
A common mistake is to blindly follow the advice of these consultants and spend the entire budget on technology changes to comply with the W3C validator. Did you know that just by working with content you can easily improve accessibility on your own? In fact, sometimes your dollars are better spent on something else than blindly following standards.
Have you been caught up in a discussion about details in semantics? Maybe a standards expert advised you to change your html for some obscure element. Please beware that there are a lot of elements that not yet are interpreted by any browsing device. This means you are designing for nobody. Your standards expert will tell you that those devices will come in the near future. At that point it is likely that you have a completely different web site published through a new content management system. Thus, you have made an effort in vain.
Do you want more? Mike Davidson has an interesting discussion on this heated topic.
A couple of years ago, I got a screen reader user to make a tape of his browsing experience on http://www.upmystreet.com and then published the results as mp3.
http://www.whitelabel.org/archives/000332.html
I think the fangs may be the most useful tool I’ve seen in a long long while. Well done.
I’m not aware of a single HTML element that no browser can render. If you’re referring to obscurantisms like dir or summary on table or hreflang, then perhaps yes. However, I interpret any claim that browsers do not understand such attributes as really meaning that IE6 on Windows doesn’t.
I don’t see the value of this article at all except as another futile and readily-refuted instance of a claim that standards don’t matter. Merely as a starting point, you can have a page that passes WCAG Priority 1 with invalid code, but I rather doubt it will actually be accessible to a screen-reader user. Meanwhile, a deaf person might have no trouble at all. The entire discussion is *contingent*, you see. There are many complicating factors.
I’m not convinced that any informed accessibilitista or standardista would make the claim that the mere adherence to standards guarantees you anything. It is, however, a prerequisite for many things.
Joe, thank you for your comment.
In the article I am talking about browser devices and how they interpret elements. I agree that most browsers have no problem displaying the bulk of xhtml elements, but take for example the following elements:
dfn, cite, address, kbd, varWhat device do you know of thet interprets them and informs the user of their meaning? Jaws, IBM Home Page Reader and Lynx (many braille terminals use Lynx for rendering) ignore them. Who benefits from that markup?
The point I am trying to get across is that you should consider how you prioritize your information development efforts. In my opinion there is an unhealthy tendency towards overemphasizing the importance of W3C validator compliance compared to the basics of information publishing such as having a decent CMS and an organization that makes sure information is published to the web.
Do not get me wrong. I am all for following the W3C recommendations. But there are many things that have a higher priority if you want to get the biggest bang for your accessibility budget.
Regarding claims from standardistas my experience differs from yours.
Lynx renders the elements you mentioned. The other user agents, if they ignore them, are deficient. We know that Jaws has a lot of work to do to support basic HTML.
Typical Braille displays are driven by screen readers, not terminal-mode browsers like Lynx.
Joe, you are still talking about displaying elements. Please have a look at this Lynx screenshot. As you can see Lynx has no problem displaying the elements. However, it does not communicate their meaning despite the proper markup.
Other user agents typically work the same way. Calling them deficient does not change the way they work.
Jaws is the most widely used screen reader. This is a fact and should be taken into consideration when designing web sites just like you sometimes have to design specifically for Internet Explorer.