A review of the Web Content Accessibility Guidelines 2.0, May 2007 Working Draft

By Patrick Lauke | June 11th, 2007 | Filed in Accessibility, Accessibility TF, Action, General, Legal, Validation, W3C/Standards Documentation, Web Standards (general)

Skip to comment form

In last month’s Interview with Judy Brewer on WCAG 2.0, we read that:

WCAG 2.0 went through several Public Working Drafts in recent years, and a Last Call Working Draft in 2006. Each Working Draft was sent out for public review — altogether to hundreds of individuals, organizations, and lists around the world where people had expressed interest. You’ll see the results of these comments in an updated Public Working Draft in the next month.

It’s been over a year since the request for review on the Last Call Working Draft of WCAG 2.0 (April 2006) originally went out. Many readers will remember the general level of dissatisfaction, or just plain bewilderment, that it provoked. So, has the latest version — Public Working Draft of WCAG 2.0 (May 2007) — taken on board the comments and criticisms that were raised?

Note: this article only looks at the differences between the previous and the current working draft of the guidelines. It is not meant as an introduction to WCAG 2.0, nor as an analysis of how it differs from WCAG 1.0.

Process, structure and language

In a very welcome move towards clarity and transparency of process, the WCAG working group has published its Summary of Issues, Revisions, and Rationales for Changes to WCAG 2.0 2006 Last Call Draft. This is an excellent starting point for evaluating how work on the guidelines has progressed over the last year, and most importantly why certain decisions, which are reflected in the latest version, were taken.

It’s worth noting first of all that the working group seems to have realised that there’s still work to be done on these guidelines, and has therefore “demoted” them from “Last Call Working Draft” to just “Working Draft”.

It’s clear that the guidelines have undergone quite a bit of reorganisation and editing. Many elements that were present in the previous version have been removed or split out to separate documents. The internal structure of the document has also been streamlined — all the conformance information has now been moved to the end of the document, meaning that readers get to the actual guidelines and success criteria much quicker.

Purely from a layout point of view, the guidelines and success criteria themselves are far easier to skim read. Each SC is denoted by a short term or sentence that signals what it applies to (for instance Use of Color). Though, at their core, most guidelines and success criteria remain unchanged, their wording has been revised to make them more immediately understandable, aided in no small part by the fact that all the bizarre new terminology of the previous document (Web Unit, Authored Unit, Authored Component, etc) has been removed in favour of clear, simple, and commonly used words.

Baselines

One of the big points of contention of WCAG 2.0 was the newly introduced concept of baselines. Although the intention behind the concept certainly had a lot of merit, many reviewers felt that it was ripe for abuse by developers and site owners. The latest draft ditches baselines, but reformulates the underlying idea in terms of choosing technologies that are accessibility supported. Rather than saying “users must have user agents and assistive technology that can deal with these technologies we’ve chosen”, the onus is now more explicitly on developers to ensure that the technologies they’ve chosen are in fact known to be supported. The concept is the same, but it’s been turned around far more explicitly in favour of the users, and it’s far less likely to be misinterpreted (maliciously or not) by developers.

Cognitive disabilities

The previous version came under criticisism for failing to adequately address the needs of users with cognitive and learning difficulties. Although the situation still isn’t much better in the new version, this is at least aknowledged in the introduction.

Although some of the accessibility issues of people with cognitive, language, and learning disabilities are addressed by WCAG 2.0, either directly or through assistive technologies, the WCAG 2.0 guidelines do not address many areas of need for people with these disabilities. There is a need for more research and development in this important area.

The introduction is also quite realistic in stating that:

These guidelines [...] are not able to address the needs of all people with disabilities.

Levels and conformance

A holdover from WCAG 1.0, the new version finally does away with the unnecessary dual system for categorising conformance levels (A, AA, AAA) and individual success criteria levels (1, 2, 3), adopting the former for SCs as well. The definitions for these three conformance levels have also been rewritten and expanded. Rather than simply stating that one level achieves a minimum level of accessibility while another results in an enhanced level of accessibility, as was the case in the previous version, these definitions now focus on the impact that a certain level has on end users. The definitions further aknowledge that conformance with a certain level may require certain aspects of a web page’s visual presentation and content to be changed or adapted.

In a note on conformance, the previous version stated that:

Because not all level 3 success criteria can be used with all types of content, Triple-A conformance only requires conformance to a portion of level 3 success criteria.

The new version reverts back to the original WCAG 1.0 model, requiring all AAA success criteria to be fulfilled in order to claim conformance to that particular level. However, it concedes that the AAA criteria place tighter limits on both presentation and content, which means that some types of content may not be able to satisfy this level of conformance (emphasis added).

The guidelines still attempt to make the point that, despite the use of the word levels, there is no implication about the relative importance of success criteria. However, this passage from Gez Lemon’s article WCAG 2: The difference between a level and a priority (posted in January last year, in reference to the pre-Last Call version) still rings true:

For any given level, all success criteria for that level, and the success criteria for all levels below, must be met before a conformance claim can be made. Therefore, each level is inferred a level of importance; otherwise, they would all be considered equally important, and ranked only as to whether or not they can reasonably be applied to all web resources.

It may be that the only way around this conundrum is for the guidelines to accept that, by their very nature, levels imply a hierarchy, and that in most cases authors will focus on fixing any major bloopers (failures of level A success criteria) first, as they are more important in order to make a site more accessible to a potentially larger percentage of visitors, before going on to the higher levels (particularly if, by admission of the guidelines themselves, these levels may actually have an impact on the overall design of a web page).

Scoping

