WCAG Next

The Web Content Accessibility Guidelines 2.0 became a W3C Recommendation (code for “finalized specification”) in December 2008. I am proud to have my name listed as a contributor to WCAG 2.0. All of WebAIM’s current clients are working toward WCAG conformance. None of them are seriously considering only the antiquated Section 508, the update of which is perpetually stuck in bureaucratic delay tactics.

While WCAG 2.0 has been used to greatly enhance the accessibility of web content, it is not perfect. Its complexity and rather absurd terminologies, while generally necessary, decrease its approachability (and arguably accessibility) for many people. It is difficult to understand. WebAIM has provided a simplified WCAG checklist to help authors get started and to aid in evaluation of HTML documents. Accessibility and technology continues to evolve, and accessibility guidelines must evolve with them.

After three years of implementing and explaining WCAG 2.0, we have identified areas of the guidelines that could be improved or clarified. For a number of reasons, we are unable to participate formally in W3C processes, and we are unaware of any current plans for a WCAG 2.1 or a WCAG 3.0, so we present here some possible changes and improvements to WCAG 2.0, and items that we hope might help you better understand and implement optimal accessibility.

Remove the CAPTCHA Exception

Success Criterion (SC) 1.1.1 (Non-text Content) allows an exception for CAPTCHA, as long as it is identified as being a CAPTCHA and “alternative forms of CAPTCHA using output modes for different types of sensory perception are provided.” If a site provides both a graphical and an audio CAPTCHA, it passes. This, however, continues to exclude users that are deaf-blind, not to mention the difficulties that all users have with CAPTCHAs.

CAPTCHA has failed. Automated processes can now bypass it faster and more accurately than actual users. WebAIM clients, even those in the highly secure financial services industry, are abandoning CAPTCHA. WCAG should do the same by removing it as an exception, or perhaps allowing graphical and audio CAPTCHA for Level A conformance but prohibiting all CAPTCHA at Level AA.

Media Guidelines

“Media alternative for text”

Several of WCAG 2.0′s media guidelines include “…except when the media is a media alternative for text and is clearly labeled as such.” This means that text alternatives are not required if the video is an alternative version of the main text content of the same page (for example, a web page with the text of a speech that also presents a video version of that speech). This, however, is often misunderstood to suggest that if a transcript is provided, then captions or audio descriptions are not required. This could perhaps be clarified to indicate that if the main content of the page provides all necessary content of the associated media, then no other requirements (captioning, transcript, etc.) are necessary.

“Alternative for time-based media”

Alternative for time-based media” is a confusing term for a descriptive transcript – a text transcript of the audio or video that provides all necessary auditory content (such as identifying laughter or an off-screen explosion) and visual content (such as a list of items displayed in the video that are not presented via audio). We simply use “descriptive transcript” instead and have found is much more easily explained and understood. If a user reads the descriptive transcript, they will get all of the necessary content conveyed in the audio or video.

Audio descriptions and transcripts

Synchronized captions are always required for audio/video content at Level A. Additionally, either audio descriptions (auditory presentation of visual content in the video) or a descriptive transcript is required for Level A conformance by Success Criterion (SC) 1.2.3. Either of these meets the needs of users with visual disabilities. If an author provides a descriptive transcript to satisfy SC 1.2.3, then audio descriptions are required in SC 1.2.5 at Level AA. However, if an author provides audio descriptions to satisfy SC 1.2.3, then a descriptive transcript is not required until SC 1.2.8 at Level AAA. This latter case would render the media inaccessible to deaf-blind users at Level AA, because both captions and audio descriptions are inaccessible to these (and many other) users.

This is all compounded by the fact that if the video does not require audio descriptions (meaning all necessary visual content is presented in the audio of the multimedia), then SC 1.2.3 and SC 1.2.5 are satisfied. This means that for such video (e.g., a talking head), the author is not required to provide a descriptive transcript unless they are seeking Level AAA conformance. In other words, if a page contains only audio, it requires a descriptive transcript at Level A. But if you add a talking head video or simply add the audio to some video content, it doesn’t require a descriptive transcript until Level AAA. This surely is a weakness in WCAG 2.0 that should be addressed.

Recommended restructuring

Confusion and limitations of the current guidelines could be addressed by structuring the guidelines as follows based on the media’s characteristics:

  • Level A
    • Pre-recorded audio only – provide descriptive transcript.
    • Pre-recorded video only – provide descriptive transcript or audio description.
    • Pre-recorded audio/video:
      • Provide synchronized captions.
      • If visual content is not presented via audio, provide audio description or a descriptive transcript.
  • Level AA
    • Pre-recorded audio/video – provide a descriptive transcript.
    • Live audio/video – provide synchronized captions.
  • Level AAA
    • Pre-recorded audio/video – provide audio description, if necessary.
    • Pre-recorded audio or audio/video – provide sign language.
    • Live audio – provide synchronized captions.

