W3C logoWeb Accessibility Initiative (WAI) logo

WAI: Strategies, guidelines, and resources to make the Web accessible to people with disabilities

Presentation: Web Accessibility Guidelines Update, June 2007

photo with Shawn and presentation slide, with text: Web Accessibility Guidelines Update. Shawn Henry. logos: W3C, Web Accessibility initiative.

Sidebar

Shawn photo

From the YUI Theater: Learn how the WCAG 2.0 Working Draft differs from WCAG 1.0, get shortcuts for using WCAG 2.0, and hear answers to common questions on W3C WAI's work in Shawn Henry's presentation to the Yahoo! Developer Network. Shawn also addresses the role of browsers and authoring tools in Web accessibility, and combining standards and usability techniques to optimize accessibility.

Transcript

Tom Hughes-Croucher: Welcome to the Yahoo tech talks from London. I'd like to welcome today Shawn from W3C and she is going to talk today about WCAG 2 and some of the other updates that have been there recently. So a big hand for Shawn please.

[Clapping]

Shawn Henry: Thanks so much for coming and hanging out on Friday after a long week, we care so much about web accessibility and I'm glad you're here. I'm just going to talk a little bit about the Web Accessibility Guidelines update. First give a little bit of background in case you're not familiar with some of that. I'm going to talk a lot about the Web Content Accessibility Guidelines (WCAG). I'm going to talk about some other guidelines you may or may not know and they are also very important. And then I have some other notes to talk about at the end on what you can think about in making your own sites accessible. So we'll go through some of these things today.

First of all I'm going to talk about why I'm involved in accessibility and why it means so much to me. On the screen is a web page that is very blurry, and so if Tom tries to adjust the screen projector he won't be able to get it to adjust properly. This is an example of how the Web looked to me starting about 1997. I was doing user interface design, usability, mostly for Windows client/server applications. I was beginning to have some health problems mostly vision, but also physical. It got bad enough that I didn't think I was going to be able to continue to work and to use computers. But then I discovered accessibility. The Trace Research and Development Center was in the city where I was living and I learned about all that they'd been doing to make information technology accessible. So I decided to do something about it. And even once I began to get better and went into remission, I had learned how important it is that information technology is accessible, that the world is accessible, how much of a difference it can make in individual people's lives, in our society, and it became a passion. So I hope you'll join me on that route to making the world more accessible, and we'll talk today about some issues of making the Web more accessible.

This is back as I said in about 1997. Soon after that, in 1999, WCAG 1 came out. One of the things WCAG 1 helped to define was what we needed to do for web accessibility. So now we were able to point to specific things. [pause for background noise] WCAG 1.0 came out in 1999 and that helped us know what we needed to do for web accessibility, and that was great. And then after it became more well known, then there was a lot more activity in making the Web accessible. But that was a long time ago. Technology has changed a lot since 1999. So, now what have is WCAG 2.0. We are working on WCAG 2.0 that is much more adaptable to different technologies and different techniques, and I want to talk about that.

[W3C WAI]

First a little bit of background. The W3C is the World Wide Web Consortium. It's the group that defines the standards for the Web, such as HTML, CSS, things you all know. Within W3C there is a group called the Web Accessibility Initiative, or WAI. And that's really cool to have this technology consortium that focuses on accessibility, that has a group that's dedicated to accessibility. And in fact within the WAI we have several groups. Some of those are the guidelines groups you hear about, and another is the Protocols and Formats Working Group. That group looks at all W3C technologies to make sure that accessibility is included as the technologies are developed, that the new technologies will be able to support accessibility. And they do some other work as well I'll talk about. We have an Evaluation and Repair Tools Working Group. We have Education and Outreach, which is what I do, that's why I get to come here and talk with you. We also develop materials, and I'll show you some of those. Then we have a Research and Development Interest Group.

So while you may hear most about the Web Content Accessibility Guidelines Group, we have a range of a different groups within WAI that are looking at different aspects of web accessibility.

[W3C Process for developing guidelines]

One of the questions that a lot of us had, and certainly I had even after I started working at W3C, is, What's the process for developing W3C specifications, guidelines, standards, technical reports, recommendations? I'll use those terms all interchangeably. We wrote a document that explains that. It's called “How WAI Develops Guidelines through the W3C Process: Milestones and Opportunities to Contribute." I encourage you to read that. I think it's about 2 pages. (It's got nice little graphics that I'll show you here in a minute.) It really is just a basic guide to what the process is and what the steps are. You can link and look at the formal Process document as you want to. This is gives you the basics to get started.

The first step that you often hear about is the Public Working draft. In fact all of WAI's work on the guidelines happens in public space. Anybody can subscribe to the mailing list, submit a comment, can read the minutes of meetings. All that is available publicly. With some W3C Working Groups and with the Protocols and Formats Working Group, most of that work is done in member space. So you hear public working drafts means that this is something that's out there for the public to look at. We've have several public working drafts of WCAG 2.0. The timing for those is when the Working Group had some particular questions. They felt like they answered a lot of questions but had some additional ones that they wanted people to focus on and to get input on, and at that time the Working Group published Working Drafts.

Last year, in 2006, the Working Group felt like they had addressed all the technical requirements that were needed for WCAG 2.0, so they published a Last Call Working Draft. Part of the effort behind that was to actively encourage the community and people, everyone from disability organizations, from small companies, from large companies, industry, from designers and developers, to take a really good look at that and to provide comments and feedback. In fact the Working Group got 900 comments, which is not unusual, but excellent to get all that feedback. So over that last several months the Working Group has been struggling to get through those comments as effectively as possible and spending a lot of time carefully addressing each of those comments, each comment got a response. On May 17, the Working Group released another Public Working Draft. Because there were substantive changes from the Last Call, then it went back to Public Working Draft status. That is what the May version is.

