[Nfb-web] WCAG accessibility guidelines from W3C (fwd)

[David Andrews]

>
>New Media Knowledge (UK)
>Wednesday, November 29, 2006
>
>WCAG accessibility guidelines from W3C
>
>By Trenton Moss
>
>The second version of the Web Content Accessibility Guidelines 
>(WCAG) is in final working draft and will soon be officially 
>released. Version 1 of the guidelines came under much criticism for 
>being vague, full of jargon and extremely difficult to use. The W3C 
>has been working on version 2.0 of the guidelines for over 5 years 
>now, but has it been worth the wait?
>
>What's good about WCAG 2.0?
>
>There have certainly been a number of improvements made to the new 
>guidelines. This is of course to be expected - after 5 years you 
>would expect some improvement! Some of these improvements include:
>
>Outdated guidelines removed
>
>A number of guidelines from WCAG 1.0 are well out-of-date. 
>Unfortunately, web developers still implement these out-dated 
>guidelines because they don't know otherwise. Rather than go on an 
>accessibility training course and learn 'real-world' accessibility, 
>many web developers and manager tick boxes against guidelines.
>
>Some of the out-of-date WCAG 1.0 guidelines, which have been removed 
>from WCAG 2.0 include:
>
>1.5 - Provide equivalent text links for links within client-side image maps
>5.6 - Provide abbreviations for table header labels, if you use these
>9.5 - Use accesskeys (keyboard shortcuts) for important links
>10.3 - Don't use tables with more than one column for layout
>10.4 - Make sure form fields aren't empty by default
>10.5 - Ensure different links have non-link text between them
>(Please note, the above isn't the exact wording of the guidelines - 
>each of the original guidelines has been translated from the 
>official W3C guideline into more easy-to-understand language.)
>
>The above guidelines have all been removed from WCAG 2.0, so 
>shouldn't be adhered to.
>
>Good real world techniques provided
>
>The document, Techniques for WCAG 2.0 replaces the previous 
>techniques document, and is actually much better. It provides a list 
>of common failures, which the previous version didn't, and actually 
>offers some excellent examples of common errors.
>
>The other major improvement in this techniques document is that the 
>examples provided are far more real-world. The WCAG 1.0 techniques 
>document used text such as PortMaster 3 with ComOS 3.7.1 in their 
>examples, but who has any idea what this means? The new document is 
>far better in this respect, using examples such as phone numbers and 
>calendars, for example.
>
>The techniques document also provides some clever recommendations, 
>which accessibility guideline box-ticking developers wouldn't 
>perhaps have thought have. For example:
>
>How to open a link in a new window using unobtrusive JavaScript
>Displaying decorative images through CSS
>Combining text and its adjacent image in the same link
>Providing a heading at the beginning of each section on the page
>..And many more! Do have a good look at the WCAG 2.0 techniques 
>document as there's lots of useful guidance here using quite 
>easy-to-understand examples.
>
>New guidelines included
>
>A number of new guidelines have been brought into WCAG 2.0. Some of 
>these guidelines are totally new whereas others were hinted at, but 
>not specifically stated, in WCAG 1.0. Some examples include:
>
>Providing text-based error messages for forms
>Ensure all pages have a descriptive title
>Background noise can be turned off
>For a full list of brand new guidelines that don't map to any 
>version 1 guidelines, have a look at the W3C's Comparison of WCAG 
>1.0 checkpoints to WCAG 2.0.
>
>What's not good about WCAG 2.0?
>
>So there certainly have been some improvements made to the W3C 
>accessibility guidelines. But is it all good news? Have the problems 
>associated with WCAG 1.0 been eliminated for this version 2 of the 
>guidelines? Well not quite, as there are still a number of problems...
>
>Verbose and jargon-filled language
>
>One of the main criticisms aimed at WCAG 1.0 was the complexity of 
>the language used. Have things improved? Hardly! Pretty much every 
>paragraph is littered with jargon that the average web developer or 
>web manager would be left with no clue as to the meaning.
>
>Clearly aware of the level of jargon, the W3C have made complex 
>terms green underlined links, linking to definitions. This is all 
>well and good in theory, but when most sentences are broken up with 
>one or two links it makes reading these sentences quite difficult.
>
>Even worse though, is that the definitions are just as jargon-filled 
>and difficult to understand as the term being defined! For example:
>
>Authored unit - Set of material created as a single body by an author
>Programmatically determined - Determined by software from data 
>provided in a user-agent-supported manner such that the user agents 
>can extract and present this information to users in different modalities
>Specific sensory experience - A sensory experience that is not 
>purely decorative and does not primarily convey important 
>information or perform a function
>Web unit - A collection of information, consisting of one or more 
>resources, intended to be rendered together, and identified by a 
>single Uniform Resource Identifier (such as URLs)
>Ironically, there's even a definition provided for the word 'jargon'!
>
>Furthermore, it seems that some jargon used in WCAG 1.0, which 
>webmasters have gotten used to, has been replaced with equally 
>incomprehensible words. For example, we no longer have Priority 1, 2 
>and 3 to aim for - instead we now have success criteria level 1, 2 and 3.
>
>Awful usability
>
>Another major criticism of the WCAG 1.0 guidelines was how difficult 
>it is to find specific guidance and answers. It doesn't take too 
>long to discover that the WCAG 2.0 guidelines quite clearly offer 
>the same low level of usability.
>
>Reasons for this poor usability include:
>
>The level of jargon and complexity of language is truly phenomenal 
>(as outlined above)
>The text is littered with links making it very difficult to read
>The two main documents, Understanding WCAG 2.0 and Techniques for 
>WCAG 2.0 are 164 and 363 pages long in total (when doing a print preview)
>If only the W3C carried out basic usability testing of how people 
>actually use (or are unable to use) these guidelines! What they'd 
>undoubtedly find is that users won't understand most guidelines and 
>will end up blindly clicking links to find out how to meet these guidelines.
>
>As with WCAG 1.0, clicking on most links from the WCAG 2.0 
>guidelines simply takes users into the middle of massive pages full 
>of difficult-to-understand text. The text, of course, is densely 
>littered with links. Users will probably click on a link again in 
>the desperate hope that they'll somehow find some text that clearly 
>and succinctly explains what they need to do. They'll usually be disappointed.
>
>Organising the massive amount of content available is certainly not 
>an easy task - but why not, as a start, split up these massive 
>documents into more manageable and less intimidating sets of smaller 
>documents? Then, carry out some usability testing, refine, and test again.
>
>Useful guidelines gone
>
>Although there are a number of useful, new guidelines in WCAG 2.0, a 
>number of important guidelines from WCAG 1.0 have been removed or 
>are only vaguely referred to. These include, but aren't limited to:
>
>3.1 - Avoid embedding text within images.
>3.2 - Create documents that validate.
>3.3 - Use CSS and not tables for layout.
>3.4 - Ensure text is resizable.
>12.3 - Divide large blocks of information into more manageable 
>groups where natural and appropriate.
>13.8 - Place distinguishing information at the beginning of 
>headings, paragraphs, lists, etc.
>14.1 - Use clear and simple language.
>(Please note, the above isn't the exact wording of the guidelines - 
>each of the original guidelines has been translated from the 
>official W3C guideline into more easy-to-understand language.)
>
>Particularly worrying is the removal of the final three guidelines, 
>all of which relate to the accessibility of content. A major part of 
>any website's accessibility, and one that's often overlooked, is the 
>site's usability and how the content is written and structured.
>
>Accessible content is crucial for all special needs users, 
>particularly those with learning difficulties and dyslexia. Perhaps 
>the reason these guidelines have been removed is because content 
>guidelines are fluffier and harder to measure than technical 
>accessibility guidelines. Whatever the reason, this is not a good 
>step for accessibility.
>
>Technology neutral and the concept of the baseline
>
>WCAG 1.0 states quite clearly that alternatives to JavaScript, PDFs 
>and Flash must all be provided, as assistive technologies such as 
>screen readers can't access these. Although this was generally true 
>in 1999, it's not the case now, and nowadays JavaScript, PDFs and 
>Flash can all be made accessible to most assistive technologies. 
>(Remember, 'can be' is not the same as 'are'.)
>
>Version 1 of the accessibility guidelines became quite outdated 
>rather quickly. To prevent this from happening to version 2 of the 
>accessibility guidelines, the W3C have attempted to make WCAG 2.0 
>technology-neutral. Sounds sensible as now the guidelines won't 
>become outdated so quickly, right?
>
>In practice, what this means is that the WCAG 2.0 guidelines are 
>extremely vague. So vague, in fact, that they're almost unusable as 
>they talk in such generic terms.
>
>Additionally, the concept of the baseline has now been introduced, 
>where by webmasters can claim which technologies they assume are 
>supported by site visitors' browsers. So, if you build a website 
>entirely in Flash and say that Flash is part of your baseline, your 
>website can conform with all the guidelines despite the fact that 
>some people won't be able to access your site at all!
>
>Discussion
>
>So, was the wait worth it? We've waited over 5 years for WCAG 2.0 
>and certainly a number of improvements have been made. Worryingly 
>though, the guidelines continue to be very difficult to actually 
>use, further discouraging webmasters from reading them. The extra 
>vagueness of these new guidelines certainly doesn't help either.
>
>The W3C just doesn't seem to get it: People don't generally want to 
>read through hundreds of pages of text to find out how to implement 
>accessible solutions - they just want answers and specific guidance. 
>For most people, accessibility is just one small part of their job 
>and they don't have time for all this.
>
>Webmasters are also now being asked to choose a baseline for their 
>website but how do they even begin to go about doing this!? How 
>would you as a web developer explain the concept of a baseline to 
>senior management? How do you decide what you should do so as to 
>comply with any legal requirements? Unfortunately there's no correct 
>answer to either of these questions.
>
>Solution?
>
>A solution could be that the W3C simply provides specific guidelines 
>for what web developers and managers actually have to do. Much of 
>this information is already there on their website, but it's hidden 
>away in the enormous and intimidating Techniques for WCAG 2.0 
>document. This document could be broken down into manageable chunks, 
>added to and refined, and focus on providing specific, real world guidelines.
>
>Guidelines should be relevant and specific to today's technology, 
>but would be updated on an on-going basis so as to make sure they 
>don't become too dated. Why did we have to wait over five years for 
>version 2.0? Why couldn't we have received versions 1.1, 1.2, 1.3 
>and so on during this time? This would surely have prevented WCAG 
>1.0 becoming out-dated as quickly as it did?
>
>Most importantly though, the whole WCAG 2.0 section on the W3C 
>website needs to have usability testing carried out on it. The 
>benefits of usability testing are pretty well known by now, and it's 
>quite clear that the W3C has very little idea how real users are 
>interacting with the website. By carrying out ongoing usability 
>testing, the W3C can learn about its users and ultimately aim for an 
>easy-to-understand and intuitive website.
>
>
>This article was written by Trenton Moss. Trenton's crazy about web 
>usability and accessibility - so crazy that he went and started his 
>own web usability and accessibility consultancy to help make the 
>Internet a better place for everyone. He's extremely good at 
>accessibility consulting and spends much of his time doing DOM 
>scripting & accessible JavaScript.
>
>
>http://www.nmk.co.uk/article/2006/11/26/wcag-20

David Andrews and white cane Harry.