IMPORTANT: Instructions

Please read carefully the
Instructions for the "Benefits of WCAG 2" Presentation
for an introduction, tips, and permission to use.

The Notes section for each slide contains important information. Make sure you can read the Notes. On this slide, the notes start with "[NOTES SECTION: This is where the important information is. . .]"


[NOTES SECTION This is where the important information is: for each slide.]

Note to presenters: Please read carefully the Instructions for the "Benefits of WCAG 2" Presentation at

Benefits of
Web Content Accessibility Guidelines

Developed with material from the
W3C Web Accessibility Initiative (WAI)

Updated 12 August 2010



[Please leave this here in case the first slide gets deleted:
Please read carefully the Instructions for the "Benefits of WCAG 2" Presentation ]

Note to presenters: Remember that some people may not be able to see the slides, for example, people who are blind or people listening to an audio-only recording of the presentation. Make sure that you say all of the information that is on each slide. See Advice for Presenters

WCAG 2 is


Web Content Accessibility Guidelines 2.0 defines how to make web content more accessible to people with disabilities, and older people with changing abilities due to ageing/aging. WCAG provides a provide common definition for accessible content, a benchmark.

Web "content" is the information in a web page, Web site, or web application, including:

A primary goal of WCAG 2 is to provide a shared standard for web content accessibility that meets the needs of individuals, organizations, and governments internationally.

Note to presenters: Depending on your audience and length of presentation, you might also want to say:

  • WCAG 2 itself is a technical standard designed primarily for Web developers and designers, authoring tool and evaluation tool developers, and others who need a technical standard for Web accessibility, such as managers and policy makers.
  • WCAG 2 itself is not designed for novice Web developers or content authors. There is other material for people with different levels of accessibility knowledge.

[quote G3ict]

WCAG 2.0 creates the foundation for a new level of standardization of web accessibility around the world. Its practical and well documented guidelines will allow web participants in many countries to evolve from a disparate set of practices to a unified approach to web accessibility for all.

— Axel Leblois, Executive Director, G3ict,
United Nation Global Initiative for Inclusive ICTs

WCAG 2 gives you


Today we'll be talking about the benefits of WCAG 2, including:

We'll focus only on the benefits of WCAG 2 in this presentation, and provide references for other aspects of Web accessibility. The benefits of accessibility overall are covered in Developing a Web Accessibility Business Case for Your Organization, which provide details on the financial, technical, legal, and social benefits.

Who Develops WCAG

W3C logoWeb Accessibility Initiative (WAI)logo


The World Wide Web Consortium (W3C) is the leading standards making body for the Web. W3C develops the Web standards HTML, XML, CSS,etc. W3C follows a formal process to ensure international, multi-stakeholder development and review. We'll talk more about that process in a minute.

The Web Accessibility Initiative (WAI) is part of W3C. WAI works with organizations around the world to develop strategies, guidelines, and resources to help make the Web accessible to people with disabilities.

WAI develops:

WAI welcomes:

WCAG is developed within W3C WAI, following the W3C process.

Note to presenters: Customize how much you cover what all WAI does. Make sure to include that WCAG is developed within W3C, the standards making body for the Web.

[Image description: W3C logo and Web Accessibility Initiative logo are right under "Who develops WCAG"]

How WCAG is developed, Stage 1

WCAG Working Group development
Arrow pointing down.
 WCAG 2 Working Draft 
Arrow pointing down.
Public review and comment
Arrow back to 'WCAG working group development'.


The W3C process is designed to:

This means that WCAG is developed with a wide range of perspectives, including yours if you so choose. More specifically:

WCAG is developed in the W3C WAI WCAG Working Group (WG). The WCAG WG is made up of W3C member representatives and "invited experts" from industry, disability organizations, government, accessibility research organizations, and more. The WCAG WG includes developers, designers, researchers, tool vendors, and people with disabilities. Nearly 100 people from around the world have actively participated in developing WCAG, and many more have contributed review comments.

All WCAG WG work is public -- anyone can read the drafts in progress, the meeting minutes, and the mailing list archives, and can subscribe to the WCAG WG mailing list.

The WCAG WG periodically publishes "Working Drafts". Working Drafts are published and announced specifically to ask for review and input from the public. Often there are issues that the Working Group would particularly like input on.

Usually multiple Working Drafts are published. There have been several WCAG 2 Working Drafts announced over the last few years.