Now, what we're hoping, is that people will take another good look at that and submit any additional comments and then the next release, hopefully not too far away, will be a Last Call Working Draft. I'm imagining, dreaming, that everyone will say "Ah! That's it. It looks great, this incorporated everything that we needed." And then we can move through the process then from there.

The next stage is Candidate Recommendation and one of the main tasks in that stage is to get implementations. So to actually ask people to implement WCAG 2.0 in their sites so we can confirm, we can check that each of the requirements can indeed be met. So that's Candidate Recommendation, then Proposed Recommendation, and on to W3C Recommendation, which is a web standard.

Any questions on the process?

Audience:  [inaudible]

Shawn:  (Do you think the microphone is going to pick up the questions, or should I repeat them?)

The question is "What exactly is an implementation of WCAG?" A web site that meets WCAG. Pretty simple. One of the things that we will need to look at is that every requirement will need to be met. All the requirements won't apply to a single web site, presumably, so we will need to have multiple web sites to show that each requirement can be met. So that's milestones. I mentioned the document, all this is available online, I encourage you to go and read it. If you have any suggestions, let us know.

[How do I make my web site accessible? Understand accessibility issues.]

Let's shift gears a little bit and talk about "How do I make my web site accessible?" What can you do to make your web site accessible? The first the thing I'm going to say is not, Read the guidelines. Here we go again, don't quote that out of context. (It's a reference to the past.) [side comment about visual]

The first thing I'm going to say is: understand accessibility issues. Really, in order to develop an accessible web site you need to have a basic understanding of how people with disabilities use the Web, a basic understanding of assistive technologies and the adaptive strategies that people use. So I would say that's really the first step to developing effective and efficient solutions to web accessibility. There are several different ways you can do that. From the WAI there is a document called "How People With Disabilities Use The Web". There is another one called "Involving Users in Web Accessibility Evaluation". The idea is to involve users in design and evaluation from the beginning and throughout the process. This document is in an evaluation suite which is why it has that title, but it's important to include people through out the process. There are a lot of neat videos on the Web that introduce screen readers. There is one on the Yahoo UI Theatre as well, and I think there are going to be some more about different types of assistive technologies. Those are really neat and useful for getting an introduction. I also strongly encourage you to get some personal interaction and hands on knowledge on how people with disabilities use the Web.

[The vital role of guidelines/standards]

One of the issues is that there are so many different assistive technologies and so many different adaptive strategies, and ways that people use the Web, that there's no way even one person with a large budget and time could understand all the issues. That's one of the reasons we have guidelines, that's one of the reasons for standards and technical standards. What they provide is a way for us to collect all the knowledge and understanding and experience that we have, and develop a single shared set of requirements. So we can say, This is what's needed for accessibility, by gathering that information. So that an individual web site developer can look in one place and not have to try to recreate all that knowledge.

It's also very important to have single guidelines across the world. We interviewed several people at the South by South West conference last year and one of them was the Dreamweaver product manager. She was emphasizing that when there are different standards in different countries, different regions, then it makes their job a lot harder to support accessibility. When there is a single shared standard internationally that everyone has contributed to and that they can use, then they can do a lot more for accessibility in their tools because they can focus. So that's one of the reasons you'll hear ‘standards harmonization', we're really wanting to pull together and have shared standards internationally.

Another very important point is that the technical standards are adaptable and flexible. We've talked about how much technology has changed, and in fact WCAG 1.0, while it was great in 1999, it doesn't apply well to some of the situations today. So that has been a primary motivation, a primary requirement with WCAG 2, is to make it last through time. To make it work for technologies today, to make it work for W3C technologies, for non-W3C technologies, and to make it work for technologies in the future. To also make it work for the techniques that we know today, this is how we make the Web accessible today. But that's going to change, not only with fundamental technologies but also as assistive technologies change, as the Web evolves, so we want these standards to be able to adapt and be flexible. I'll talk a little bit more about how they do that.

The other thing we need is some how-to guides or techniques on how to make the Web accessible. We need them at different levels. We need techniques for people doing rich Internet applications, we also need techniques for people doing multimedia. We also need techniques on the other end. For example, my in-laws have a farm in Iowa. They have a web site where they update what fruit you can come pick that day. We need to have the web design – and I'll talk more about that - and guidance for my father-in-law, so he can make his web site accessible. So there is a definitely a role, an important role, for guidelines and standards.

[How WCAG 1.0 differs from WCAG 2.0]

I'm going to talk a little bit about the WCAG 2.0 Working Draft and how it's different from WCAG 1.0. In WCAG 1.0 we had guidelines and each guideline had checkpoints and they were priority 1, 2 and 3. With WCAG 2.0 we still have guidelines. We have a level above that called principles, the principles of accessibility. In short they are: make sure that your web content, your web site, is Perceivable, Operable, Understandable, and Robust. You can go and read more about those. The principles organize the guidelines and gives us the basics. Then we have the guidelines, and then we have the success criteria. The success criteria are at level A, double-A and triple-A. There is more than just a difference in terminology between the checkpoints and the success criteria. Indeed one of the big differences is that the success criteria are designed to be clearly testable. One of the issues with WCAG 1.0 was that it wasn't always clear whether a web site passed a checkpoint. In WCAG 2.0 that was one of the requirements, to make it more testable. The success criteria are those testable statements.

