One of the comments I read after our WCAG (Web Content Accessibility Guidelines) 2.0 panel is that it would have been good to have a “what you can go back and do at your place of work now” type summary. Well, I agree that this is often a good thing to do and so I’d like to retrospectively offer a few suggestions on that basis:
- Go read the core documentation now. Ignore the preamble if you can - although you may need to familiarise yourself with some of the new terminology. If you stick to reading the core part of the core document, you may be surprised at how much you understand and how it’s not as bad as it may have been painted to be
- Keep an open mind - don’t believe everything that you read on the web about WCAG 2.0, instead form your own opinions (step 1 here is essential for this)
- Register at Accessify Forum. There’s a great starter for discussing all accessibility matters and certainly a lot less daunting for a relative beginner than registering for the WAI (Web Accessibility Initiative) mailing list
- Make sure your site still stands up to WCAG 1.0 - it’s still the only referenceable accessibility guidelines from the W3C. If your site is still good to go with WCAG 1.0, when 2.0 is finalised you’ll have a lot less to do
- If you work in a team, ask your developers or your management team what they know about accessibility. Do you need to do some education on a general level (without mentioning documentation or version numbers)?
- Take a look at the new WCAG 2.0 Quick Reference. Try it out, put in some realistic baselines and see how it works for you
- Finally (for now at least), remember that you have a very short time now left to comment. The deadline was extended for final comments (as posted here) but that deadline ends on the 22nd. That’s three days from now. Yikes! Find out how you can comment here.
Patrick H. Lauke (redux) wrote:
And to expand a tad more on some of Ian’s points, from my perspective…
As mentioned in the panel, unless there is legislation explicitly mandating that you conform to the letter of WCAG 1.0, don’t try to fervently follow the guidelines for the sake of them; understand the issues, understand what problem they actually try (or, considering they were written in 1999, tried) to solve, and - with an eye on modern best practices - address the issues. This means that certain guidelines can now be considered obsolete; I usually:
- ignore 1.5 - as I don’t normally use client-side maps, and apart from Lynx user agents can handle them fine nowadays anyway
- ignore 10.3 - as this has never been an issue in recent years if the content is marked up correctly
- ignore 10.4 - as discussed ad-nauseam, any modern combination of browser/AT can cope with empty form controls (apart from outdated, and in my view broken, braillers); in fact, pre-filled form fields can be a hindrance, or at least an annoyance, to many users who have to first delete the existing content that was so helpfully added
- ignore 10.5 from a technical accessibility point of view - if you’re debating adding “pipe” characters or similar, why not mark up lists of links as actual lists? if you must have adjacent links in a sentence, can a more natural choice like a comma work (i.e. can you make it fit the natural flow of the language and sentence, rather than artificially adding some printing character just to please automated checkers)? and, for usability reasons, you could increase the spacing/padding/margin of links ever so slightly if you do happen to have adjacent links with just non-printing characters in between…which is more of a usability issue really
- ignore 13.6 in most cases - it’s the user agent’s responsibility to provide better functionality to users to allow them to skip sections, block level elements, etc. it’s up to you (as a usability enhancement, again) if you want to provide a single “skip to the content” link or similar. use at your own discretion, but don’t feel that you *must* obey this rule unquestioned
So, if you start knowingly (and with valid reason) ignoring certain checkpoints, what complaince level should you claim? Well, I’d say: none. I usually mention that I “strive to adhere to WCAG 1.0 AA as interpreted by the web team”…no false claim, but it’s closer to the truth than those “AAA compliant Segala/Bobby/Whatever approved” buttons.
Once WCAG 2.0 comes around for real, I’ll pretty much be doing the same thing: unless mandated explicitly by law, I will draw my own conclusions from the guidelines and use them to inform my decisions in order to make my site accessible to *users*, not to a set of guidelines.
Posted on 20-Jun-06 at 12:28 am | Permalink
Patrick H. Lauke (redux) wrote:
With regards to point 6: realistically, unless you have some very specific requirements (for instance, an intranet-only site where you have control over the technologies available to end users’s desktop machines), I can’t think of a situation in which you’d want to stray off simply having “HTML” as your baseline technology. So, uncheck all the fancy stuff in the Quick Reference and print out this highly abridged overview of WCAG (better still, save it as a real web page to maintain the links…maybe even use it as a basis of an internal web accessibility guidelines document for your internal development team?)
For those instances in which you use technologies outside of your baseline (i.e. having a baseline of HTML, but then adding a Quicktime or SMIL movie), check what the Reference with those technologies enabled would look like, but clearly mark out the additional (optional) technologies so that it’s clear your baseline does not directly require them.
And, to complement it all: if you find the examples (both of success and failure) in the Techniques document too far fetched, erroneous, or simply outdated, you may wish to write your own examples - maybe evene making them specific to your particular site/template/target audience/etc. Again, this will help disambiguate the tech-agnostic, fluffy guidelines for your own benefit and that of your developers.
Posted on 20-Jun-06 at 12:36 am | Permalink
Paul Walsh wrote:
Patrick - perhaps you could expand on your comment “but it’s closer to the truth than those “AAA compliant Segala/Bobby/Whatever approved” buttons.”?
I’d appreciate you pointed me to a resource where I can find a Web page that doesn’t live up to the claims of the site owner as verified by Segala? We will review whatever you find immediately.
Posted on 04-Mar-07 at 11:24 pm | Permalink