WCAG 2.0 – Polishing the rough edges

Only a few days remain for public comment on the recent draft of WCAG 2.0. I’ve compiled some questions and issues and have a short list of things that just don’t make much sense. While I will certainly post my comments to the working group, I thought I’d post some thoughts here for your review and/or clarification first.

I am not intimately familiar with WCAG 2.0. I’ve followed its development and was even accepted at one time as a WCAG working group member, although I’ve ashamedly never really participated. So, I am mostly looking at WCAG 2.0 from an outsider’s perspective. As such, many of my concerns may be entirely due to misunderstanding the language or structure of the guidelines themselves. Yet if I have encountered such misinterpretations, it’s quite likely that someone less familiar with accessibility will have them also.

Jack Pickard has written an excellent writeup on WCAG 2.0. I almost entirely agree with his conclusions (particularly those surrounding validity) and will not address the specific issues that he has brought up.

Overall opinions

The current draft of WCAG 2.0 is good. It’s certainly better than the previous draft. It’s not perfect, but overall, I’m rather impressed. I believe that by polishing a few rough edges, that it will be a very solid set of guidelines that will remain relevant for some time. Now, let’s talk about those rough edges a bit.

Levels

In WCAG 1.0, the priority levels for checkpoints meant something. If you weren’t Level A compliant, you were excluding someone. If you didn’t reach level AA, you might exclude someone. And if you weren’t AAA compliant then some people might have a bit harder time than if you were. Levels were simple and easy to understand.

In WCAG 2.0, a success criteria (SC) at one level is no more important than another, yet the levels “build upon each other”. Huh? So they are parallel, yet there’s a hierarchy? Levels, rather than focusing entirely on user access, now focus on “supporting assistive technology” and “limits on presentation”. Success criteria that provide higher AT support and have less impact on presentation get assigned a higher level. Many SC, such as transcripts and readability, don’t fit this definition at all. Perhaps this change is politically motivated – no one wants to favor one disability group over another (primarily when the largest disability group is the one specifically not addressed by WCAG 2.0)

This rather obscure methodology for levels, unfortunately, gives very little guidance to developers who are interested in accessibility, not merely AT support and presentation constraints. The guidelines simply need to indicate that success criteria at lower levels will have a greater impact on users, because this is precisely how they are being and will be interpreted anyways. On the other hand, this must be done in a way that developers do not automatically discount the Level AAA guidelines as irrelevant as they have done over time with WCAG 1.0.

Alternate Versions

If portions of your site do not conform with WCAG 2.0, you may still claim conformance by providing alternative versions that do comply. While many see this as a large loophole, accessible alternatives are often vital for accessibility. As technology changes, we need to require accessibility while also supporting innovation and the creation of dynamic, interactive content that may not currently support accessibility.

I see no problem with the allowance for alternative versions. Disallowing alternatives will do little for accessibility. Which is better, an inaccessible simulation and an accessible alternative or nothing? If a developer cannot build anything because one version would be inaccessible, then we have no accessibility.

But how do you provide access to those alternatives if the user somehow stumbles upon your inaccessible version? That is the real issue. If someone follows a search engine link and ends up on my inaccessible Flash simulation, how can I direct them to the accessible version if the page they are currently viewing is inaccessible? The working group has thoroughly explained this issue and presented several possibilities for rectifying this issue. The options are:

1. require a link in an accessible manner on the inaccessible page that links to the accessible alternative
2. allow the user to find the accessible alternative based upon the URI
3. provide a common page that links to both versions

1 introduces some technology burdens. The purpose of the accessible alternatives is to allow use of inaccessible technologies. Thus, providing an accessible link in these technologies may not even be possible. 2, in my opinion, is pretty much useless unless a specific methodology for URI structure is required (e.g., “all alternatives must be in an /alt/ directory at the same level as the inaccessible version”). 3 makes a lot of sense, but doesn’t really work if the user never sees this page. As you can see, there is no perfect solution to this problem. Perhaps the best option might be, “use at least two of the following three methods.”

Link context

SC 2.4.4 (Level A): The purpose of each link can be determined from the link text and its programmatically determined link context.

The problem here is really in the wording. “Programmatically determined link context” is defined as being the link and other content associated with the link (e.g., the surrounding paragraph, link title, table headers, etc.). When using the word “and” it seems to suggest that the link text and it’s surrounding context MUST be used. Yes, I know this is a bit nitpicky, but this ambiguity in the language present a barrier for determining Level A conformance.

So if you have a link that makes sense all by itself (even one link alone on a page) and that link has no surrounding context, then it would fail this SC because the required link context is missing. Such a link would, however, pass SC 2.4.8 (Level AAA) which requires the link text makes sense without any surrounding context.

Suggested wording: “The purpose of each link can be determined from the link text or the link text and its programmatically determined link context.” Alternatively, if the link text is considered and specifically defined to be a possible component of programmatically determined link context, then “The purpose of each link can be determined from the programmatically determined link context” would suffice.

The word “purpose” in SC 2.4.4 is also a bit vague here. I interpret purpose to mean what you do with a link (you click it), not to what the link is about. Perhaps “function’ or “target context” or something might be better.

Captions

Success Criteria (SC) 1.2.1 (Level A): Captions are provided for prerecorded multimedia, except for multimedia alternatives to text that are clearly labeled as such.

“Multimedia alternatives to text” are multimedia that present no more information than is already presented in text (for instance, a video of a narrator reading text that is also displayed on the screen). This provision was added to allow for multimedia to mirror content within a page without requiring that multimedia to be captioned. This is partially because the captions may decrease accessibility of multimedia alternatives provided for those with cognitive disabilities. But there’s a big loophole in this approach – a content creator can simply designate the transcript for a video as the content and the video itself as the “multimedia alternative to text”, thus there would be no requirement to ever provide captions for any video that has a transcript.