Let's look at an example. WCAG 1.0 checkpoint 2.2 says "Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits..." Alright it's pretty easy to understand, but if I showed you a web page with different color combinations would you be able to say, “Yes, it's sufficient and meets this”, or “No, it doesn't”? You can't. It's too into the gray area (pun intended) to be able to distinguish, because this checkpoint is not clear enough. The equivalent one in WCAG 2 is success criteria 1.4.3 (in this version) and it says: "Text (and image of text) have a contrast ratio of at least 5:1…" And there are tools that will evaluate what the contrast ratio is. So now it's very clear, we can tell, yes, it meets it, or it doesn't – it passes or it fails. One note about testability: there are success criteria for which the machine can say pass or fail; but, like WCAG 1, and I think will always be the case, human evaluation is needed for some of the success criteria. They are still defined very clearly so that when you have different people looking at it and evaluating it they should be able to come up with the same answer. But we still will need to use a combination of tools and humans in order to evaluate conformance to WCAG 2.0

[Flexibility and adaptability through the different WCAG 2.0 documents]

The next thing that I want to talk about is some of the different documents and the difference between what's normative—the required standard—and informative—which is optional. WCAG 2.0 is the document that's intended to become the standard. It's designed so that it can live through time, so that it's stable as technology changes, that it will still apply as we developed new techniques. In order to do that, it can't provide specifics for technologies because the technologies will change, and we need it to apply more broadly and across time. So what we have is Techniques, and the Techniques tell you how to meet WCAG 2.0.

There are currently general techniques, HTML techniques, CSS techniques, and scripting techniques, and there's planned to be more. And in fact, we are encouraging developers of non-W3C technologies to also develop techniques for their technologies so maybe you'll have PDF or Flash or XYZ or whatever comes up, to say in this technology here are the techniques to meet WCAG 2.

Now again, the techniques are informative. You don't have to use those. You can, but if you develop another technique, another way with a new technology or new information, that will meet the [success criteria], then you can. You can still do that. So it provides that flexibility as things develop over time and for a lot of community input and community to work together to advance accessibility and to share ways to make the Web more accessible. So we have the WCAG 2 and the Techniques.

This is one of the ways that we provide flexibility: to have the techniques separated. The techniques also can be updated more frequently; they don't go through the same formal process, they have a shorter process, so we can update those more frequently and informally update those.

Another aspect of WCAG 2 that makes it more flexible is what's currently, in this draft, being called Accessibility Supported Technologies. (It was, in the previous draft, called Baselines.) The basic idea behind this is to allow the flexibility for accessibility in different situations. Here's an example. If I'm developing a site for the Internet, I can't rely on SVG because not everybody has an SVG player that's accessible, so I wouldn't be able to create an Internet application for wide use that relied on that and is still accessible. I could use that technology for enhancement as long as it wasn't relied upon. So you can use technologies for enhancement or for alternate views or such, as long as there's a view where it is not required. On the other hand, if I'm developing an in-house application, and I know that everybody using that application has SVG support and it's accessible and I can confirm that, then I could use SVG. I could say the baseline for this app - or the accessibility supported technology list - for this internal application includes SVG, I know that everyone has it, I know that it's fully accessible; therefore, I can use it. So that's an example of the flexibility that's within WCAG 2.0.

WCAG 2.0 also WCAG more flexibility in terms of the specific requirements and the criteria, the success criteria have more flexibility. Just a quick example: in WCAG 1.0 checkpoint 7.1 says, “Until user agents allow users to control flickering, avoid causing the screen to flicker.” And user agents still don't allow you to control flickering, most of them, and so in WCAG 1 you weren't allowed to have flicker and there are some other movement limitations with WCAG 1. With WCAG 2 there's more movement allowed and there are just some specific requirements to ensure that, for example, the movement doesn't cause photosensitive epileptic seizures. So there's more that you can do - we have more research now, we're more able to clarify what is a safe range and what is not, and that's built into the guidelines. So an example of just in general of how WCAG 2 also allows designers and developers more flexibility in following the guidelines and in design.

Another issue that's very different is scripting. Back in 1999 there was almost no - maybe no, maybe the zero - support for scripting in common assistive technologies. So in order to be accessible you really needed to make your web site work without scripting, with scripting turned off, or when it's not available. That's changed now. All of the major browsers and assistive technologies, such as screen readers, support scripting. So now we can actually use scripting, even in some cases to enhance accessibility. There are definitely things that we need to do to watch out for additional accessibility issues around scripting, but it's no longer a “no-no”[to be avoided]; now it's actually encouraged in some cases. In fact there are specific scripting techniques in the techniques [for the] guidelines; for example:

So there are different things where we say, Hey, go ahead, use scripting. There are ways that you can use scripting to advance accessibility in these cases.

[Accessible rich Internet applications (WAI-ARIA)]

How many people have heard of ARIA? Alright. ARIA is Accessible Rich Internet Application Suite, the WAI-ARIA. (I think people have heard of it just because we got a good acronym. [laughter] We've played with some other ones for the whole package around web content, I won't share, we got kind of silly on those. We came up with a really good one but it was taken by something we really didn't want to be associated with, so we're still working on that.)

This one [WAI-ARIA] has a good acronym. But it's also really cool and cutting edge and this is some other work that's going on in the Protocols and Formats Working Group. What this is doing is looking at how to make some of the more advanced features of dynamic content and rich Internet applications accessible. It's particularly looking at how to provide information about user interface controls to assistive technologies. For example, if you have a menu or a tree control, how can we make the information about the nodes available to assistive technologies, and being able to tell where I am in a tree, expanding and collapsing, and getting around and navigating a lot faster in those. Looking at general role and state information are some of the things we're doing with ARIA.