This structuring would require audio descriptions or a transcript at Level A, but only if they are necessary for blind accessibility. At Level AA, all pre-recorded video would require transcripts. At Level AAA, video would require audio descriptions, if they are necessary due to visual-only content.

It is with great hesitation that I recommend moving audio descriptions to Level AAA (in WCAG 1.0, they were Level A). While they are the primary and preferred mechanism for providing multimedia accessibility to users with visual disabilities, one must balance their significant expense and difficultly to generate and the fact that transcripts provide equivalent content and are also accessible to a much broader audience (e.g., deaf-blind). Because a transcript will already have been generated in order to provide captioning, it seems more logical that the emphasis should be placed on providing a nearly universally accessible descriptive transcript, rather than on providing less usable and more burdensome audio descriptions.

Contrast at Level A

White text on a white background is Level A conformant. No contrast requirements are present until SC 1.4.3 at Level AA. Adding a minimal contrast requirement (perhaps 2:1 and 3:1 for large text) at Level A would help address significant readability issues that could be found on Level A conformant sites.

Decrease the 200% Text Resizing Requirement

Users with significant low vision rarely resize text in a browser. If a user requires text that is twice the default size, page zoom or a dedicated screen enlarger is and must be used. Designing modern web interfaces to support 200% text resizing is very difficult. This Level AA success criterion typically poses the most significant burden to our clients (often more so than captioning). We strongly recommend that the text resizing threshold be reduced to 150%, with perhaps a 200% threshold for Level AAA conformance.

UPDATE – 4/27/12

It was pointed out to me that browser zoom is allowable to meet the requirements of this success criteria. This seems very contrary to the normative text which says that “text can be resized…” In short, it’s pretty much impossible to fail this success criteria for HTML content because all major browsers provide adequate zoom functionality. I believe this is a severe deficiency in WCAG 2.0. We know that many users prefer text sizing over page zooming. This adds credence to my recommendation above for a 150% true text resizing requirement.

Clarify Images of Text

Success criterion 1.4.5 requires that if the same visual presentation can be made using text alone, an image is not used to present that text. The possibility of highly stylizing text and page elements with CSS (especially CSS3) begs the question of how one defines “same visual presentation”. For example, a graphical button with rounded corners, a background gradient, and text drop-shadow could be recreated with text and CSS3, but it is not clear if this is required to meet this Level AA success criterion.

While using text is always optimal for accessibility (and for other reasons), Level AA conformance should only require that the graphical text be replaced with true text when readily-available font face styling will suffice. In other words, authors should not be required to implement significant text styling to duplicate the graphical text’s presentation. SC 1.4.9 (Level AAA) already prohibits all presentation of text within images.

Specify Mechanisms to Bypass Blocks

A wide variety of “mechanisms” are available to allow users to bypass blocks of repeated content on web pages. This success criterion would be more meaningful and understandable if it required at least two possible mechanisms, such as:

  • a “skip” link
  • a consistent heading structure (e.g., main content always begins with an <h1>)
  • in-page navigation links
  • use of landmark roles
  • HTML5 structural elements

“Can Be Programmatically Determined”

WCAG 2.0 uses the phrase “can be programmatically determined” extensively. A wonderful article by Jason Kiss explains this term and its use in WCAG. This term refers to relationships that assistive technologies can make between content and/or markup. WCAG defines it to mean that technologies “can extract and present this information to users in different modalities”, whatever that means.

In most cases, when WCAG 2.0 requires that something “can be programmatically determined”, modern technology can actually do so. But not always.

As an example, if an ambiguous “click here” link is preceded by a descriptive heading, this is allowable at Level A by SC 2.4.4 because the meaning of the link “can be programmatically determined” based on the heading structure. The problem, however, is the word “can”. No modern assistive technology actually implements a method whereby the link is automatically made unambiguous because of this structural relationship. In other words “can be programmatically determined” does not mean “IS programmatically determined”.

This creates a situation where WCAG allows or requires something that does not actually result in any better accessibility. It also presents a situation whereby authors can’t know for sure if their content is actually conformant without knowing if assistive technology CAN do something. And which specific technologies or how many of them must do it before “can” means “can”? This is very akin to WCAG 1.0′s very confusing phrase “until user agents…”.

While supporting documentation attempts to clarify this, it remains a confusing aspect of page conformance. This could perhaps be addressed by more specific details at the success criteria or techniques level that reflect actual assistive technology capabilities, rather than simply suggesting that potential support is sufficient.

Require Keyboard Focus Indicators at Level A

A lack of keyboard focus indicators for navigable page elements – SC 2.4.7 (Level AA) – renders a page nearly entirely inaccessible for the large population of sighted keyboard-only users. This is one of the most significant and pervasive accessibility issues currently on the web (see The Plague of Outline:0). There is no reason why this should not be a Level A requirement.

