WCAG 2.0: The new W3C accessibility guidelines evaluated
- From: "BlindNews Mailing List" <BlindNews@xxxxxxxxxxxxxxx>
- To: <BlindNews@xxxxxxxxxxxxx>
- Date: Thu, 4 Oct 2007 22:36:33 -0400
ProgrammersHeaven.com
Tuesday, October 02, 2007
WCAG 2.0: The new W3C accessibility guidelines evaluated
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.programmersheaven.com/2/W3C-accessibility-guidelines-evaluated
BlindNews Mailing List
Subscribe: BlindNews-Request@xxxxxxxxxxxxx with "subscribe" as subject
Unsubscribe: BlindNews-Request@xxxxxxxxxxxxx with "unsubscribe" as subject
Moderator: BlindNews-Moderators@xxxxxxxxxxxxx
Archive: http://GeoffAndWen.com/blind
RSS: http://GeoffAndWen.com/BlindNewsRSS.asp
More information about RSS feeds will be published shortly.
Other related posts:
- » WCAG 2.0: The new W3C accessibility guidelines evaluated