Now the status of ARIA is it's moving really fast, which is great. We just, I think last week, released another Public Working Draft of some of the documents in the suite. The hope is that the next release will be the Last Call, so they're really moving on that.

Most of the work so far has been on the technical side, and the primary audience for that is tool developers. Very soon, hopefully with the next release, there'll be a Best Practices Guide for web site developers. There are things that the tools need to do, but they're working on what do we need to do when we're designing web sites. That should be coming out shortly, so look forward to that combination in helping understand what we need to do.

Right now there is a brief overview of ARIA, so if you haven't heard of it I would encourage you to go and look at that, and then keep an eye out for the Best Practices. And if you're really into it, look at the other information as well and you can learn what's going on from the tools side, that is, both primarily browsers and assistive technologies.

Now one of the other really cool things about this is that we already have implementations. There already is at least one browser and at least one screen reader that are implementing ARIA. This is moving along fast and it's great to see. It's really exciting to see accessibility getting involved early on so we don't have this problem of the Web moving faster than the accessibility enhancements. So we encourage you to follow that work and look at how it can help with your applications.

[Understanding and implementing WCAG 2.0]

Let's talk a little bit more about the differences in WCAG 1.0 and WCAG 2.0.

One of the issues with WCAG 1.0 when it came out in '99 is people weren't really sure how to interpret it or implement it. Actually I was - (eventually after I decided I was going to do accessibility, and all of a sudden once it was a requirement people started doing it, and I decided, Hey, that's what I'll do for my full-time gig) - so I was consulting in accessibility; I was not at first involved with WAI at all. We had a lot of questions about interpreting the guidelines, I mean [such as]: What do they mean by this checkpoint? How do we implement it? People would say: How does this help people with disabilities anyway? So with WCAG 2.0, that information is all provided.

In 1.0 there are some simple techniques. In WCAG 2.0 the techniques are much more robust, you have lots of examples of what you need to do, you have tests and such within the techniques, and then we have this whole reference manual called Understanding (and Implementing) WCAG 2.0. This will tell you the intent of the success criteria and the guidelines—what was the Working Group thinking, what did they really mean by this. We've got nice short succinct text in the guidelines themselves and the Understanding [document] gives you much more explanation. It tells you how it helps people with disabilities, it tells you key terms, more examples, and links to the techniques - so a lot of information in there.

One note, this [the Understanding doc] is not intended to be read cover to cover at all. Instead, it's a reference guide, and we'll talk about how to get into that.

[WCAG 2.0 Quick Reference]

That's a lot of stuff. We have something else that's been incredibly useful. I think the primary thing as you're developing your web sites you're going to want to look at is the Techniques, and the easiest way to get around and see those is through the Quick Reference.

Let's take a look at the Quick Reference. [video displays http://www.w3.org/WAI/WCAG20/quickref/#visual-audio-contrast-contrast] So if we were wanting to look back at color contrast, we looked at that earlier, let's say we want to look up more about color contrast. In the Quick Reference you can get these guidelines and success criteria, and we're looking at the success criteria. We've got a nice little short couple-word handle. It says this is contrast, it's the minimum requirements for contrast. It has the full text of the success criteria: “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 tells you that's level AA. And then right after that is a link. The link is “Understanding Success Criterion 1.4.3”. So if you're reading that and you're going, Huh? Don't know what the - I want to know more about this. You can click on the link and it'll go to the Understanding document where you can get all the background, more examples, and such on that.

Then the next section is Sufficient Techniques, and these are the techniques that the Working Group has said, Hey, if you do this, you got it, you've met the success criteria. These techniques are short sentences, and if you look at it and say, Oh yeah, got it, understand that, you can just keep going. Or, if you want some more information you can click on it, go to the Techniques, and you can actually see the examples and more information on how to do that. So this is where I think you'll spend most of your time - is looking at the techniques that say exactly what to do.

The other thing that's new in WCAG 2 (I don't think we had this in 1) is Common Failures. This says, here are some examples of how you can mess up and not meet this success criterion. For example, for this contrast one, a common failure is specifying a foreground color without specifying a background color, or vice versa. So you can look at that and say, Oops, yeah I gotta check that and remember that.

There are also Advisory Techniques. These are not required to meet the guidelines but here are suggestions for other things you can do to meet the guideline, or the success criteria. [Note: Please see the official description of Advisory Techniques in the WCAG 2.0 documents.] And again, you don't have to use these techniques. There's defining what you can do, but there's flexibility to be able to define other techniques that will also meet the success criteria.

(You look like you might have a question. No, okay, just thinking, processing. Alright, great.)

So again, nice neat package. I strongly encourage you to use the Quick Reference. I think it's going to be what most people use most of the time for getting around the guidelines. We had originally thought we might develop a separate user interface, but now I'm thinking that this might be all we need, so I'd love to hear your feedback on how this works, if this works for you, it doesn't, on what things we can change to make it work better, because this might end up being the primary user interface to get at all the information, if it works, let's see.

[The Quick Reference is customizable]