Still on the subject of conformance, the explicit section on the Scoping of conformance claims — with its ill advised example A site has a collection of videos for which it is not required to and does not want to claim accessibility which seemed in direct contradiction to the preceding line Scoping cannot exclude a particular type of content (for example, images or scripts) since it would allow exclusion of individual success criteria — has disappeared. There are still references to a site’s ability to specify which URIs a conformance claim applies to (and, by inference, which URIs are effectively out of scope) and the possibility of excluding certain web pages or sections with a Statement of partial conformance, particularly when dealing with user contributed content and aggregation. The loophole is still there, but it’s not served on a silver platter to the casual reader.

Accessible alternatives

Speaking of loopholes, Guideline 4.2 – Ensure that content is accessible or provide an accessible alternative is gone from the latest version. Nonetheless, the concept of alternative versions is still found in the Conformance Requirements section. As with the previous point, it’s an improvement not to have an explicit guideline that sanctions a perceived “easy way out”, as was the case in WCAG 1.0 — although, in fairness, even then checkpoint 11.4 clearly stated If, after best efforts, you cannot create an accessible page, provide a link to an alternative page (emphasis added). The editorial note in WCAG 2.0 relating to this part of the Conformance Requirements does explicitly elicit further suggestions and comments on the whole alternative content issue, as the working group recognises that, in its current form, it may not be ideal.

Validity

One final point to note is that, despite much uproar about this in the previous version, validity (the requirement to create web pages that, to use WCAG 1.0 parlance, validate to published formal grammars) is still out. Reading the summary of changes, the rationale for this move is explained as follows:

The working group looked at this topic carefully over an extended period of time and concluded that requiring strict adherence to all aspects of specifications does not necessarily result in an increase in accessibility. For example, it is possible to create invalid pages that present no accessibility barriers. It is also possible in certain situations to enhance accessibility through the use of markup that is not part of the specification.

[...]

The working group must work within its charter and only include things that directly affected accessibility. Some aspects of use technologies according to specification and validity do relate to accessibility. However, others do not. So requiring validity would take us beyond our charter.

Although the working group cannot require validity, it recommends it and it is our #1 sufficient technique listed for conforming to SC 4.1.1.

There is no doubt that the final decision was, at least in part, politically motivated (and pushed through) by certain influential members of the working group. Personally, I would have loved to see validity enshrined in the normative guidelines, rather than just in the informative techniques documentation … yet the pragmatist in me aknowledges that the guideline isn’t all that bad, requiring well-formedness and adherence to a language’s general syntax rules — albeit in a very clumsy fashion, by way of elements with complete start and end tags and nested according to their specifications. The wording is certainly an improvement over the vague requirements for Web units or authored components to be parsed unambiguously.

Summary

There are many more aspects of the guidelines that have changed since last year’s version — I’d strongly recommend that interested readers go through the summary of changes and compare the last two versions of the guidelines side by side. Overall, things may still not be perfect, but this latest draft can, without a dobut, be seen as a marked improvement. Though it will still be a while before we see WCAG 2.0 become a stable and official W3C Recommendation, the signs are good that it’s on course and heading in the right direction. Have a look for yourself, and make sure you send your comments and suggestions on the current version of WCAG 2.0 to the working group by 29 June 2007.

Addendum on techniques and community involvement

This short article only concentrates on the core guidelines document itself, as this is the only normative document in the WCAG 2.0 suite. Once developers get down to implementing the new guidelines, they’ll mostly be referring to the Techniques for WCAG 2.0 (by way of the WCAG 2.0 Quick Reference) … and those are admittedly in a less than optimal state at present. We’ll be posting more on this soon, but it’s worth reiterating that the techniques are only informative. The intention of WAI is to update these regularly (around once a year) to reflect current best practices, based on material submitted by the developer community — a process that WaSP, working closely with the WCAG WG, will be actively involved in.

Your Replies

#1 On June 11th, 2007 4:10 pm Accessify: latest news / Quick review of WCAG 2.0, May 2007 Working Draft replied:

[...] Read the full article: A review of the Web Content Accessibility Guidelines 2.0, May 2007 Working Draft. [...]

#2 On June 12th, 2007 1:25 am mcdave.net » links for 2007-06-12 replied:

[...] A review of the Web Content Accessibility Guidelines 2.0, May 2007 Working Draft – The Web Standards Project (tags: wcag accessibility accesibilidad guide) [...]

#3 On June 24th, 2007 4:12 pm Mental Workload for Paged and Scrolled Documents- Standards Schmandards replied:

[...] All text on a single web page and the standard browser scrollbar to move forward in the page. (Example: A review of the Web Content Accessibility Guidelines 2.0, May 2007 Working Draft). [...]

#4 On July 6th, 2007 9:39 am Ivo replied:

When do you think will WCAG 2.0 become a official w3c recommendation? I think, that this will a little time…

Best regards,

Ivo

#5 On July 8th, 2007 1:28 am Assistive Technology replied:

I hope the standard will change so all people with disabilities (also cognitive) can look for a more accessible web.

#6 On July 10th, 2007 3:38 am OPC Toolbox » Blog Archive » A review of the Web Content Accessibility Guidelines 2.0, May 2007 Working Draft replied:

[...] Patrick Lauke reviews the new working draft of WCAG 2 Note: this article only looks at the differences between the previous and the current working draft of the guidelines. It is not meant as an introduction to WCAG 2.0, nor as an analysis of how it differs from WCAG 1.0. [...]

#7 On July 18th, 2007 5:17 am zar replied:

Thx for keeping us informed. I think, that this will a little time, that WCAG 2.0 become a official w3c.

#8 On August 9th, 2007 6:19 pm Ajeet Khurana replied:

I am concerned that issues related to accessibility are more about jingoism than reality. So far, web standards for accessibility are more about sloganeering than about any serious advancement. All the accessibility solutions seem to be in the domain of hardware providers.

Return to top

Post a Reply

Comments are closed.

Working together for standards The Web Standards Project