Notes

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

A video with audio and slides, and a text transcript, of a presentation similar to this one is available online from www.w3.org/WAI/highlights/200706wcag2pres. Note that it is from June 2007 and some information may have changed since then.

Notes

Today I'll be talking about [text on the slide]

Notes

This presentation assumes that you have some basic knowledge of Web accessibility and of WCAG 1.0. Some resources that cover these topics are listed at the end of the presentation, in case you want to fill in your knowledge or share them with others.

Let’s start by highlighting a couple of key points about what WCAG is

Notes

WCAG 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.

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

WCAG 2.0 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.0 itself is not designed for novice Web developers or content authors. There is other material for people with different levels of accessibility knowledge.

Notes

Let’s look at who develops WCAG and how…

Notes

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
  • guidelines which are widely regarded as the international standard for Web accessibility
  • support materials to help understand and implement Web accessibility
  • resources, through international collaboration
• WAI welcomes:
  • participation from around the world
  • volunteers to review, implement, and promote guidelines
  • dedicated participants in Working Groups
• WAI has several different Working Groupings that:
  • develop guidelines for Web sites (“content”), authoring tools, browsers and other “user agents ”
  • ensure that W3C technologies support accessibility
  • facilitate development of accessibility evaluation tools
  • conduct education and outreach
  • coordinate with research and development around accessibility issues

WCAG is developed within W3C WAI, following the W3C process. Let’s look at what that provides…

Notes

The W3C process is designed to:

• ensure broad public input, and
• encourage consensus development.

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.0 Working Drafts announced over the last few years.

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

[image description: “WCAG Working Group development” at the top, with an arrow down to “WCAG 2.0 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”]

Notes

Public review, comments, and feedback have helped improve WCAG 2.0 with every draft. Here are some examples of language improvements, and later are some examples of technical improvements.

• April 2006 Draft: www.w3.org/TR/2006/WD-WCAG20-20060427/
• May 2007 Draft: www.w3.org/TR/2007/WD-WCAG20-20070517/

Here’s another example:

• 2006 Draft: 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)
• 2007 draft: Web page: a resource that is referenced by a URI and is not embedded in another resource, plus any other resources that are used in the rendering or intended to be rendered together with it

UPDATE note: Check the latest draft and use that wording.

Notes

If you haven’t read WCAG 2.0 lately, please take a look! Read the Overview and the FAQ, which are only a couple of pages each. You can skim the Quick Ref and the Changes doc to get a feel for recent developments in WCAG 2.0. We’ll talk more about the Quick Reference later.

First let’s look at a very common question about WCAG 2.0 …

Notes

When the Working Group believes it has addressed all comments and technical requirements, it provides the complete document for public review and announces the Last Call.

The Working Group again asks for review and comments. The Working Group responds to each comment on the Last Call Working Draft. It can take weeks or months for a Working Group to formally address all comments, document the resolutions, and make necessary changes.

If there are substantive changes, it would go through another Last Call Working Draft before moving to the next stage often with a Working Draft in between.

Once the all comments have been resolved, it progresses to the next stage.

Notes

Here’s a list of the milestones in the W3C process.

One of the aspects of the W3C process is getting implementations, that is, real cases where the guidelines/specifications have been met in Web sites. This demonstrates that they really are do-able.

Notes

For an explanation of the milestones, please see How WAI Develops Accessibility Guidelines through the W3C Process: Milestones and Opportunities to Contribute at www.w3.org/WAI/intro/w3c-process

Notes

WCAG 2.0 has multiple layers that cover the basics through the details for understanding and developing accessible Web content. These multiple layers help it meet different needs, especially the goal of applying broadly to current and future technologies and situations.

WCAG 1.0 has guidelines.

WCAG 2.0 Working Draft (WD) also has guidelines, and it has a higher level: principles of Web accessibility.

Notes

The 4 principles of Web accessibility in WCAG 2.0 are:

Perceivable - Information and user interface components must be presentable to users in ways they can perceive. This means that users must be able to perceive the information being presented; it can't be invisible to all of their senses.