Additionally, captions are a level A requirement. But the problems with captions are that they:

• are almost entirely inaccessible to screen readers (a potential violation of Guideline 1.3)
• cannot be controlled via keyboard in the majority of media players when embedded in a web page (a violation of Guideline 2.1)
• introduce timing that cannot be controlled with a keyboard (a violation of several Guideline 2.2 success criteria)
• may display at a rate well beyond the “lower secondary education” reading level (a violation of SC 3.1.5 )
• etc.

I’m not saying that captions are bad. The problem is that captions alone do not provide adequate multimedia accessibility to many users. The solution to the problems listed above is to provide a transcript in addition to captions. Unfortunately, WCAG 2.0 minimizes the importance of transcripts.

Transcripts

While transcripts provide necessary accessibility to multimedia content for a wide variety of users, they are only required at level AAA in SC 1.2.7. Transcripts are often the only mechanism for audio and multimedia content to be accessible. They are the only mechanism for someone who is deaf and blind. Again, if WCAG 2.0 defines Levels A guidelines as those that typically “achieve accessibility by supporting assistive technology while putting the fewest possible limits on presentation”, then certainly transcripts should be at least an equivalent level as captions which are at Level A. Captions are less “AT supported” than transcripts and surely greater limits on presentation are present with captions than for a simple link to a transcript. Besides, you do not typically create captions without having a transcript first.

In short, relegating transcripts to level AAA is a mistake.

Of note, SC 1.1.1 does address non-text content and is at level A, but there is an exception for multimedia:

“All non-text content has a text alternative… except if non-text content is multimedia… then text alternatives at least identify the non-text content with a descriptive text label.”

So if a page uses non-live audio only (no video), then this SC applies and a transcript would be required. Perfect! But if the page has archived multimedia (audio AND video), only a text label is necessary. In other words, simply identifying that a video is there and what the video is about would suffice here. That hardly provides deaf or deaf-blind access.

Additionally, under SC 1.2.2 (Level A), transcripts OR audio descriptions are required if the video presents anything visually that is not presented in audio. This is primarily intended to provide screen reader access to visual and interactive multimedia content. However, if audio descriptions are provided, they are of no use to someone that is deaf. And neither the audio descriptions nor transcript are not required if the visual content is also in the audio track, so this SC certainly does not support multimedia accessibility for the deaf.

Perhaps this is an oversight by the working group or perhaps I’m totally misinterpreting something. Either way, WCAG 2.0 needs additional clarity and importance given to transcripts and their necessity to many people with disabilities.

Color

SC 1.4.1 (Level A): Any information that is conveyed by color differences is also simultaneously visually evident without the color differences.

This SC addresses only color blindness (and perhaps monochrome displays), but ignores the fact that other stylistic differences can be as inaccessible as color. As an example, the following would be sufficient under this guideline:

The green mushrooms listed here are OK to eat. The red, italicized mushrooms will kill you.

• Amanita
• Chanterelle
• Porcini
• Shitake
• Tylopilus

Without the italics, the list may be inaccessible to some with certain forms of color blindness. The italics might make this content accessible to them, but it does not make this content accessible to screen reader users, braille outputs, the deaf-blind, those using technologies that don’t support these visual styles (such as my cell phone), or those that override or disable visual styles. While color should not be used alone to convey content, many stylistic visual differences are no more accessible.

Reading level

SC 3.1.5 (Level AAA): When text requires reading ability more advanced than the lower secondary education level, supplemental content or an alternate version is available that does not require reading ability more advanced than the lower secondary education level.

Of note, this SC does not require a lower secondary reading level. Instead, it requires a lower secondary alternative to more complex content. But how do you determine if content is written to a “lower secondary education level”? What types of technologies allow this to be adequately and universally measured? Why lower secondary education level?

WCAG 1.0 stated, “Use the clearest and simplest language appropriate for a site’s content”. Because of the working group’s self-imposed (and probably unnecessary – see my testability entry) mandate that each guideline be testable, they have attempted to map this SC to a “testable” standard–reading level. There are a few problems with this.

First, this is still an arbitrary measurement. There are several divergent techniques that are used to determine reading level. And what is “lower secondary” Is that ninth grade? Tenth? How did the working group determine that this is the most accessible reading level for all audiences?

Second, if it is possible for the content to be re-written to an early secondary level, shouldn’t this be the goal for the original document, not an alternative? In cases where the content (e.g., a college chemistry class or readers of a technical journal) may not be understandable to someone at a “lower secondary education level,” attempting to provide an alternative that simply uses smaller words or simpler sentence structure will not necessarily make the content more understandable.

Third, this seems to be a casual nod to the cognitive disability community, yet this is an area that WCAG 2 clearly states they are not addressing.

Readability is very arguably the most vital aspect of making content understandable (a core WCAG 2.0 principle). I’d certainly say it is more important that content be readable than it is to inform the reader what language is being used (a Level A requirement). While readability is a Level AAA guideline, requiring a specific, minimum readability level does not make sense and can actually decrease accessibility in certain settings. I would advise the working group to either remove this SC completely or remove their mandate that all success criteria be testable and the arbitrary lower secondary level measure. This will allow a more user-centered, “appropriate for the content”-type guideline for ensuring readability. After all, determining if language is appropriate for a site’s content is no less measurable by humans than determining if alternative text provides “equivalent information.”

Conclusions

WCAG 2.0 has come a long way. It still needs work. I have presented some of my issues and questions. If you share my concerns or have some of your own, I encourage you to provide comments on WCAG 2.0. The deadline for this draft is June 29, 2007.