The other thing I want to point out about the Quick Reference is you can customize it. If you have all the information, it gets kind of long. But you can select just the information that you want to see. For example, you can select which technologies you're using. Right now it's set up so that you can turn off things like multimedia and SMIL and scripts. SMIL is Synchronized Multimedia Interface Language, something like that. (I said I'd define all my acronyms, but I don't always know the definition of the acronyms.) - and scripts. So if you're just doing a simple site, you can turn off the technologies and the things you're not using. You can also select which level success criteria you're using. So you can use these options to filter what's shown in the checklist to make it smaller and more relevant to what you're doing. This is another area where I'd really love to get your feedback. We've got some ideas on different ways to do this and we wanted to get this out with the announcement, the new update on the 17th of May, so we haven't even implemented all of our ideas yet. We'd really welcome your input on what works. If we want to get on the phone and do a quick informal usability test, we can - you can certainly send in your comments as part of the review period or whatever works best for submitting comments. Are there other things you would like to be able to filter this for the list? Does this meet your customization needs, or are there other ideas you have for what would make this more useful for you? So I'd really love to get your feedback on that. That's the Quick Reference.

[Other WCAG 2.0 Supporting Documents: Overview, FAQ, Changes]

We also have some supporting documents. Those were developed mostly in the Education and Outreach Working Group. We have the Overview of WCAG 2, and I would ask if you hear anyone talking about WCAG and they're pointing directly to the technical documents ask them, Hey, point to the Overview first, because the Overview explains in text a lot of what I'm saying now, and so for people who don't get the opportunity to listen to this or to read this, the Overview gives some of the basic introductory information, and really starting with the Overview will help significantly.

There's also the WCAG 2 FAQ and we keep that updated fairly regularly.

And then we have with this 17th May release, a document that explains some of the current issues, some of the changes that were made, some of the rationales for the decisions that were made, between the 2006 Last Call Working Draft and the 17 May 2007 Working Draft. So if you're a person who's been following that and are interested in how the issues were addressed, I would encourage you to read that document. It addresses things like validity, baseline, coverage of people with cognitive disabilities and the accessibility issues, and that kind of thing is covered in the changes document. It's useful if you're at that level of interest.

[Benefits of WCAG 2.0]

Wrapping up on WCAG 2.0, the current working draft, some of the benefits: having a shared international set of guidelines provides a common definition, a common benchmark, that we can work with around the world in defining accessibility. We've developed WCAG 2.0 so that the guidelines provide that stable foundation; but then we have flexible, adaptable ability through things like defining what technologies currently support accessibility, by being able to develop new techniques, and to have the techniques that apply to different technologies now and in the future. And we have that extensive supporting information that's available so we don't have to - (I started to say pay consultants so much to interpret but, maybe we should edit that out) - extensive supporting information that's available to answer your questions more easily and give more information. Okay.

Questions on WCAG 2.0?

Audience: With the accessibility supporting idea, like the baselines model, was it intended that people could produce sites just using Flash where the content is in Flash?

Shawn:  Okay, so the question is with this accessibility supported baseline model, was the intention that someone could create content using Flash. There's not yet a list of which technologies are accessible - are on the list of what's accessibility supported, so I don't know the answer to that direct question. I don't know if anybody does yet. Maybe they do, I'm not sure. Certainly the intention is that at some point, whether or not it's now, another technology, such as Flash, absolutely could be. Yeah.

Audience: I mean, is the baseline … [inaudible] Is there an actual criteria for determining what … [inaudible]?

Shawn:  Is there an actual criteria? Yeah, there is, in the conformance section of the 17 May version. There are steps: this is what is means to - this is what you what you have to do to be considered an accessibility supported technology. Yep. And so again, the plan is that WAI will provide a list; but just like the technologies this is a suggested list, and you might say: okay, we want to use another technology, we're going to go through and determine and demonstrate that it is sufficient for accessibility so that we can use this other technology. So again, the whole idea here is WAI will provide the basics but allow flexibility for other people to do additional stuff if they want to.

Audience:  Have you consulted with companies like Adobe in drawing these up?

Shawn:  Yes. The question is have we consulted with companies like Adobe in drawing these up. Absolutely. As a fact, one of the co-chairs of the WCAG Working Group, at the time she became co-chair, was working for Adobe, and so absolutely we have and we've encouraged the participation from Adobe and back before that from Macromedia, and we continue to do that.

With the techniques for other technologies, the plan is that we would not develop those ourselves but that we would actively work with other people to develop them. So when the XYZ technology says, Hey we want to develop [techniques] for how you can use our technology to meet WCAG 2, we'd be like, Great, you know, we'll look over them, we'll help you with it. We'll have to see with the timing and how formal that is, but we encourage that, we support that, and we will point to it, once it's worked through and such. So absolutely, we encourage that. I mean, the goal is to make the Web accessible. And we've got more flexibility, and it's not like 1.0 which - with 1.0 the idea was we know that W3C technologies are developed with accessibility in mind, and at that point most others weren't. Now, clearly accessibility is more included in development of other technologies. (Whether or not it's totally there yet? I'm not going to stand out on a limb and say right now.)

Audience: You mentioned that one of the ideas behind WCAG 2 was to have it be one standard and one recommendation, instead of at the moment with fragmentation. Is anything happening with Section 508?

Shawn:  Yep. So the question was: I mentioned that the intention, the hope is that we can have a single set of guidelines - which I'll talk about in a minute - and is anything happening with 508? The answer is yes. 508 you're referring to is Section 508 of the Rehabilitation Act in the United States, and they define some requirements for accessibility of web sites and other products. Over the last few years we have actively engaged with the U.S. Access Board, which is the group that defines those 508 standards, and we said, Please review WCAG 2, we want to talk with you, we want to work with you, in the hopes that if and when 508 is ever reopened for edit that what we've done with WCAG 2 can ideally meet the same needs. Because certainly the fragmentation between Section 508 and WCAG 1 has been a big problem for a lot of organizations, and that's something we'd like to not have. That dialogue has been very good the last few years with Access Board, and working together and getting comments, just like we do from everybody else, you know, we have public comments. That's a dialogue we wanted to make sure to foster, as well as with some other international standards activities. We've been in dialogue with some of the work going on in Japan and in Europe and really doing what we can to bring people together. And in fact, 508 has now reopened up. 508 is being - the term is refreshed, refreshed. And WAI is on the committee that will provide recommendations, so we're continuing that dialogue and hoping that we can come together on a shared standard internationally, especially in the U.S.