Operable - User interface components and navigation must be operable by users. This means that users must be able to operate the interface; the interface can't require interaction that the user can not perform.

Understandable - Information and the operation of the user interface must be understandable by users. This means that users must be able to understand the information as well as the operation of the user interface; the content or operation cannot be beyond their understanding.

Robust - Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. This means that users must be able to access the content as technologies advance; as technologies and user agents evolve, the content should remain accessible.

Notes

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

WCAG 2.0 is designed to be more precisely testable. That is, the requirements are clearer, making it easier to understand how to meet WCAG 2.0. 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.0.

Let's look at how this is different from WCAG 1.0

In WCAG 1.0 under the guidelines are checkpoints. The checkpoints are the basis for determining conformance to WCAG 1.0.

In WCAG 2.0, under the guidelines are success criteria. The difference between 1.0 checkpoints and 2.0 success criteria is more than just terminology, it represents the difference in testability. The success criteria are testable statements that are the basis for determining conformance to WCAG 2.0.

Let’s look at an example of the difference…

UPDATE note: Check the success criteria designations (A, AA, AAA) in the latest draft; they might have changed to something else.

Notes

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?

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.0 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.0 or not.

Let's look at the similar WCAG 2.0 success criteria

Notes

The WCAG 2.0 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.0 is more precisely testable that WCAG 1.0 is.

(Remember that some success criteria need human evaluation, and cannot be evaluated only with automated tools.)

UPDATE note: Check the latest WCAG 2.0 Draft at www.w3.org/TR/WCAG20/ to get the current wording of the relevant success criteria

Notes

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

WCAG 2.0 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.

WCAG 2.0 is designed to be more adaptable and flexible, through different types of documents.

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

Notes

“Normative” formal standards, and “informative” supporting documents

An important clarification when looking at WCAG 2.0 information is to understand the difference between the “normative” standards and the “information” supporting documents.

WCAG 2.0 itself – the document at www.w3.org/TR/WCAG20 – is the formal Web standard draft, which is planned to become a “W3C Recommendation”. It is the only document that defines what is required. The other documents provide additional information, but are not part of the formal standard.

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

WCAG 2.0 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.0 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.0 is not prescriptive about how to do things, but rather what functionality is needed for users. So WCAG 2.0 specifies what needs to be done for accessibility, and a related document tells how to do that. WCAG 2.0 Guidelines and Success Criteria are technology-independent, and specific guidance is provided in the Techniques.

Let’s look at how that provides flexibility.

Notes

Techniques tell you how to meet WCAG 2.0

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

• Description
• Examples, such as HTML code
• Browser (User Agent) and Assistive Technology Support Notes
• Resources
• Tests

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.0 will be a stable document, the Techniques document can be updated as technologies and new techniques are developed. That’s how WCAG 2.0 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.0 standard, and you don’t have to use them to meet WCAG 2.0. You could develop other ways to meet WCAG 2.0. This is another aspect of the flexibility of WCAG 2.0.

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

Notes

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

7.1 Until user agents allow users to control flickering,<br />avoid causing the screen to flicker.

7.2 Until user agents allow users to control blinking,<br />avoid causing content to blink

7.3 Until user agents allow users to freeze moving content,<br />avoid movement in pages.

WCAG 2.0 allows more movement, within defined parameters

2.2.2 Blinking: Content does not blink for more than three seconds, or a method is available to stop all blinking content in the Web page.

2.2.3 Pausing: Moving, blinking, scrolling, or auto-updating information can be paused by the user unless it is part of an activity where timing or movement is essential. Moving content that is pure decoration can be stopped by the user.

2.3.1 Three Flashes or Below Threshold: Content does not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds.

2.3.2 Three Flashes: Content does not contain anything that flashes more than three times in any one second period.

Notes

Back in 1999, in the days of WCAG 1.0, 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.

Notes

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

Notes

WCAG 2.0 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 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.:

Menus, tree controls, navigation bars

Role and state

Once ARIA is implemented, you'll be able to 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.

Notes

Work on WAI-ARIA is moving pretty fast, and one of the promising aspects is that there are already implementations of ARIA. There is already at least one browser and at least one screen reader that are implementing ARIA.