People have reviewed WCAG Working Drafts and submitted many comments to help make WCAG 2 better.

Note to presenters: Customize how much you cover the WCAG WG and the process. If all of the audience is  familiar with W3C Working Groups and public review, you may not need to include this slide.

[image description: "WCAG Working Group development" at the top, with an arrow down to "WCAG 2 Working Draft" which is in the middle, and another arrow down to "Public review and comment" at the bottom. A longer arrow then goes from "Public review and comment" back up to "WCAG Working Group development"]



Here's a list of the milestones in the W3C process. [read through stages on slide]

For an explanation of the milestones, see "How WAI Develops Accessibility Guidelines through the W3C Process: Milestones and Opportunities to Contribute"

One of the aspects of the W3C process is getting implementations, that is, real cases where the guidelines/specifications have been met in websites. This demonstrates that they can be implemented in the real world.

WCAG 2 went through this stage the middle of 2008, gathering at least two implementations for every requirement in WCAG 2. (These are linked from the WCAG 2.0 Implementation Report page

WCAG 2.0 was published as Web Standard (W3C Recommendation) in December 2008!

[decorative images are next to each milestone]

(Images credit: Shawn Henry, copyright W3C. W3C grants permission to use the images under the W3C Document License at Include a reference to the main source document as follows:

How WAI Develops Accessibility Guidelines through the W3C Process: Milestones and Opportunities to Contribute. S.L. Henry, ed. W3C (MIT, ERCIM, Keio), September 2006.

Cooperation with accessibility policy development around the world


Many new and revised accessibility policies are directly referencing or converging on WCAG 2

Throughout the development of WCAG 2, the WAI actively worked with organizations developing accessibility policies, including the U.S. Access Board that develops the Section 508 standards, the Japanese Industry Association, European organizations, and several others.

Note to presenters: If there are policies that reference WCAG 2 or directly relate to WCAG 2 in the organization, country, or other area related to your audience, consider listing those on the slide and mentioning the relationship.

To find out about local policies, you can:

Integrated Accessibility Guidelines


Another benefit of WCAG is that it is part of an integrated suite of accessibility guidelines and specifications from the W3C WAI:

Note to presenters: If you have time, this is a topic that you might want to cover in more detail. For material, see:

Authorized Translations


Another benefit is that WCAG, and other W3C specifications, can be translated and provided as an Authorized W3C Translation. This is especially important for non-English-speaking countries that want to adopt WCAG, rather than investing effort in developing a different set of guidelines.

For more information see the Policy for Authorized W3C Translations

Already there are planned or completed translations in Catalan, Chinese, Czech, Danish, Dutch, German, Hindi, Hungarian, Italian, Japanese, Korean, Portuguese, Spanish, Russian, and more.

For a list see WCAG 2.0 Translations

Note to presenters: If there are WCAG 2.0 translations in the languages of your audience, consider including the link to the translation(s) in the slide.

Cooperatively developed International standard


All of these points are aspects of WCAG 2 being a cooperatively developed international standard.
[Read slide text.]

WCAG 2 gives you


WCAG 2 builds on WCAG 1 and incorporates what we've learned to make WCAG more useful and more effective.

While the approach and a few of the requirements of WCAG 2 are a little different, the fundamental issues of Web accessibility are the same.

Most websites that meet ("conform to") WCAG 1 should not require significant changes in order to meet WCAG 2. Also, WCAG 2 is designed to be "backwards compatible" so that a site can meet both WCAG 1 and WCAG 2.

The differences between WCAG 1 and 2 are introduced the "WCAG Versions: 1.0 and 2.0" section of the WCAG Overview Details are provided in:

Let's look at how differences in approach and structure make WCAG 2 work better.

[decorative image description: hand holding silver platter with "WCAG 2" on it]

(Image credit: Shawn Henry. Permission granted to use for other WCAG 2 presentations.)

WCAG 2 Gives You


Applies to more advanced Web technologies - current, future, non-W3C

WCAG 2 has been developed to be applicable to current technologies and to future technologies. It is designed to apply to W3C technologies, as well as technologies developed outside of W3C.

Let's look at how the different WCAG 2 documents provide that flexibility, as well as provide both general, technology-independent and specific guidance.

[decorative image description: hand holding silver platter with "WCAG 2" on it]



WCAG 2 itself - the document at - is the formal Web standard"W3C Recommendation". It is the only document that defines what is required. (Other documents provide additional information, but are not part of the formal standard.)

How WCAG 2 documents provide a stable basis as well as flexibility

WCAG 2 goes through the formal W3C process and once it is completed, it is intended to be stable and relevant as technology changes over time, and apply as we develop new techniques for making the Web accessible. In order to do that, WCAG 2 itself needs to be broadly applicable and technology-independent. (It can't have details for specific technologies because things will change over time.)

WCAG 2 is not prescriptive about how to do things, but rather what functionality is needed for users. So WCAG 2 specifies what needs to be done for accessibility, and a related document tells how to do that.

WCAG 2 Guidelines and Success Criteria are technology-independent, and specific guidance is provided in the Techniques.

[Techniques document]

(image description below)


Techniques tell you how to meet WCAG 2

The Techniques for WCAG 2 is a supporting document that tells you how to develop accessible web content that meets WCAG 2. It provides specific details:

It also shows you common "failures", that is, some examples of how you can mess up and not meet the success criteria.

Where as WCAG 2 will be a stable document, the Techniques document can be updated as technologies and new techniques are developed. That's how WCAG 2 can provide a stable basis, with flexibility to adapt over time - through the Techniques.

Currently there are: General techniques, HTML techniques, CSS techniques, Server-Side Techniques, and others. More Techniques will be developed in the future.

WAI encourages development of techniques for non-W3C technologies as well, so there may be techniques for Flash or PDF or XYZ technology. While W3C WAI will not directly develop techniques for these other technologies, it will encourage their development.

Techniques are "informative"

Again, the Techniques are not part of the WCAG 2 standard, and you don't have to use them to meet WCAG 2. You could develop other ways to meet WCAG 2. This is another aspect of the flexibility of WCAG 2.

(By the way, if you develop new techniques to meet WCAG 2, you can submit them for review and inclusion in updates to the Techniques document.)

Note to presenters: A larger version of the image is available at

[image description:

Instructions for Developers
Techniques for WCAG 2.0
(HTML, CSS, scripting,. . .)

  • Browser and assistive technology support notes
  • Examples, code
  • Resources
  • Test procedures


WCAG 2 gives you

(still need human judgment)


With WCAG 1 it was often difficult to determine whether or not a website met some of the checkpoints. This was a problem for some organizations that wanted to adopt WCAG 1 into policy.

WCAG 2 is designed to be more precisely testable. That is, the requirements are clearer, making it easier to understand how to meet WCAG 2. We'll look at a specific example of that in a minute.

Note that testable doesn't mean that it can all be done automatically, you'll still need a combination of automated testing and human evaluation to evaluate if a site meets WCAG 2.

Let's look at how this is different from WCAG 1. . .

[decorative image description: hand holding silver platter with "WCAG 2" on it]

Testable Example


[read slide text]

This sounds good, however, if we look at a sample web page, is it precise enough that we can determine whether or not the web page meets this checkpoint?

Questionable color contrast:

example web page described below


Here is an example web page. The main navigation down the left has black text on red background. Along the top are right is small black text and larger black text on light red background. In the middle is large red text on white background. There is small red text on a white background, gray background, and red background.

Do these areas meet WCAG 1 Checkpoint 2.2 for color contrast?

While the checkpoint provides important guidance, it is not specific enough to clearly determine whether all of the color contrast on this page meets WCAG 1 or not.

Let's look at the similar WCAG 2 success criteria. . .

Note to presenters: Consider customizing this image. Find one with questionable color contrast from your organization or that would resonate with your audience.

Note to presenters: Remember to describe the pertinent parts of the image for people who are blind or otherwise cannot see it.

Testable Example


The WCAG 2 success criteria is more specific and testable. It defines a precise contrast ratio, and there are tools that you can use to determine the contrast ratio.

That's an example of how WCAG 2 is more precisely testable that WCAG 1 is. (Remember that some success criteria need human evaluation, and cannot be evaluated only with automated tools.)

WCAG 2 gives you

for different situations,
can use other techniques


WCAG 2 is adaptable and flexible, for different situations, and developing technologies and techniques. We described earlier how WCAG 2 is flexible to apply to Web technologies now and in the future.

While WCAG 2 itself provides a stable standard for what users need, the Techniques provide flexibility in how developers meet users' needs. There are different Techniques for different situations. And the Techniques are optional; you can use other ways to meet the WCAG 2 success criteria.

Let's look at some other ways that WCAG is flexible and adaptable. First let's look at examples of what WCAG 2 allows that WCAG 1 did not; that is, where WCAG 2 is less restrictive than 1.

[decorative image description: hand holding silver platter with "WCAG 2" on it]

More design flexibility, e.g.:


WCAG 1.0 limited movement used in web pages, through the following checkpoints:

WCAG 2 allows more movement, within defined parameters

Note to presenters: Customize how much you use this example, and how much text you have on the slide. For longer presentations to designers who are familiar with WCAG 1.0, you might want to include all these details. For short presentations, it might be best to cover it much less, if at all.

Scripting allowed!


Back in 1999, in the days of WCAG 1, there was very little support for scripting in common assistive technologies, such as screen readers. You pretty much couldn't design a site that relied on scripting and was accessible. That's changed now. All of the major browsers and assistive technologies support scripting. So now there are ways where you can use scripting, and even in some cases use it to enhance accessibility.

There are definitely some accessibility issues depending on what you do with scripting, but it's no longer something that always impairs accessibility; now it's actually encouraged in some cases.

There are several resources on the Web that provide additional guidance on accessibility and scripting.

Note to presenters: For some audiences, you might want to explain that scripting is an issue under the "Perceivable" principle. In the past, content provided through scripting was not always perceivable to uses with disabilities.

Scripting techniques


In fact, there are specific scripting techniques for WCAG 2, including: [items listed on slide] And there will probably be more in the future.

Reference: Client-side Scripting Techniques for WCAG 2

Note to presenters: This is a particular area that you might want to cover in more or less detail depending on your audience. You can get more about scripting techniques from links in the Techniques document contents list as well as other (non-W3C WAI) resources on the Web (however, note that some may be out of date or incorrect).

Flexibility for rich Internet applications (Ajax, DHTML)


WCAG 2 is being developed in coordination with related work on making accessible the more advanced features of dynamic content and rich Internet applications developed with Ajax, DHTML, and other Web technologies. That work is the Accessible Rich Internet Applications Suite, WAI-ARIA, which is being developed by the W3C WAI Protocols and Formats Working Group.

A primary focus of ARIA is providing information about user interface controls to assistive technologies, e.g.:

With WAI-ARIA you can make rich Internet applications much more accessible and usable by people with disabilities. For example, for a menu in a tree control, ARIA defines how to make the information about the nodes available to assistive technologies, so that users can to tell where they are in a tree, expand and collapse nodes, and get around and navigate a lot more effectively. Keyboard access is a key aspect of WAI-ARIA.

Note to presenters: Please use "WAI-ARIA" on first reference, especially in print. It's OK to use just "ARIA" when you're using it repeatedly. (per the WAI-ARIA FAQ

Note to presenters: This is a particular area that you might want to customize to cover in more or less detail depending on your audience. You might want to only mention it briefly and then delete the next couple of slides. You can learn more from the WAI-ARIA Overview at


ways of using


Another way that WCAG 2 provides flexibility and adaptability for different situations today and as technology changes over time is allowing technologies to be used based on the accessibility support in different situations.

We won't cover accessibility-supported technologies here; it is covered in other WAI material.

Note: Check for updated information on accessibility-supported technologies in the Overview of WCAG and the WCAG 2 FAQ

What WCAG 2 gives you


[read slide text]

[decorative image description: hand holding silver platter with "WCAG 2" on it]

Understanding document

(image description below)


With WCAG 1, many people had questions on how to interpret it and implement it, such as: What does this checkpoint mean? How do we implement it? How does this help people with disabilities?

With WCAG 2, that information is provided in the Understanding document. It tells you the intent of each guideline and success criteria and how it helps people with disabilities; provides examples; and lists related resources, such as the tools to test for color contrast that we talked about earlier.

Note that the Understanding doc is not intended to be read cover to cover; instead, it's more like a reference manual. It's the book on WCAG 2, from the Working Group itself.

That's a lot of information. We have something else that's incredibly useful for getting around it all. . .

Note to presenters: A larger version of the image is available at

[image description:

Detailed Reference
Understanding WCAG 2

  • Intent
  • Benefits to people with disabilities
  • Examples scenarios
  • Resources
  • Techniques

[How to Meet WCAG 2]

(image description below)


How to Meet WCAG 2 is a customizable quick reference to the WCAG requirements and techniques. It lists all of the guidelines, success criteria, and techniques for WCAG 2.

Most people will use the How to Meet Quick Reference as the main tool for WCAG 2.

Note to presenters: How to Meet WCAG 2 is a key tool that should be mentioned in almost all presentations.

[image description:

Customizable Quick Reference
How to Meet WCAG 2.0]

[Quick Reference screen shot]

Screen shot of the Customization Tool for the Quick Reference with check boxes to choose various technologies, levels and sections


You can customize How to Meet WCAG 2 quick reference for your specific situation.

If you have all the information listed in the quick reference, it gets kind of long. But you can select just the information that you want to see. You can turn off things like [multimedia and SMIL (Synchronized Multimedia Integration Language) and scripts], and select which technologies you're using. You can also select which level success criteria you want included.

You can use these options to filter what's shown in the checklist to make it shorter with only the items relevant to your project.

[image description: Screen shot from with the checkboxes listed below.

Customize this Quick Reference

  • HTML techniques (always shown)
  • Show CSS techniques and failures
  • Show Synchronized Media techniques and failures
  • Show SMIL techniques and failures
  • Show Client-side Scripting techniques and failures
  • Show Server-side Scripting techniques and failures
  • Show WAI-ARIA techniques and failures


  • Show Level A Success Criteria
  • Show Level AA Success Criteria
  • Show Level AAA Success Criteria.


  • Show Sufficient Techniques and Failures
  • Show Advisory Techniques


Additional Support


WAI also has other documents that introduce WCAG 2 and provide additional support, which were developed mostly in the W3C WAI Education and Outreach Working Group.

The WCAG 2 Documents provides an important foundation for understanding the different WCAG 2 documents. It explains in text a lot of what we're covering today. (If you see someone linking only to the technical documents themselves, such as in a blog post, it would be great if you would encourage them to link to Overview first. That way people can get the foundational information about the different documents, such as the Quick Reference, instead of potentially getting caught up in the technical document.)

[Read other documents listed on slide.] These other documents are all linked from the navigation area on the Overview page.

[quote EDF]

By giving clear technical specifications to website designers, and unifying web-accessibility standards, WCAG 2.0 directly benefits users who have accessibility needs due to disabilities.
It represents a crucial tool with which to build a better and more inclusive web.

— Yannis Vardakastanis,
European Disability Forum (EDF)



There are many resources on the WAI website to answer your questions. For example,

Check out the WAI Resources list at

There is also a WAI Interest Group mailing list where you can ask questions of the Web accessibility community.

Note to presenters: Ideally you would provide a handout with the links listed. Make sure to have accessible formats as needed, e.g., large print and Braille or electronic versions. If you don't have handouts, make sure to leave the resources displayed long enough for people to copy down the information. Also, be prepared to read it all out clearly for people who cannot see the screen.

Source Material

Web Accessibility Initiative (WAI)

Benefits of WCAG 2. Shawn Lawton Henry, ed.

  Copyright © 2010 W3C® (MIT, ERCIM, Keio).

Note that this presentation is based on material provided by the W3C Web Accessibility Initiative (WAI) Education and Outreach Working Group.

Note to presenters: Remember to credit this presentation as source material for your presentation, as described in Instructions for the "About WCAG 2" Presentation at

In handouts, include the reference:

This presentation is based on slides from the Web Accessibility Initiative (WAI): Benefits of WCAG 2. Shawn Lawton Henry, ed. Copyright © 2010 W3C® (MIT, ERCIM, Keio). Status: Updated 12 August 2010.

Benefits of WCAG 2


To review what we discussed: [text in slide]

[decorative image description: hand holding silver platter with "WCAG 2" on it]

WCAG 2 Benefits you!


WCAG 2 benefits people with disabilities, it benefits Web developers and designers, it benefits organizations with websites, and. . . WCAG 2 benefits you!

[decorative image description: hand holding silver platter with "WCAG 2" on it]

About this presentation

Please read carefully the
Instructions for the "Benefits of WCAG 2" Presentation
for an introduction, tips, and permission to use.

Please send any feedback and suggestions for improving these presentation materials to


[slide is hidden in some software so it will not display]