When the W3C’s Web Accessibility Initiative recently put one of their technical recommendations, a new version of the Web Content Accessibility Guidelines or WCAG 2.0, in Last Call Working Draft status with a deadline of only a few weeks, it caused outrage in the web community. First there was Joe Clark’s article To Hell with WCAG 2.0, soon followed by various other initiatives, and suddenly, the deadline for public review was extended from May 31 to June 22. But don’t consider it a victory, for while we may have more time, there is still no guarantee that the proposed spec will actually be improved as much as we feel it needs to.
The original Web Content Accessibility Guidelines explained how web authors (designers, developers) could make the websites they produce more accessible. With WCAG 1 being over seven years old, the need to create a new version was obvious. The guidelines themselves offer practical as well as theoretical guidance that you can should be able to use to measure and analyze your site’s accessibility. What they utterly fail to accomplish, however, is to make the issue of web accessibility any more clear to you!
There have been countless complaints about existing CSS and HTML specifications for the highly technical language that makes it difficult for a web designer or developer to read and understand, let alone implement. But there is good reason why those specifications are so technical: they were written in large part for browser developers, not web designers. When it comes to accessibility, those browser developers (or creators of media players, assistive technologies and other user agents) have an accessibility document of their own: the User Agent Accessibility Guidelines. To make the whole thing complete, developers of authoring tools have the Authoring Tool Accessibility Guidelines. The latter applies to many more applications and tools than most people think, just look at who ATAG is for to get an (incomplete) idea of the versatility. The WCAG however are aimed exclusively at people who create websites, whether they do that in full (design, markup, CSS and content) or solely through writing content that ends up as part of a larger website. Naturally, you would presume that the WAI is aware of its target audience, but as Joe Clark’s article extensively points out, this doesn’t appear to be the case.
In fact, just going through Joe’s piece from a (standards-conscious) designer/developer’s point of view, you’ll quickly discover that WCAG 2.0 may just be your worst nightmare when it comes to web accessibility. If you’re a web standards-enthusiast in today’s world, you belong to a small but growing group that is becoming increasingly aware of how tricky accessibility on the web really is, but at least you know how to deal with a lot of common accessibility pitfalls. You also know that valid markup will help make pages more accessible, yet that it’s no guarantee for a truly accessible page at all. WCAG 2.0 is not going to make your life any easier, instead, it’ll make it much more difficult and confusing.
The real victims
Accessibility, in the end, is not about the web designer or developer, or the people developing browsers or authoring tools; it’s about the people with disabilities, and these people will suffer from WCAG 2.0 the most.
Being the normative technical report issued by the W3C, we run the risk of WCAG 2.0 being adopted unquestioned by many governments and large corporations. We shouldn’t blame them for doing so, because it’s not their duty to conduct a research into the quality, effectiveness and usability of the technical reports that the W3C produces. It is their duty, however, to make use of these reports in a conscious, sensible manner. In other words, it is reasonable to expect them to use their heads when working with these reports. The NFB vs. Target lawsuit shows that this isn’t a given.
What may happen is that many government and corporation websites will try to “pass” WCAG 2.0, but through doing so become no more accessible than they were before (or even worse, less accessible). People with disabilities will continue to experience a frustrating rendition of the internet, but they will have little hope for the situation to improve any time soon.
Then there’s the new wave of web professionals (a group I like to consider myself a part of). Some of us will be fresh out of college or even high school, whilst others may have opted to skip college altogether. Needless to say, we are far away from being academics, which makes the WCAG 2.0, Understanding WCAG 2.0 and Techniques for WCAG 2.0 documents, ironically, extremely inaccessible to us. It’s not that the language used in any of these documents is impossible to read for someone without a degree in English, it’s that it’s really not useful.
They’re hard to read, ridiculously extensive, confusing, overly ambiguous and tedious. They hardly encourage budding, young web professionals to read through and use the guidelines for what they’re intended to do: guide you in creating accessible websites. In fact I think it’s more likely the opposite will take place: the documents will turn that young and budding web professional away from the accessibility guidelines. And if English is not your first language, you’re in an even worse position. There are no translations of any of these documents available at this time, and judging by the sheer size of them I’m not expecting there to be any for another while.
A different but equally important issue is that the documents are incredibly time-consuming: roughly 5% of them contain actual, practical advice that you can use; the rest is just a kind of failed foreplay.
Take, for example, Success Criterion 3.1.1:
The primary natural language or languages of the Web unit can be programmatically determined.
Imagine for a moment that you don’t already know about the lang and dir attributes when you read that. Would this make any sense to you? Would this tell you how to create your code in a way that it conforms to that criterion? Not likely, so you click on "How to meet 3.1.1" which takes you to the relevant part of the Understanding WCAG 2.0 document. There, you have to wade through two pages of unhelpful explanations on the issue, before briefly getting to some practical advice on what it’s all about and how to implement it. By now, you’ll have spent about five minutes only to learn that you need to use a lang attribute on the html element to specify the primary language of your document.
Accessibility is an increasingly important issue, as the web grows ever larger, both metaphysically and in terms of the number of people using it, and our responsibility as web producers becomes more important too. We can’t let the web continue to grow as a mess of tag soup.
Web Accessibility 2.0?
With all the problems we’ll get with WCAG 2.0, many people will take it into their own hands to define web accessibility and make their own guidelines — for instance, guidelines that we can actually use. In fact, Joe Clark’s WCAG Samurai is already one such example in the real world – they’ve been (secretly) working on it for over a year already, and will be publishing errata of their own for the WCAG 1 and, possibly, 2 documents.
There will be more examples; bloggers have long been writing accessibility tutorials, and several books on (modern) web development include a lot of information on accessibility from a practical point of view.
Is this going to be a new trend? Probably not — far too few people care that deeply about accessibility to make it a real trend. Should we be concerned about this development nonetheless? Definitely. It speaks volumes that there are such tremendous problems with WCAG 2.0, that it has led to these developments in the first place. It seems the Web Accessibility Initiative has lost sight of what they’re meant to do, which is to help make the web a more accessible place for all. A recourse to accessibility vigilantism may be our only choice…
What’s becoming very clear from all of this is that web accessibility is not for the faint of heart. Practical advice seems scarce in WCAG 2.0, but the theoretical advice is very hard to decipher and make any sense of. That, in itself, may be an even bigger problem, because web accessibility will never restrict itself to a set of testable guidelines. It will never restrict itself to things a machine can test, because it’s about human disabilities and those come in a million-and-one shapes and forms. They are far too complex and case-dependent to be machine-testable.
Fortunately, all is not lost: it just takes a different mindset to tackle web accessibility. Unlike with CSS and XHTML, you don’t have the luxury of a real “Accessibility Validator” — there are some tests you can run your site through, but they are limited and superficial. Rather than relying too heavily on these, a good dose of imagination and a few tips may for now be all you need to improve the accessibility of your websites.
Not everyone has a colleague, friend or family member with a disability (let alone multiple people all with different disabilities) that they can ask to test their site’s accessibility. What you do have available to you, without question, is your imagination. You can imagine that someone with bad motor skills may have trouble clicking very precisely with a mouse, so increase your clickable areas wherever possible. You can imagine that someone with bad vision will not see weak contrasts very well, so increase your contrasts.
There are also tools you can use: Fangs is a screen reader plugin for Firefox (unlike most other screen reader software, Fangs is free). Turn your monitor off and try to navigate your own website. Use the Web Developer Toolbar to disable and enable JavaScript, CSS and images, and see how your site functions under all conditions (and combinations).
Put your mouse aside and try to navigate through your entire website using just the keyboard. Now try that again in Internet Explorer. For accessibility, it is imperative to remember that not everybody uses a browser that comes with a lot of handy features such as Type-Ahead-Find (or Type & Find). Likewise, remember that not everybody knows how to configure their browser for optimal performance and usability - a lot of people use Internet Explorer with its default settings. What may seem like a non-issue to you because you can name five workarounds off the top of your head may be a great hurdle to others.
Use unobtrusive JavaScript practices. Make sure your scripts activate only in circumstances where they should, and where they will not hinder others. Don’t use JavaScript-links (the non-protocol a href="javascript:…"). Don’t write links that don’t point anywhere and rely on JavaScript to send the user to the correct location (a href="http://www.theitarticles.com/#" onclick="…"). Don’t rely on JavaScript being enabled for any kind of navigation or form submissions. People will navigate your website in their own ways; don’t force them to do it your way.
If you must use image replacement techniques, use them in accessible ways (stay away from display: none; as it’s ignored by screenreaders). If you want to use skip links, either make them visible or invisible at all times - a blind person will not benefit from it appearing on a mouseover somewhere, and a seeing user will not know there’s a skip link to benefit from unless they coincidentally come across it. Keyboard users may likely tab through the link as they start tabbing quickly to get to the content, if they don’t see right away that there is a skip link they can use.
I could go on and on, but the most important thing is to keep in mind that web accessibility is, in almost all cases, a gradual process. It is unlikely that you’ll get it right from the start, but imagine all possible conditions that a user can browse your site under and try to make everything work as well as possible, to the best of your abilities. Ignore the official guidelines if you can’t make sense of them - you don’t have to understand them to be able to write accessible websites. Web Accessibility 2.0 is the accessibility of the real world situations, of real world testing, and we’ll all define it together as best as we can.
Source: thinkvitamin.com