Notes

Note that there are different WAI-ARIA documents for different audiences:

1. The first documents produced were the technical specifications for
   • developers of Web browsers, assistive technologies, and other user agents;
   • developers of authoring tools and accessibility evaluation tools; and
   • developers of other Web technologies (technical specifications).
2. For Web content developers and authoring tool developers, a separate document [will] provide[s] best practices for implementing WAI-ARIA in Web content.

UPDATE Note: WAl-ARIA work is moving fairly rapidly; please remember to check the latest information and status of the documents; for example, the full name of the Best Practices document. The current status will be listed in the most recent Call for Review that is listed on the WAI home page under "Documents in Progress", below www.w3.org/WAI/#announce - and might also be listed in the WAI-ARIA Overview at www.w3.org/WAI/intro/aria

Notes

WCAG 1.0 used the "until user agent" clause to address current limitations and future advances in user agents, such as with Checkpoint 10.2.

For WCAG 2.0, "accessibility-supported technologies" addresses that (the issue of current limitations and future advances).

Let's look at what accessibility-supported technologies means from the authors' point of view.

Notes

From a developers/designers/authors perspective, one way to think about accessibility-supported technologies is: A list of Web technologies that an author can use to create accessible Web content.

Notes

WCAG 2.0 includes the criteria for a technology to be included on the list of accessibility-supported technologies.

Notes

Note that you can use other technologies that are not on the list, as long as they are used only for enhancement, and all the information and functionality is fully available (perceivable, operable, and understandable) to people with disabilities then the non-accessibility-supported technology is not supported, or turned off (or on).

Now let's look at how it's described in WCAG 2.0, which covers other perspectives as well.

Notes

Let's look at examples for each point.

Notes

"Technologies" here is Web content technologies, e.g., HTML, CSS, GIF, SVG, PNG, PDF, Flash, JavaScript, MPEG.

Note that these are examples of Web content technologies, but not all of those listed are necessarily accessibility supported.

Next, let's look at what those "if"s are

Notes

For the second phrase ("users' assistive technologies support"), you could say "the screen readers, screen magnifiers, etc. that the users use support it".

Notes

Where the second point says that assistive technologies have to support the technology, the third point says that common browsers and other user agents have to support the technology – because some people rely on the accessibility features of browsers and don"t use assistive technologies.

Notes

So if we put it together, is says [text on slide in the second box].

Notes

Next lets look at two very different situations for a Web site, and how the concept of the accessibility-supported technologies list provides flexibility.

Notes

Situation A is a Web application on the Internet that is intended to be used by everyone.

Notes

Situation B is a Web application inside an organization that is only for employees.

Now lets say you are developing these Web applications and you are considering using SVG, scalable vector graphics. In situation A, you could not rely on SVG because many people dont have user agents that support SVG.

However, if in situation B, the company provides all employees with accessible user agents that handle SVG and you have confirmed that it is fully accessible, then you could document that SVG is an accessibility-supported technology for that situation; therefore, you could use it for the application and meet (conform to) WCAG 2.0.

[image description: Photo of two kids looking at a computer, under Situation A (same as previous slide). Additionally, under Situation B, man in business clothes at a computer with others in the background.]

Notes

Here's what it looks like when we put it all together: [text on slide].

We just looked at how the concept of accessibility-supported technologies provides you flexibility for different situations and flexibility as technologies and user agents develop over time.

You can read more about accessibility-supported technologies in the WCAG 2.0 documents.

Speaking of the WCAG 2.0 documents, that's one of the other things that WCAG 2.0 gives you

Notes

Let's look at how this compares to WCAG 1.0

Notes

Techniques

With WCAG 1.0 there are some techniques. The WCAG 2.0 techniques are much more robust and comprehensive, and they include tests.

Understanding

In WCAG 1.0, brief descriptions are included in the main WCAG 1.0 document under each guideline. With WCAG 2.0, extensive guidance is provided for each guideline and success criteria in a new document, called Understanding WCAG 2.0: A guide to understanding and implementing WCAG 2.0.

Notes