Audience:  [inaudible]… going on in Europe, particularly in Holland and Sweden.

Shawn:  Yeah. In Europe, there are similar issues in Europe, with individual countries making - having different guidelines. WAI has a staff member in Europe, Shadi Abou-Zahra, and he spends a lot of time working on that issue, standards harmonization. We have a document on - I don't remember the formal title - but it's basically why standards harmonization is important. I'd encourage you to read through that. Part of what we need is a community saying, Hey, country, don't go do your own guidelines. That document has some of the reasons why people do it and some of the discussions to help them understand the issues. We really need your help in sharing a voice to say this is why it's difficult when we have multiple standards.

Audience:  Do you recommend that the way that the U.K. with PAS 78, whether that isn't the better approach, where instead of actually defining it in technical standards it basically refers to  what the W3C has available?

Shawn:  Yep. So the question is with PAS 78, which is Public - what's the acronym? Publicly -

Audience:  Publicly Available Standard.

Shawn:  Publicly Available Standard.

Audience:  Specification.

Shawn:  Specification. (I had somebody send an email after Tuesday night and said I hadn't defined that acronym, but they didn't say it while I was there so I couldn't give them a quid.)

I haven't looked at that for a long time, but my recollection is that we strongly agreed with how they did it. We find that it's best for individual policies to point to a [shared international] standard. And right now we are hoping that any policies that are developed would point to WCAG 1.0 with wording that would allow for moving to WCAG 2.0. It doesn't have to automatically say we're going to do it. I mean, it's expected that it would still be an evaluation to make sure that that's what the organization wants to do, or the government or whatever, but that's what we are encouraging. So point to WCAG 1.0 for now with language that clearly says we'll move to WCAG 2.0 once it's available.

[When to use WCAG 2.0]

A little note about that and when to move. Certainly in terms of policy you can't yet say do WCAG 2.0, it's not done, and it is changing, it changed a lot since the Last Call in 2006. However, most of the fundamental issues aren't changing. The things that changed were some things changed levels and some of the specifics on the requirements changed, but the general what you need to do for accessibility, that didn't change. And so, some organizations are already using WCAG 2.0 Working Drafts in their development. They had the advantage of having all this additional support in the Techniques and in the Understanding document, and also being ahead so that once WCAG continues to develop and gets done they'll be ahead of the game. So I encourage you to go ahead and start looking at WCAG 2, start using it. Be aware that some of the little details may change, but go ahead and start using it. Any other questions?

Audience:  Are there any serious conflicts between WCAG 2 and WCAG 1 that would prevent that from happening?

Shawn:  Excellent question. Are there any serious conflicts between WCAG 1 and WCAG 2 that would prevent that from happening? No. One of the requirements was that WCAG 2 needs to be backward compatible. So you absolutely can develop a site that meets both. Yep, you can develop a site, so go ahead and do it. And in fact what you'll find is that in most cases it'll be easier to meet WCAG 2. The fundamental issues are the same. There are only a couple of differences in terms of the basic requirements. The one I can think of is with WCAG 2 there are some additional requirements for error handling, for giving help with handling errors, input errors, and that wasn't in WCAG 1. But other than that there's not a lot of difference, except for more flexibility, like I said, so –

Audience:  Yeah.

Shawn:  Yeah, you could very well say, I'm still required to meet WCAG 1 so I'm going to do that, but I'm also going to meet WCAG 2. Yeah, go for it.

(And there was something else I wanted to say about that, what was it. I can't remember. I'll remember in three minutes. That's how long it takes things to bubble back up. That happened earlier today anyway, it was - oh yes, I do, 30 seconds not three minutes, I got my zeroes wrong.)

We have with the last Working Draft and we'll have again, we just haven't updated it yet, a mapping between WCAG 1.0 checkpoints and WCAG 2. So say, I know what WCAG 1 checkpoints, how is that handled on WCAG 2? That'll help you if you already know WCAG 1 and you're looking at WCAG 1, help you with getting in WCAG 2. We also have started a document on how to transition from 1 to 2. We're going to be providing more of that support. Alright?

Audience:  With the WCAG 2 Last Call last year and there was quite a vocal backlash for the Web developer community to an extent that a small group decided that they would stay WCAG 1 and try to include all that. Now, they published the document yesterday I think. And are there any plans for the W3C to have a good look at that, take on board some of the improvements they've suggested, and maybe bring those into the techniques document for WCAG 2?

Shawn:  Absolutely we'd take a good look. I mean, it was announced yesterday at the last session, I ran back to the hotel, people were standing by, I sent them the URI, and then I went off to the pub. [laughter] So, yeah, they looked at it while I was at the pub, having dinner, of course. And so, especially those on an earlier time zone - and then I got back - I actually left early, and that's what I did last night when I wasn't at the pub having a drink. So we looked at it, absolutely. We looked at all comments. There were comments that were submitted - I'm not sure how formally they were submitted - but we were aware of, and we take those into account.

The whole idea of WAI is to bring together difference of opinions. It's easiest if those are actually sent to us, but we also, you know, we all have the feeds and we get notified when someone blogs about 2.0, you can bet that. So we're watching that. We've looked at it. We also looked at doing a 1.1 version ourselves, as I think is mentioned in the other, the Samurai Errata, and decided against it. I think what you'll find - I skimmed at it, I haven't looked in any detail, I don't have a formal reply yet, but I think you'll find that there are a lot of the same issues with WCAG 1. I think some of the guidance will probably be nice and simple and outdated, I mean, WCAG 1 is outdated. It's still what we have and if you have to point to a standard, it still defines accessibility, but it's not as good as it could be for today's technology. And certainly in a quick skim that does address some of today's technology; it doesn't address all of today's technology and it's not flexible for developing future technology. It doesn't have the flexibility that we built into WCAG 2. So absolutely we're looking at it. I haven't looked in detail, but I'm guessing that probably anything that's required and necessary for accessibility and not too technology-specific is already included [in WCAG 2.0 Working Drafts]. I mean, it's errata to 1.0 which we've been working with since '99.

Yeah, we take all input seriously and we appreciate all input, especially constructive input of people who've read the guidelines and thought through them and sent us comments. We really appreciate it, because we want the guidelines to work for everybody. I mean, they'll only make the Web accessible and they'll only be successful if they work for everybody in current situations. (Alright, shall we move on? Cool. Good, I was afraid, small crowd, might not get questions. We've been talking about WCAG 2 this whole time. Alright.)

[Responsibilities for web accessibility]

I'm back to the image of the fuzzy screen. With the fuzzy screen, with the blurriness, you can still read some of the text. The big text is still visible. You can see “Just Ask Integrating Accessibility Throughout Design, Paperback, and you might be able to recognize that that's amazon.co.uk, but probably not read any of the details. And this is about the only option back in 1997, '98, '99, when none of the major browsers had good zooming. One of the major browsers had some font resizing if the author had marked up their fonts with relative units and not absolute units. But today and a few years ago, Ahh there's a browser that did beautiful zooming, and so all of a sudden because this mainstream free browser now provided text resizing, then it was no longer an issue, so I could resize the text and see it just fine.

I want to use that as an example of talking about the other aspects of web accessibility, what we'll talk about as the “components” of web accessibility. We talked about content; that includes everything, forms, images, text, applications. We have the Web Content Accessibility Guidelines, WCAG, to define what we need to do for content.

Shawn photo
[image description at http://www.w3.org/WAI/intro/components-desc.html#relate]

People use browsers, or other media players, or what we call ‘user agents' to get at content. They also use assistive technologies. Some people with disabilities use screen magnifiers, screen readers we've heard of, switches, different strategies and technologies to get at the content. We have User Agent Accessibility Guidelines that 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. So we need to be aware of these shared responsibilities and what the browsers and assistive technologies can do (and you may have heard some more about that this week).

On the other side we have developers using authoring tools and evaluation tools to develop content. Now, what are some examples of authoring tools? Just yell out. (The easier ones first for those of you who know the punch line.)

Audience:  Dreamweaver.

Shawn:  Dreamweaver. What else are the basic ones you think of? What do you think of first when I say authoring tools?

Audience:  [inaudible]

Shawn:  Okay. What else?

Audience:  Someone's got to say it, FrontPage.

Shawn:  Someone's got to say it, FrontPage, thank you, that's right. These are the things that we think of as authoring tools, but there are other things that are authoring tools, such as -

Audience:  Content management systems.

Shawn:  Content management systems, CMS. That's probably one of the biggest issues with accessibility and authoring tools today, is that many sites are developed using content management systems. And what we'll find is that there are so many things that authoring tools can do to make developing accessible content easier. For example, with a content management system, our easy example of alt text: When I put in an image and I type in alt text, does it save it in database? - so that the next time I place that image on a web page, it brings it up and it says, Do you want to use this alt text? - or maybe the image is used in a different context so I need different alt text, so it allows me to put in different alt text, and stores that in the database as well. And the next time someone puts that image on a web page, it says, Do you want to use one of these alt text or do you want to do something different? So just that one little example of how the content management system can make accessibility easier and better for the developer. There's many more examples, many more issues, that the authoring tools can do to make our jobs as developers easier and to allow us to get more accessibility into our web sites with less effort, and I think that's a major issue.

What are some other authoring tools?

Audience:  Blogs?

Shawn:  Blogs? Blog comment features or just defining your own blog, yep. What else? What about photo sharing sites, what about social networking sites?

All these are authoring tools, because they're used by people to develop, to make content for the Web. And we need to make sure that all those are allowing us to make accessible content, and that all these authoring tools, including the basic WYSISYG (what you see is what you get) we know and the content management systems are also accessible to people with disabilities, so that people with disabilities can also contribute content, whether they are full-time developers in a web shop or adding a blog comment.

We've also defined what the authoring tools need to do. So we have ATAG, Authoring Tool Accessibility Guidelines 1. That was developed a few years ago. We've been working on ATAG 2. I think it went out to Last Call last year as well and it gathered comments, and I believe they are waiting to sync with WCAG 2, so I think that ATAG and WCAG may come out at the same time.

One of the important things to think about in the timing of ATAG is that now is a great time for authoring tools to look at ATAG 2. Just as we said there's advantage to start looking at WCAG 2 for your own web sites, there's great advantage for looking at ATAG 2 for authoring tool developers. What I would ask you to do is to really encourage them to do that. The other thing that I've heard talking to people that develop both browsers and authoring tools is: we want you to send us email and requests for accessibility. For example, the accessibility program manager for one of the authoring tools that you mentioned (I won't say which) said I want emails, I want people bugging us, I want people saying, Make this accessible, this is important. Because what happens as a product manager for these tools, you're getting a lot of requests for features and improvements and changes to the product, and when you have a couple of people saying accessibility is important, it's easy to say, Yeah well, I've got to do other things. But when you have a whole community saying accessibility is important, this is going to impact our purchasing decisions. Do you meet ATAG? ATAG is going to be part of our procurement. Accessibility is important. These are the features we need for your authoring tool to have for accessibility. When we have a bunch of us sending email and providing that feedback, that we're going to have more of a voice in getting accessibility improvements in authoring tools, which can make a huge difference in accessibility. Because my father-in-law does not have time to learn about accessibility. I mean, that's what I do and it's my passion, and I can't ask him to do that, he runs a farm, among other things. So we need to make the simple tools that he uses to update and create his web site, we need to have accessibility built in as much as possible. So help that with the authoring tools.

I've been saying this for a while and then earlier today, or yesterday, at the @media conference, I overheard Molly Holzschlag, who is now doing some work for Microsoft and on Internet Explorer, encouraging someone to do just that, send feedback, get riled up, get the community together. And I said, “Can I quote you on that?” She thought for a minute, and then she said "ROARRRR". [laughter] Yeah, let's come together as a community. The people who are trying to get the advances want the community support, so let's all roar. I'll say at the end a little different version on roar.

[Advancing web accessibility]

I talked a lot about WCAG 2.0 and the user agent guidelines and authoring tool guidelines, but I want to kind of bring it back together and say what can we do as a community to advance web accessibility, in addition to encouraging the browsers and assistive technologies and the authoring tools to improve accessibility. Reminder what I said at the beginning: For us all to understand more about how real people with disabilities use the Web on a day-to-day basis, that all developers who had had some basic understanding of that. Let's not get involved in courses, let's make sure that when people are initially learning about developing web sites they get some exposure to accessibility. And that as we develop, we include people with disabilities throughout the process.

Now, I'm going to step out of my W3C hat and tell you about a project I've been doing on the side: a book called Just Ask: Integrating Accessibility Throughout Design, and that's what it's mostly about. There's a lot of detail in including accessibility in a user-center design process, and the beginning is in general some more basic steps on including people with disabilities and accessibility throughout. The neat thing about this is the entire thing is available online free, so if you want the print version you can get the print version, but you can also just get it online free. Search for Just Ask Accessibility and you can read it all. So I'd encourage you to find out if you can get some information from that to help you with your process.

Another thing I want to talk about is just working together throughout the communities, bringing together different communities. I think it's really good that we're having discussions in the accessibility community. When we have open-minded, clearly thought out discussions where we debate pros and cons and what's the best way to do things, that's excellent and that can result in improving accessibility. One of the things I want to make sure about is that we be careful that people who aren't actively involved in accessibility just see that as a confused field. I think it's important that we have those discussions and then we grow and learn through dialogue with each other and different opinions, but that we also are clearly saying, Make the Web accessible. We're continuing to refine the best way to do that, but we have a shared message that the bottom line is to make the Web accessible (and don't mind us, we're working on it, but don't worry with that). So really working together within the community, I think personally especially, is really important.