Remove Parsing Requirement

While the intentions are noble, SC 4.1.1 (Level A), which requires that significant coding validation errors be avoided, has little impact on end-user accessibility and is next to impossible to evaluate. The areas in which coding errors impact accessibility are already sufficiently covered by other success criteria (such as proper form labeling, frame titles, table headers, etc.). I can’t think of a single instance where a significant coding issue would impact assistive technology specifically. The parsing requirement should be removed or perhaps changed to require strict validation at Level AAA.

Conclusion

This is not intended to be a criticism of WCAG 2.0. The web is clearly much more accessible because of these guidelines. As future updates to WCAG are considered, and as authors implement these guidelines today, these recommendations might provide some clarity and guidance, with the hope of making the web more accessible for all users. If you have feedback on these recommendations, or have thoughts of your own on WCAG, please comment below.

Comments

  1. Jason Kiss

    Great article, Jared.

    The practicality of meeting some accessibility requirements needs to be acknowledged, and audio description is one of those areas. I think requiring transcripts at Level AA and moving AD to Level AAA is completely reasonable. Making it more practical to meet Level AA might make doing so that much more palatable to developers and producers, especially where resource and cost tend to be presented as arguments against building accessible sites.

    (And thanks, also, for the kind link and mention.)

  2. Cliff Tyllick

    Great post, Jared. You have, indeed, identified points where the guidelines could use significant improvement. And, much to their merit, these aren’t a great departure from the spirit and organization of WCAG 2.0. So, W3C, why not incorporate them into a WCAG 2.1?

    I’m particularly impressed by Jason Kiss’ and your ideas for fixing the awful “can be programmatically determined.” I know of two legal departments that have been completely flummoxed by trying to interpret what that means. So sad. And, basically, it means nothing more than, “Using the appropriate method, tag the language of the entire document. When word or phrases from other languages are introduced, use appropriate methods to tag the language of those words or phrases.” In Word, I incorporate these tags through character styles. That way, if ever I need to, I can also modify the appearance of all French or Latin or Hindi terms throughout the (usually English, in my case) document. In HTML, inline styles afford the same possibility.

    In touching on the parsing requirements, you’ve raised an issue that actually makes it impossible to craft highly accessible Web documents and applications. At least, last I checked, the W3C validators still did not recognize ARIA landmarks and other coding that is nonetheless valid and can be used to significantly improve accessibility. And, given the state of HTML5, how can any validator check that? Just to mention HTML5 raises a number of hot-button issues, but even without all the squabbling there would be no way for a validator to keep up with all the changes in a constantly evolving environment. As you’ve pointed out, if the validity of the code is a sticking point for assistive technology, then the experience is almost certainly inaccessible in ways that can be pinpointed by the other guidelines. And in that case the other guidelines would be far more effective in helping the author, designer, or developer figure out what they would need to do to make the experience accessible. This one? Hardly a clue. Toss it!

    But, finally, please don’t give up on Section 508. Yes, the writing of administrative rules is an exhausting process. But the draft rule is now available for review and comment, and I am sure that your input would tremendously improve the ultimate result. Like WebAIM, and unlike the W3C, Section 508 doesn’t wear blinders to the world outside HTML. That’s crucial for those of us who mainly deal with word-processing documents or spreadsheets or any of various other non-HTML formats, as I do with in much of my work. We have to make *those documents* accessible in their native formats. We can’t convert them all to HTML just because WCAG 2.0 doesn’t apply to proprietary formats. We would appreciate greatly your review of these draft rules that will control so much of our working world.

    Once again, great post!

  3. Jared Smith

    Thanks for your comments Cliff. I haven’t given up on Section 508, but I am rather disenfranchised by the process. You may not know, but I was on the Section 508 TEITAC committee that spent 3 years authoring the draft guidelines. I wrote and edited a sizable portion of the current guidelines (and that’s primarily the path by which I helped save WCAG 2.0 from the disaster it was becoming at the time). I agree that they will be very useful, that is if they ever see the light of day.

  4. Randall Pope

    Jared,
    On behalf of the Deaf-Blind community, we thank you for remembering us. Great post, Jared!

  5. adam solomon

    Re: contrast
    Though there exists a strong argument that contrast should be required at level A, nonetheless white text on white background is not as unaccessible as one might think in light of the existence of browser foreground/background control overrides. This is usually sufficient, if not convenient, to give users the ability to control color schemes even in situations where the developer has not provided proper contrast in css.

  6. Jeevan Reddy

    Excellent article Jarad. All the points you said are absolutely necessary to improve the Accessibility guidelines (WCAG 2.0).

  7. Ghita Jones

    Thoughtful and insightful post, as usual, Jared. Thank you.

    I would like to point out that those of us who are or want to sell products to state/federal agencies must follow whatever those agencies adopt. In other words, we are ‘stuck’ with §508 and can only hope it will be finalized and update soon. While we consider WCAG 2.0, we have to address §508 via our VPATs. The sooner these can be “harmonized” the better!

  8. Sailesh Panchang

    When the DOJ sought public comments in 2010 with reference to Web accessibility and the ADA, I suggested they should go with WCAG 2 Level A plus SC 1.4.3 for color contrast and SC 2.4.7 for visual focus indicator as the minimum standard.
    You are right, I encounter resistance from clients who want to be level A compliant disregard the above two SC because they are at Level AA. They make the page completely unusable by users who need to adjust contrast or are sighted keyboard users.
    Very good article
    Thanks,
    Sailesh

  9. Gordon M

    Hi Jared, interesting points here.

    I have to fundamentally disagree with you about 4.1.1 though. In fact, I believe this is the most important requirement of all.

    Anyone who developed in the era of the 90′s remembers the browser hell that every web developer had to go through. Beyond simple text-only digests, making web pages accessible was next to impossible. There was no consistency and non-standardized code made things like syndication, social media, collaboration, and meaningful search difficult and cumbersome. People with disabilities deserve to experience web 2.0 just as much as non-disabled people.

    By enforcing validation, every assistive product out there, whether it is a $2000 screen reader to a free 50KB plugin, can consistently and reliably work on valid pages without requiring thousands of lines of extra code that costs millions of dollars in extra funding.

    WCAG needs to be able to adapt and grow with the web into the future. As pages get mashed-up, syndicated, shared, plussed, liked, etc. standardization will become even more important, not less. Passing validation is a crucial step to ensuring that the more interactive and advanced web applications of the future can still be made accessible in a reliable and consistent way.

  10. Jared Smith

    Gordon-

    I do not disagree with you at all. These are all important things. My point is that they are not accessibility-specific issues, but are general technology issues that affect everyone, and as such, they would be better addressed in areas other than the very narrow scope of WCAG.

  11. Gordon M

    An example of a validation error that is not directly accessibility related but can still cause problems for assistive technology:

    (error) start tag for element “ul” which is not closed

    In a page with many links in lists, an error like this can make it significantly more difficult for someone using a screen reader to navigate to specific sections of a page in a timely manner. Let’s say I have downloaded a script that automatically skips between lists on a page so that I can navigate it faster. There is no way the script can work with an invalid document without relying on hacks or guesses.

    Another issue is the fact that mobile web devices (which are quite popular amongst many people with accessibility issues) don’t have nearly the same speed that desktop computers have and are sometimes significantly slowed down by badly coded web pages. A page that passes the other WCAG 2.0 SC’s but has bad code can fail because assistive technology simply can’t work in a timely manner on a mobile device.

  12. Craig McPheat

    Excellent points raised. I have to write my own in-house success criteria and guidelines to get what I want back from suppliers because if I say “to W3C WCAG2″ a lot of the points are so wooly they technically meet the requirements, but not to a practical standard.

  13. Neil Osman

    Thanks for the great read.
    I am visually impaired my self and i find the 200% criterion very useful, almost as much as the enlargement itself;-)
    I’ve noticed that many visually impaired readers find it cumbersome using a magnifier to read on the web. My take is that if a vertical scrolling was avoided, text enlargement could have been much more effective and thus needed.

  14. Nick Dunn

    Thank you so much for publishing this. Reminds me of Joe Clark and friends’ Samurai Errata for WCAG 1.0.

  15. John

    I agree with the comment regarding CAPTCHA. It has failed. I have a visual disability and even with corrective lenses, I have a hardest time reading them. It seem that some websites go out of there way to make sure you can never log on by employing CAPTCHA that is ridiculously difficult to to decipher. In addition, like stated, there are types of CAPTCHA-breaking methods out there anyway for those who want to bypass them. There has got to be a better system.

  16. Sam Joehl

    Parsing can have a significant impact on accessibility. When you add AT to the stack you introduce all the quirks of how the AT interoperates with the browser, and failing to add a closing tag or to close off a tag can result in making an element completely inaccessible or some horrible page renderings not only at the browser layer but at the AT layer. We see this a lot especially with data tables. Whether this requirement should remain in WCAG is open for debate, but unfortunately developers need to be reminded to write conformant code because it does have an impact on accessibility.

  17. Jared Smith

    Sam-

    I don’t disagree. My point is that if the mangled code causes accessibility issues (such as with data tables), then this will already be a failure somewhere else in WCAG 2.0. For every type of error that does affect accessibility, there are 100 that have no impact at all on accessibility. Let’s keep WCAG focused on accessibility, not on coding best practices.