With WCAG 1.0, 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.0, 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. Its the book on WCAG 2.0, from the Working Group itself.

Notes

The WCAG 2.0 Quick Reference!

The Quick Reference lists the requirements for WCAG 2.0, provides summary information from the other documents, and links to details.

Most people will use the Quick Reference as the main tool for WCAG 2.0.

So lets look at it in more detail.

Notes

The Quick References includes the guidelines and success criteria from the normative WCAG 2.0 document.

Under each success criteria, it lists the relevant techniques – just the title phrase of the techniques.

Notes

The Quick Reference provides the basics, with links to the details.

For each guideline and each success criteria, there are links to the Understanding document.

Each of the techniques titles are linked to the details in the Techniques document.

Let's take a look at the actual Quick Reference.

Notes

Lets look more at that color contrast success criteria. There's a short title: "Contrast (Minimum)" then the full text of the success criterion: Text (and images of text) have a contrast ratio of at least 5 to 1 except if the text is pure decoration. Large-scale text or images of text can have a contrast ratio of 3 to 1, and it includes the Level, which is Level AA for this one. Right after that is a link Understanding Success Criterion 1.4.3, so you can go directly to that topic in the Understanding document to get all that additional information if you want it.

The first section is Sufficient Techniques. These are the techniques that the Working Group has defined as being sufficient to meet the success criteria that is, if you do the sufficient techniques, you meet the success criteria. These techniques are short sentences, so you can skim them. If you want to know more, you just click the link and it goes to the Techniques where you get the explanations, examples, etc.