If you want to help directly with the work of W3C:

Any questions?

Audience:  [inaudible] quite a vocal, if very small, accessibility community around web content, but it doesn't seem to be such a conversation going on with user agents and authoring tools. How can we go about encouraging that to happen?

Shawn:  I was going to ask you the same question. [laughter] The question is: we have an active community about web content, how can we go about doing that about user agents and authoring tools. That's something that we've been asking in Education and Outreach, I mean, that's my job actually. I think part of it is we need some better examples, I just did some quick stuff. We need some better examples to help people understand how powerful it can be. And I think let's keep talking on it. Let's keep talking on how we can do that because I do think it's vital. I think the improvements in the authoring tools are what's going to make the difference between the Web being accessible. Yeah, we've got some really dedicated developers and designers doing some great work on accessibility and spending hours and hours and lots of energy and thought and skill into that, but that's really only a touch of the Web, and most of the Web is still missing basic accessibility issues. So yeah, let's keep talking. Let's figure that out. Let's figure out what we need to do to bring that issue up. And now is the time to do it. We're also re-looking at UAAG, the User Agent Accessibility Guidelines. We're working on looking at if we want to do updates to those, so now's the time, let's talk. Let's talk as a community on that.

[Actively encourage accessibility]

Alright. Just a couple of notes in conclusion. I really want to actively encourage you to help people get real accessibility involved in their projects, to make the Web more accessible. I think one of the ways to do that is not (- I'm not in the - I don't want to say I'm not a roarer, I'll stand up and shout when I need to). There's one approach that's more attacking and sometimes that's necessary, and there's another approach (and I'm not trying to insinuate that's what Molly intended, so a little caveat there).

I think it's much better to reward people who do a good job. And so when we find browsers that are doing a good job, when we find features, when we hear about what they're doing, really actively blog about that, promote that. I mean, that's part of it: there's no discussion around it. So let's really promote the good things. Let's promote the tools that are doing the job and actively say, This is what we want, not in a way of, Oh you're doing a job, but [instead], Hey we're really behind you if you do this. When we have a tool that fully meets ATAG, which we don't yet, will we all rally behind it? You know, that would be good motivation. When we have web sites that do a good job of accessibility, let's really support those. And encourage individual development, whether it's within your own organization. Do people get gold stars, do they get bonuses, do they get raises, because they're doing a good job of accessibility? Is that a part of the reward system within a job, within web site?

I'm looking forward to bringing accessibility up and helping people realize both how important it is individually, and to themselves, how it can make them a better web designer, how they can really make the world a better place for individuals and for society as a whole. So thank you for all your help with that.

[clapping]