The next section is Common Failures (which is new, we didn't have that with WCAG 1.0). They are examples of what not to do. For example, for this contrast one, a common failure is specifying a foreground color without specifying a background color, or vice versa.

The final section is Advisory Techniques. These will usually enhance accessibility, but are not sufficient techniques for various reasons.

(Remember that all techniques are informative, and you dont have to use those particular techniques. They are there to define what you can do and to make it easy for you to know what will work, but there's flexibility to be able to define other techniques that will also meet the success criteria.)

UPDATE note: Check the success criteria designations (A, AA, AAA) in the latest draft; they might have changed to something else.

UPDATE note: The order of the sections and the text might have changed since this screen capture.

Notes

You can customize the 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.

UPDATE note: The customization options might have changed since this screen capture.

Notes

We also have other documents that introduce WCAG 2.0 and discuss current issues, which were developed mostly in the W3C WAI Education and Outreach Working Group.

• Overview of WCAG 2.0 Documents provides an important foundation for understanding the different WCAG 2.0 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.)
• WCAG 2 FAQ, which is updated fairly regularly, addresses questions such as: When will WCAG 2.0 be done? What is the current status? When should I start using WCAG 2.0?
• [Summary of Issues, Revisions, and Rationales for Changes to WCAG 2.0 2006 Last Call Draft addresses things like validity, baseline, coverage of people with cognitive disabilities and the accessibility issues.] If youve been following WCAG 2.0 development and are interested in how the issues were addressed, I encourage you to read that document.

UPDATE note: The document in brackets will likely be updated with each release.

Notes

To review what we just discussed: [text in slide]

Notes

There are a lot of things that WCAG gives you however, there is one thing that WCAG does not give you: that is first-hand experience with accessibility issues and how people with disabilities interact with your Web site.

Learning about basic accessibility issues and how people with disabilities use the Web will make it much easier to develop effective accessibility solutions, and to meet WCAG.

Before spending much time trying to implement guidelines, learn the basics about interaction with assistive technologies and adaptive strategies. There are many resources on the Web that help you with each of these steps to learning the basics:

Read resources on how people with disabilities using the Web

Watch videos of people with disabilities using the Web

Spend some time watching and talking to people with disabilities using Web sites like yours

"Remember that the goal of accessibility is not to check off a guidelines list; the goal is to make your site accessible. Using WCAG helps ensure that you address all issues, and involving people with disabilities helps you address them efficiently and effectively. " -www.uiAccess.com/understanding.html

WAI Resources:

Involving Users in Web Accessibility Evaluation <www.w3.org/WAI/eval/users.html>

How People with Disabilities Use the Web <www.w3.org/WAI/EO/Drafts/PWD-Use-Web/>

Notes

So, you should understand how people with disabilities use your site, and use WCAG to help develop accessible content.

Is that all that's needed to achieve Web accessibility?

Notes

We have been talking about content, which includes text, images, forms, applications, multimedia, etc.

We have the Web Content Accessibility Guidelines, WCAG, to define what we need to do for content.

Notes

People use browsers, media players, or what are generically called user agents' to get at content. Some people with disabilities use assistive technologies, such as screen magnifiers, screen readers, switches, voice input, and such.

The User Agent Accessibility Guidelines (UAAG) define what the browsers and assistive technologies need to do for accessibility, such as provide the ability to increase text size and to zoom in and to scale appropriately.

When the browsers, media players, assistive technologies, and other user agents do their part for accessibility, less is required of content developers and the Web is more accessible to users.

Notes

On the other side we have developers, designers, coders, authors, etc., using authoring tools and evaluation tools to develop content. Authoring tools include:

• Common WYSISYG editors [list a couple of common tools]
• Content management systems (CMS) - Content management systems are probably one of the biggest issues with accessibility and authoring tools today, because so many sites are developed using a CMS.
• Blogs, photo-sharing sites, social networking sites, etc.

All these are authoring tools, because they're used by people to develop content for the Web.

W3C WAI has also defined what the authoring tools need to do, in ATAG, Authoring Tool Accessibility Guidelines. ATAG 1.0 was completed in early 2000, and ATAG 2.0 is in development now.

There are 2 aspects to authoring tool accessibility:

1. They should help Web developers produce Web content that is accessible and conforms to the Web Content Accessibility Guidelines.
2. They should be accessible themselves, so that people with disabilities can use them to create content, whether they are adding a blog comment or full-time developers in a Web shop.

Notes

While most of us dont work directly on authoring tool and user agent development, we can have a strong voice in encouraging them. We need to push for accessibility improvements.

The product managers for these tools get a lot of requests for features and improvements. When they dont hear much about accessibility, the other things higher priority. On the other hand, if they get many requests for accessibility improvements from their customers and potential customers, they are more likely to do something about it.

Make sure that accessibility is a top consideration in choosing which authoring tools, browsers, and other user agents to purchase and use. When accessibility is a key criteria in procurement, that will make a difference to tool vendors.

There is a WAI resource that helps with that for authoring tools: Selecting and Using Authoring Tools for Web Accessibility.

Now is a particularly good time to be pressuring authoring tool vendors to work on ATAG, because 2.0 is in development. They can participate in developing ATAG 2.0, and start now to implement it for the next release of their tools.

So please take action and actively encourage accessibility improvements in all types of authoring tools, browsers, and other user agents. Send email and communicate how important it is that the tools meet accessibility guidelines, make developers jobs easier, and provide better accessibility to users.

Notes

There are also things that you can do now related to WCAG 2.0.

Notes

Remember to spread the word about the different WCAG 2.0 documents and the best place to start. First, to learn about WCAG 2.0, start with the Overview document. And for using WCAG 2.0, you’ll probably want to start with the Quick Reference.

Notes

So this is what we talked about today: [read out text on slide].

Notes

Notes

In addition to the resources that we listed throughout the presentation, here are links to some introductory resources and resources on specific topics. I'll read through them.

There are many more resources on the WAI Web site, and I encourage you to look through the home page and the Resources list.

Notes

Finally, note that this presentation is based on material provided by the W3C WAI Education and Outreach Working Group. The source presentation is WCAG 2.0 Web Content Accessibility Guidelines Update, edited by Shawn Henry, available from www.w3.org/WAI/presentations/WCAG20_about/

Notes

In conclusion:

Let's help everyone understand real-world accessibility issues for people with disabilities.

Let's come together as a community to develop effective accessibility solutions.

Let's spread the good news about WCAG 2.0, and develop useful supporting resources - both technical documents and material for "the average Web developer/designer ".

Let's encourage authoring tools, browsers, and Web sites to be more accessible.

Let's make the Web accessible to everyone!

Notes

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