By henny

In June 5th of this year Shawn Henry from the World Wide Web (W3C) Web Accessibility Initiative (WAI) presented on "What’s new, WCAG 2.0, and current issues" hosted by RNIB in London. Shawn gave a great overview of what is happening with the Web Content Accessibility Guidelines version 2 (WCAG 2.0) as well as spent some time answering some really interesting questions from the audience.

It's taken a bit of time to get the transcript finalised (see an earlier post on the trials and tribulations of podcast transcription) but we're there now. A huge thank you to Stuart Colville of Muffin Research who helped organise the even and the University of Westminster where it was held. What follows is a transcript of the talk.

Henny Swan: Hello and thank you very much for coming tonight. Lots of familiar faces and some new faces, which is great. My name’s Henny Swan; I’m Senior Web Accessibility Consultant, RNIB, where we carry out audits, consultancy, and training. We also run the Web Access Centre as well as the Web Access Centre blog. We’ll be finding a podcast, a transcription of the event, hopefully in a few days’ time. It’s a great pleasure to welcome Shawn Henry tonight from the Web Accessibility Initiative. She’ll be talking about what’s new in Web Accessibility, Web Content Accessibility Guidelines 2.0 update, current issues, etc.

I think Shawn is planning to talk for roughly an hour, after which she would like to take questions, and she loves questions, the more questions the better. A couple of things before we kick off. Thank you to Stuart Colville; he’s helped us organise tonight as well as the University of Westminster for lending us this venue. And also, we’ll be selling copies of Shawn’s book Just Ask: Integrating Accessibility Throughout Design; it’s a really, really good book. It’s the first time you can get it on sale here in the UK. It is 22 quid. So if you’ve got cash or cheque, that would be great, preferably cash. And I think that’s it, so over to Shawn Henry.

Shawn Henry: Thank you so much. I also want to thank Stuart and Westminster University for the venue and especially RNIB and Henny for organising this; it’s a lot of work to pull together and it’s great to have this opportunity for you to come together and for me to talk. I love to talk about accessibility and I’ll try to keep it under an hour. I really appreciate this opportunity. (The other thing is, I just like seeing my name and Henny’s name together, isn’t it fun: Shawn Henry Henny Swan We’re working together on co-editing a document on how to transition your website from WCAG 1.0 to 2.0, and you might’ve seen Henny’s recent blog that’s related to that issue. So it’s fun just to see our names together on that.)

I’m going to start it off by talking a little bit about my background. (It’s something I don’t usually do; so you may learn some new stuff here.) In the mid 90’s, I was a user interface designer. I was working on usability, designing mostly client-server applications for large businesses. I was doing consulting and doing different types of interface design and studies, mostly for Windows applications. And I started to have some health problems. I started to have blurry vision and have some physical problems. So a lot of times when I tried to use the computer, it looked like this: this is a screenshot from Amazon and it’s all blurry. I had a problem using the computer.  I thought I was going to have to quit work, because you can’t work very well like this. I was living at Madison, Wisconsin, at the time, and that’s home of The Trace Research & Development Centre and they’ve been working in the field of accessibility for many years. So I hooked up with them and figured out I could do something about this instead of having to quit. I started learning more about accessibility. At the time though, there wasn’t a lot of guidance on how to make accessible IT products; there wasn't much out there. Then in 1999, the Web Content Accessibility Guidelines came out. And those really provided some concrete information on what we could do to make the Web accessible. So, great, alright, let’s go do it! Well, people still weren’t doing it. And then, a couple of years later, I can’t remember the exact year, more policies started coming out requiring Web accessibility. So all of a sudden people started taking it more seriously, understanding more about what they wanted to do, and really actively looking at incorporating accessibility throughout their products. So that’s what I’m doing now today. Even once I went into remission, I was like, ‘Hey, this is an important thing. Accessibility is so empowering for people, to be able to access information technology, the Web and other technologies. I’m going to make this my life’s work.’ So that’s what I have been doing.

The Beauty of WCAG 2.0

One of the things you may realize is WCAG 1.0 came out in 1999. Well, times have changed; technology has changed; the world is a lot different. We know a lot more about how people with disabilities interact with IT. The assistive technologies have changed a lot and continue to change. And that’s the beauty of WCAG 2.0. Did I just say WCAG 2.0 is beautiful? No, I won’t go that far. But certainly the approach to WCAG 2.0 is beautiful, in that it allows us to adapt as technology changes, it allows us to adapt as we learn more about how people with disabilities interact with the Web and how we can make that better a user experience for people. So that’s one of the main things I’m going to talk about today, as well as some other things. A couple of notes: feel free to interrupt if you need any clarifications, or if I use an acronym that I don’t explain. Actually, we’ll do this: if I use an acronym and I don’t say what it means and you catch me, I’ll give you a pound. [Laughter] I have to finish the sentence, because I might introduce the acronym and then say it. So at the end of the sentence if I haven’t said it and you catch me, you get a pound. Okay now everyone is awake. Feel free to interrupt if you have questions during the time I’m talking, if they are quick clarifications, let me know, raise your hand. And then we’ll have plenty of time for questions at the end as well.

Audience Poll

Okay, first question I have for you, because I really want to make this interactive and I want to find out a little bit about where you’re coming from. So how many people are willing to raise your hand when I ask questions? [pause] Alright, pretty much everybody, but not quite. Alright; thank you. First of all, let me find out about your experiences with assistive technologies and how people use the Web, and one of the easiest ways to talk about that, although not the only way, is ‘screen readers’.

So, how many people know a little bit about screen readers, at least a little. Okay, almost all hands raised. Great. How many people know a lot about how screen readers interact? Okay—just a few—alright. How many people are comfortable that they know what the deal is with the W3C (World Wide Web Consortium), WAI (Web Accessibility Initiative). [participants laughing] Okay, so most people raised their hand. What about WCAG (Web Content Accessibility Guidelines) 1.0? Pretty much everyone. I think when we take the margin of error of people who wouldn’t raise their hand for the first question anyway, then we’ve got everyone in on it. How many people have read through WCAG 2.0? Okay, we’ve got far less than a quarter. (How many people have actually worked on WCAG 2.0? We’ve got one up here, very good!)

W3C WAI, briefly

Okay, so this helps. I’m going to go really quickly through some basics then. Everyone pretty much knows W3C (I already explained it, you don’t get a quid) is a standards-making body for the Web, do things like HTML and CSS. WAI or W-A-I (Web Accessibility Initiative) is a group within the W3C. So that’s really cool, because a lot of organisations developing standards don’t focus on accessibility, and we’ve got this group within the W3C that does. We have several different areas within WAI. We have the Guidelines groups, which I’ll tell you about later. We also have a Protocols and Formats Working Group. And what they do is look at accessibility across different technologies. They review all W3C specifications as they’re being developed to make sure they address accessibility.

We are also currently working on the WAI suite for (I’ve got to get the acronym right) Accessible Rich Internet Applications, and that’s work on how we make Internet applications accessible. So that’s going on in that group. We also have the Education and Outreach Working Group. That’s the one that I’m primarily in and Henny’s also in that group. The handouts you got and my being here tonight is part of our education and outreach work. And then we also have a Research and Development Interest Group. So we do a lot of different things. Next I’m going to talk a little bit about terminology. I’m going to use these terms interchangeably. The WAI Accessibility Guidelines, the current ones are, and the ones we are developing are intended to become, what are called ‘W3C Recommendations’. (It’s a long history on why they’re called that and I’m not going to spend the time to go into that today. It doesn’t really matter.) What is important is to realize that these are essentially Web standards. Again, that’s like HTML and CSS, and they are functionally Web standards. So when I say ‘guidelines’ and ‘standards’ throughout the rest of the time, I’m using them pretty much interchangeably. If I’m needing to distinguish one or the other, I’ll let you know. So that’s a little bit of background about the W3C.

Where guidelines fit in developing accessible Web sites

Now I’m going to talk about you developing accessible Web sites. One of the first and most important things is to understand accessibility issues. A lot of people here know about screen readers. Hopefully you know about what it’s like to use a screen magnifier. Hopefully you know what it’s like to use a switch. What it’s like to use the computer visually but without a mouse. And what different issues there are with different disabilities and the combinations of assistive technologies and abilities. However, it’s not possible for any one person to know all of this. So while ideally as we’re developing Web sites as individuals and a team we know all the challenges, it’s not practical. I’m going to talk about how understanding accessibility issues is important as a whole; it’s important for you developing your specific Web site. And here’s just a few resources to help with that. One is How People with Disabilities use the Web. That’s an online resource from WAI. Another is called Involving Users in Web Accessibility Evaluation. And just to note, it has that title because it was developed as part of the Evaluation Resource Suite. Really, it’s important to include people with disabilities in involving accessibility throughout the entire design process. Just because that document happens to have been developed as part of evaluation, it’s vital to include it throughout the process.

W3C WAI absolutely encourages you to include people with disabilities and accessibility considerations from the beginning and throughout. However, you can’t know all the different issues, there’s just too much to know. Think about how much effort it is just to test on different browsers. Now when you add all the different types of assistive technologies, etc., etc., it’s more than you can do. So what we have to help cover this broad range and gather up all the knowledge and bring it together, is develop guidelines, or technical standards. One of the primary benefits and reasons and needs to have standards is to bring together knowledge and put it together in a way that everyone can access it. There are several other reasons. One of the big reasons is so that authoring tool developers and evaluation tool developers etc. can have a common set of standards and know what they need to work on for accessibility.

We did some interviews at the South by Southwest conference in March and we interviewed a Product Manager for DreamWeaver, Jen Taylor, and that was one of the big things she said, is when we have a single standard internationally, then it’s much easier for the authoring tool developers to incorporate that within their development process. If each organisation, each country, each region has its own standard, then the authoring tool developers have a whole lot more work to do and cannot get as much done in terms of accessibility. So, that’s one of the big advantages and needs for technical standards. Technical standards help us define what we mean by accessibility. It gives a benchmark for accessibility. So we know, here’s what we need to do - and that’s something we can work together as a community to develop and share and continue to grow. In order for standards to be effective, especially moving forward, they need to be flexible. They need to be flexible to meet different needs, now and in the future. So one of the beautiful things about WCAG 2 is how it’s designed to do that. I’ll talk some more about that later.

The other thing we need is some guidance on how you actually do this. So, as I go through, I’ll talk about the parameters for the standards, define how they can be written. What I mean is, in order to make them apply broadly, now and in the future, they need to be somewhat abstracted from how you actually do something in HTML, for example. Because if the standards were written just for HTML, then when XYZ-awesome-technology-for-accessibility comes out, then it wouldn’t meet the standards. And so instead, what we need to do is define standards so that they say, 'This is what we need to do for accessibility, generally', and then we have specific techniques, guides, that tell you how to implement that in a specific technology. And so two different things. And another thing we need is to have techniques for different levels. For example, my in-laws have a farm in Iowa and they have a website that they update it every day to say what fruit is available, it’s come pick your own, but they are not particularly computer savvy. My father-in-law has done really well with a computer, but he does not have a lot of time, and he's certainly not a web developer. So we need to make things easy for him. We need to make things easy for simple sites, as well as to develop more complex and in-detail things like we are for rich Internet applications. We need those techniques and guidance at different levels.

WGAC 1.0 to WCAG 2.0

Alright, I want to talk a little bit about some of the practical differences between WCAG 1 and WCAG 2, especially since most people here are familiar with 1 and not many with 2. WCAG 1 had guidelines, and under those guidelines were checkpoints, and the checkpoints were categorized in Priority 1, Priority 2 and Priority 3. WCAG 2 also has guidelines, but there is a layer above that which helps organize the guidelines and understand more what’s needed for accessibility, and those are called ‘Principles’. And the Principles are: Perceivable, Operable, Understandable and Robust. You can read more about that, I won’t go into details. We have principles, and the guidelines, and then we have success criteria. So that’s a little different. Instead of checkpoints, we have success criteria, and they are level A, AA and AAA.

Now this is not just a change in terminology; it’s actually a strengthening in approach. One of the issues of WCAG 1.0 was that some of the checkpoints were not testable enough. You couldn’t say whether or not a site passed it or not. And that posed problems in some cases. So with WCAG 2.0, that's been one of the defining requirements, to make it testable. Not saying it has to be tested with only tools, but also human evaluation is still necessary for some testing. But we want to make sure that you can go through a Web site and say, 'Yes, it meets WCAG 2.0 guidelines, or, No, it doesn’t.' So that’s one of the differences with the success criteria; it is much more testable. Now, here is an example of the testability and also a note on the levels. On the screen it says: 'WCAG 1.0 - Checkpoint 2.2 Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having colour deficits'. Right. Pretty easy to understand what this is. Now, if I show you a Web site. Could you say it meets or it doesn’t? Nah, it’s too vague. It’s a bit too difficult. You can’t. I mean surely there are some that clearly does or clearly doesn’t, but there’s a lot of grey area where you can’t tell. With WCAG 2.0, the similar success criteria says: 'Text and images of text have a contrast ratio of at least 5:1,' and there are links to several tools that will help you analyse that. So you can just punch it in and the tool will say what it is and say if it passes or it doesn’t. So you can see this is much more testable.

If you read previous versions of WCAG 2.0, or if you read some blogs on previous versions of WCAG 2.0, you might have a critique of the language, and… so did I. In previous versions they were really focusing on getting the technical aspect right. With the new version - WCAG 2.0 updated Working Draft was released on the 17th of May (and I’ll talk more about that) - one of the things they did is to really simplify the language and make it easier to understand. There is still a little more room for that, but it’s vastly better; it’s a whole lot better. Even this one used to say ‘luminosity contrast ratio’ which was not necessary and made it feel a lot more jargony and harder to understand. Another note while we’re here is that the priorities and the levels are a little different. For example a single topic can have multiple levels. This one has a related one that says 'Text and images have a contrast ratio of at least 7:1 dot, dot, dot' (by the way, there’s some more to each of those, that’s just the beginning) and this is at level AAA. And so in this case they’re saying, ‘here is some basic accessibility and you can go further as well’. And you’ll seen some of that in WCAG 2. I’ve already talked about what WCAG does for you, some of the advantages, and I just want to reiterate that. WCAG 2 itself is the technical standard. It lays the foundation for accessibility across technologies, now and in the future. It is intended to become a W3C Recommendation. We hope it will live a long time. It’s designed so that it can adapt to changing technologies, and changing techniques as we learn and grow. So that’s a foundation. Now, in addition to that, we have WCAG 2 Techniques. The techniques tell you actually how to meet the guidelines, specifically the success criteria. The there are some general techniques, and there are some techniques that are focussed on specific technologies: there are techniques for HTML, techniques for CSS, there are some techniques for scripting, and there are planned to be additional techniques. Someone else can define techniques for other technologies. Someone might define how you can make, for example, Flash meet WCAG 2.0, or upcoming technologies. So the key difference to understand is that these techniques can be updated, added to, edited much more frequently and much more easily within the process.

So the Guidelines themselves are stable, the Techniques we can continue adding to and updating as technology changes, as we do more user interface design studies, and as assistive technologies change, we can update those techniques so they stay current with what we are dealing with right now. Then another big difference with WCAG 1 and WCAG 2 is the amount of supporting materials. There’s a whole lot more information available. With WCAG 1.0, we found that… I was doing consulting, so after I finally said ‘Okay, I’m not going to quit work, I’m going to do something about it.’ I was still doing user interface design when I could and trying to get people to incorporate accessibility, and once it started becoming a requirement, and all of a sudden there was actually business. So I did consulting for accessibility for several years. And one of the problems we would have is when you’d look at WCAG 1.0 and say: 'Well, this is what the checkpoint states, but what does this really mean? You know, is this right or wrong? How do we interpret it? What did the Working Group mean?' And that was a big problem, interpretation, especially when accessibility is a requirement. So what the WCAG Working Group has done is answer all these questions.

So now you have the reference book for WCAG 2; there’s a document called Understanding WCAG 2 and it tells you all about each guideline and each success criteria. It includes the Working Group’s intention; how it helps people with disabilities; some examples; what are some bad examples, you know, how you do this wrong - all that information is available now with WCAG 2.0, where it wasn’t available before. One of the other things you might have heard is WCAG 2.0 is too big. I think that’s an advantage, that the supporting materials are so huge. WCAG 2.0 itself is rather short. The guidelines and success criteria are very short. (Right now the introduction is kind of long in this version, we might edit that down a little,) but the guidelines and success criteria are quite short. But then you can go and get all this additional information if you want. It’s not the kind of thing that you’re going to sit down and read unless, well, you know… [laughingly] get a life.

Participant 1: Unless someone pays you to do it. Shawn: Really its more a kind of thing where when you have an issue, when you’re looking at a certain thing, for example: I what to make my tables accessible, what is meant by that success criteria? Then you can use it more as reference material, rather than a start-to-finish read-through guide. One of the other things is when the previous Working Draft came out, we had planned to have a document that’s currently called the Quick Reference, but didn’t have it. It came out a couple of weeks or months or something afterwards. It’s really awesome. With the current Draft, it’s updated, and we made some improvements to the user interface. It’s still a draft and we’re still working on it in terms of making improvements to the interface. I want to show you that because it’s really, really cool and helpful.

WCAG 2.0 Quick Reference

Alright. How's this font size? Put you're thumb up if you want bigger? We’re okay? Great. (Oh, I probably shouldn’t have asked for thumbs up, that’s probably a rude gesture in some culture.) [Shawn laughs along with the participants.] Okay, so what we have here is the Quick Reference that gives you each guideline and each success criteria and then it lists out what techniques - remember I said that techniques are how you do it - what techniques you can use to meet that success criteria. These are the ‘sufficient techniques’. It also tells you some common failures, some things that you might do wrong. Then there are ‘advisory techniques’. And you can read more about what's meant by sufficient and advisory. I just wanted to show how that the Quick Reference is relatively simple.  Right now we’re looking at the Guideline 1.4. (And actually I wanted to go down to the one we were talking about.

Here we go. I’ll decrease the font size just a tad so you can see that we can get this pretty much on one screen, alright.) On one screen we have the success criteria; all the texts in the links of sufficient techniques, how you can meet that success criteria; common failures; and some advisory techniques - relatively simple, all together in one place. Then you can also get additional information. There’s a link to ‘Understanding the Success Criteria’, and that goes to the document I told you about that provides all the information about what the intent is, how it helps people with disabilities, etc. And then each of these techniques’ links goes to the Techniques document that actually explains what that is. Right. So that’s the Quick Reference. It’s really, really helpful. I assume that most people will use the Quick Reference as their primary tool in using the Guidelines, as opposed to reading through the Guidelines themselves and Understanding, that this would be the primary tool. (One of the things that we have also been looking at is the user interface and how you get at all this information, the usability of the different documents. We had planned to do some more work and had different ideas for the design. I’m thinking more and more that we might just work from this Quick Reference.) So let us know how this works for you. We would really like your feedback. This is something else that we can continue to revise. The content is pulled from the Guidelines themselves, but in terms of how we have this organised, we can keep making that better.  Then the other thing I wanted to show with this is that you can customise it. Currently with what’s available, you can say whether or not you are using technologies like CSS and multimedia, which level success criteria you’re working on, how much information you want included. You can make this more simple or more complex depending on what your needs are. This really can help scope the guidelines and success criteria down to what you need to know. And again, we welcome feedback on this and how it works for you.

That’s a little bit about WCAG 2.0

The handout you’ll read about it will say that it’s technology independent and it’s more testable and that it’s more understandable. Another way of putting that is the Guidelines themselves help provide a common definition, so we can all say, 'this is what we were working for, for accessibility'; and that’s needed. It’s flexible for technology as it develops and also additional techniques, whether they’re techniques for new technology, techniques for improving usability - some of the advisory techniques are techniques for improving accessibility for people with cognitive disabilities, and so we can continue to address those and refine it. And then there is a lot of information in the Understanding doc and you can get answers to your questions far more easily. So I want to see if there are questions, questions or comments on WCAG 2.0? Let’s take a little break for that. Yes?

Participant 1: [indecipherable] … Success Criteria 1.4.3. about colour contrast. Now level A says colour contrast is 5:1, but what I’m seeing is if you’ve got people with dyslexia, the more colour contrast you have, the more difficult it is for them to read the text. Shawn: The question is a specific question about the Success Criteria that we looked at, which was actually AA. Yeah, okay. And then you were saying that for some people with some disabilities, increased contrast makes it more difficult. Participant 1: How do we deal with that? Since there seems to be a conflict… [indecipherable] …solution. Shawn: That’s a specific question on the provisions of WCAG; I’ll do a quick answer now and then we can talk more on specifics afterwards. How many people are in usability and know much about usability? Okay, what’s the common answer when somebody asks you whether or not you should do something in usability? It depends! Right, yeah. It depends and there’s always the balance of needs. So what we do here is ideally you make it user customizable. And we’ll talk a little bit more about that, whether it’s user customizable through a user agent, through what the Web author does, or both. The bottom line is user customizable. Short answer. Other questions on WCAG 2 … yes?

Participant 2: Is there any concept of having any example design patterns in there or anti-patterns that would explain how to do the guidelines? Shawn: Yeah, so your question was: 'Is there any idea of having designed patterns, example interfaces?' Yes. Two things. Number 1: within the Techniques there are examples. (I should’ve mentioned that, so thank you very much for asking.) In the Techniques, there are examples. Most tend to be on one specific thing. Actually there are a few different things. We’re working on a demo, the Before and After Demo (BAD Demo), that shows an inaccessible Web site and then fixes for accessibility. So that’s one place you can look for examples. The other thing is that right now the techniques are organised very much according to the guidelines, but we plan to also have support materials that address topics like: How to make accessible forms, How to make accessible tables. There’s already a lot out there on that but that’s also something that we want to work on and correlate. So the first thing is to go and look in that (…are they under techniques or understanding?) Yeah, there are actually different types of examples in both the Techniques and Understanding docs; and you can get to them through the Quick Reference. Yes?

Participant 3: If they’ve just been updated, how can they be WCAG 2.0 still? Shawn: The question is, 'If they are just updated, how come it’s WCAG 2.0, still?' Actually WCAG 2.0 is still in Working Draft and I’ll talk a little bit more about that later. The 2.0 is not finalized; it’s currently a Working Draft. (So far all these questions are things I should have said anyways, so keep asking.)

Participant 4: We were just thinking how to tell when it is done. Shawn: It’s hard to tell when this is done? Participant 4: Yeah. Shawn: Yeah, yeah. In all the handouts that you have, I think we’re pretty good about calling it a Working Draft. (I’m checking. Yeah, there it is, up in current status of WCAG 2.0.) Yes?

Transitioning a site from WCAG 1.0 to WCAG 2.0

Participant 5: If I’ve got a site that is largely conforming to the WCAG 1.0 AA guidelines, what sort of scale of task am I facing to make it meet WCAG 2.0? Shawn: Okay, the question is ‘If I have a site that pretty much conforms to WCAG 1.0 AA, how much is involved in meeting WCAG 2.0?’ (This is great! I have to thank you for these questions.) Probably not much, is the short answer. As I said, Henny and I have been working on a document that tells you how to address that. Henny has a blog post already out that has some guidance on that. We have some experience of people who are already working on 2.0, but we don’t have any hard facts yet about how long. The thing is that the basic principles of accessibility have not changed. Some of the techniques and the specifics have. Mostly WCAG 2.0 gives you more flexibility, it allows you to do more things, it’s less restrictive. There are a couple of things that are new. The thing that pops to mind is error handling. There are some new requirements for errors, like if you have an input form and the user has errors, giving good instructions.

Participant 6: Really, the question is: I'm lazy can I do nothing?! Shawn: Yeah, this is right. [Laughs] (His follow-up question was basically, ‘I’m lazy, can I do nothing?’) At the very least you should go through it, and that actually will take a little bit of thinking because the approach is different. As I said, the guidelines themselves are more broad, and then you need to look at the Techniques to make sure that you’re meeting the success criteria. So, I’m sorry, you’ll have to do a little bit, you’ll at least need to go through it and make sure there’s not new stuff that you're missing. But we’ll have a lot of support to help you with that. In addition to the document that Henny and I are working on in the Education and Outreach Working Group, there’s also a document that maps WCAG 1.0 to WCAG 2.0, so you can use that to help what you’re doing. And I would say if you have a simple Web site, maybe nothing. Maybe you can be lazy. [laughing] If you have a more complex Web site, if you have forms, then probably you will need to do more. Yes? Participant 6: Just a clarification that the flexibility… [indecipherable]… in that it depends on usability. If I’ve got it right, basically the flexibility comes in doing something to achieve guidelines. Since the measurability whether or not the guideline is being met is still, I think, regardless of how you do it, it will be in the end result. So, in my organisation, … [indecipherable]… they did all this. So, it’s the end result that would be measurable. That’s all. Shawn: (Right, and that was so well said, I don’t think that I can repeat it, but I’m trying to because we're recording it.) And so basically the comment was: wanting some clarification about flexibility, as you understand it the flexibility is in how you do it but the end result is still measurable… Participant 7: What she is asking is whether the success criteria are measured against the process or against the deliverable. Shawn: (The clarification is: 'is the measurement of the Success Criteria against the process or the deliverable?') Okay, very good. Yeah, it’s actually the end result. So the idea is here we have Success Criteria, these are testable statements. You look at the Web site, you say it meets it or it doesn’t. That’s the set in stone part; that’s clear cut. Now, how you meet it?

Most people are going to use the techniques that are already defined, because the Working Group has already said, ‘if you do use techniques, you are done, you meet WCAG 2’. Okay, so it’s taken care of. Where the flexibility lies is, if I have a new technique; say, I’m using this new technology, or we’ve developed this new method and we’ve tested it and it works really great. Then you can say, this is a technique that I’m going to use to meet the success criteria. But the end result is still meeting the success criteria. Yes? Participant 7: How much of this lies with the manufacturers of assistive technologies? Shawn: The question is ‘How much of this lies with the manufacturers of assistive technologies?’ and I’m going to use that to transition to the next segment. But before I do, I want to point out one other thing. You’ve got the handouts and I really encourage you to look through these. There’s one on WCAG 2.0 and it has different information, like how you get started, what the different documents are, and I would strongly encourage you to start with the document at the top: Overview of WCAG 2.0 documents. And when you read or hear someone talking about WCAG 2 and they are not saying start with the Overview, please say, 'Hey! Start with the Overview when pointing to WCAG 2.0!' It really helps you know what the different documents are and how to get started. We also have a WCAG 2 FAQ and we keep that fairly current. You can see that has current status and what’s going on and answers some frequently asked questions. Another document that is not on here is called Summary of Issues, Revisions, and Rationale for Changes Since the WCAG 2.0 Last Call Working Draft. You can get to that from the FAQ. This is mostly important for people who are following WCAG 2 development and some of the questions and issues with the validity and coverage of cognitive disabilities and things like that.

Shared responsibilities: The Components of Web Accessibility

So now to transition a little bit to what you brought up, the component of assistive technologies. I’m back on the screen with the fuzzy text, probably from your vantage point, most of you can kind of see the heading. The main heading is 'Just ask: Integrating Accessibility Throughout Design in Paperback'. You can probably pretty much see that, but not a lot of the other text. So, if on this screen the text is increased you could see - and in fact most of the time with my vision, if I can get the text a little bigger, 150 percent of what’s common; then I can read just fine. So, whose responsibility is it to do that? That’s one of the things I’m going to talk about when I talk about assistive technologies. Alright. One of the myths I think that’s common is that most of the responsibility for accessibility lies within web developers. But, in fact, there’s really a whole system and assistive technologies are part of that system and there are other parts. Let’s look at that. So now to transition a little bit to what you brought up, the component of assistive technologies. I’m back on the screen with the fuzzy text, probably from your vantage point, most of you can kind of see the heading. The main heading is 'Just ask: Integrating Accessibility Throughout Design in Paperback'. You can probably pretty much see that, but not a lot of the other text. So, if on this screen the text is increased you could see - and in fact most of the time with my vision, if I can get the text a little bigger, 150 percent of what’s common; then I can read just fine. So, whose responsibility is it to do that? That’s one of the things I’m going to talk about when I talk about assistive technologies.

Alright. One of the myths I think that’s common is that most of the responsibility for accessibility lies within web developers. But, in fact, there’s really a whole system and assistive technologies are part of that system and there are other parts. Let’s look at that. We’re going to talk about the different components of web accessibility, the different pieces that need to pull together. When we talk about content, like the Web Content Accessibility Guidelines, we’re talking about images, forms, text, anything on the Web. People use browsers, media players or other what we call ‘user agents’, to access Web content. And some people also use assistive technologies, which most of you are familiar with.  (Illustration with labelled graphics of boxes, content, and people. at the top centre is a pie chart, an image, a form, and text, labelled 'content'. coming up from the bottom left, a line connects 'developers' through 'authoring tools' and 'evaluation tools' to 'content' at the top. coming up from the bottom right, a line connects 'users' to 'browsers, media players' and 'assistive technologies' to 'content' at the top.) The browsers and assistive technologies also have a role to play in accessibility. Text resizing is one of the key examples. Right now, I think most of the new browsers do a fairly good job of text resizing. Back then, none of them did. So, you know, back in 1997… (I’m not sure, when did Opera come out? I think it was after that. I didn’t know about it anyway.) Back then, if the site developer hard-coded their fonts using absolute font sizes, there was nothing I could do. It only worked if they had used a relative size. But then different browsers came out, a browser came out that could scale font and images regardless of what the author had done. And now, there are different zoom features in the latest releases of all the most popular browsers. So this is something now that the browsers are taking more responsibility for. There are a lot of other examples of that, where the browsers can do more to help accessibility. So, one of those questions is, ‘do I need to have a text control on my site?’ In fact, with the WAI site, when we re-designed it, we had this question, ‘Should we do that or not?’ What we decided is to follow a different philosophy. You know the expression, ‘If you a give a person a fish, they eat for a day; if you teach a person to fish, they eat for a lifetime’. So what we did is, put a link 'change your text size or colours', and that goes to a page that tells you how to do that in different browsers. Someone else who did something like that is - I think, is it the BBC that does My Web, My Way? Yeah. They have a much more elegant approach to that than ours. Participant: I made it. I would say ‘No’; personally, I would say you don’t need to have text resizing buttons on a Web site. Instead, let’s teach people how to do it in the common browsers, and let’s encourage the browsers to continue doing it and do a better job of it, (they’re not all well done), and to implement these features sooner and better. But that’s just one example; we have a lot of other examples. Another example of what web developers are having more responsibility for because there is not enough support in all browsers and assistive technologies, as well as user knowledge, is skip links. Because, right now, in certain assistive technologies and certain screen readers and certain Web sites, that’s not necessary at all. If the site is well designed, a user can jump to headings. If you have, for example, with the WAI site you have a heading for site navigation. It’s not visible, but you can still jump through it. So, if the assistive technologies and the browsers provided the ability to navigate through headings, and Web sites did their headings right and users knew how to do this, then we wouldn’t have to have skip links. So there is a system here; it’s not just the responsibility of one group. We really need to work together so that the system works better for accessibility and, quite frankly, less of the responsibility falls on the millions and millions and millions of Web site developers instead of the few hundreds of authoring tool developers and assistive technology developers and browser/user agents. Yes? Participant 8: I have to say this at this point. I just hope she is here tonight. There is a thread on the RNIB blog by a person called Bim and she writes about Too much accessibility and it’s really fantastic. She writes about how people with good intentions implement things but it actually works against people. So if there's anything you do please go and have a look at this post. Shawn: Yeah, so this is a compliment on Bim’s web blog post on the RNIB site - and she is up here in the front, Bim, you want to wave your hand - on too much accessibility, and going overboard.

There are actually some really funny and some really sad examples. I’ve got a couple in the book as well. Probably the worst one I saw… (well, better not take the time to go into it). There are a bunch, so definitely too much accessibility. And that’s why it’s so important to really understand accessibility issues. You can't just look at the guidelines and Success Criteria and the understanding document and do a really good job. Hopefully, you’ll get the basics. But you really need to have some understanding of how people with disabilities use the Web. Participant 9: The examples that you’ve given are pretty basic. I mean obviously there are things that can be handled from the front end like from the Web developer and the browser perspective. What I was referring to was more of the ARIA where do you, how do you draw the line between, you know, updating the DOM and then having to have the code to update the screen readers buffer to tell that a change be made to, say to people who manufacture assistive technologies, hang on, you know, this is a new technology here and we need to cater for that and your software is falling short of providing Web access. Shawn: (The question was ‘The examples here are very basic.

What about more complex issues, for example with JavaScript, updating the DOM and the ARIA stuff, the Accessible Rich Internet Applications suite (standards that we’re working on), and the fact that not all the assistive technologies do those.) It’s a problem and it’s something (I’m going to keep going with the pace here, so won’t go into details) it’s something we need to keep working on. It is something that is a challenge. We would like to be able to say: this is the Web developer’s responsibility, this is the assistive technology or browser’s responsibility, period. But in fact, a lot of assistive technologies and browsers don’t do all the things that we would like them to do. And people can’t always upgrade. My father, who is 70, also needs large fonts. He’s still working and all he gets from his employer is IE6. He’s not allowed to use anything else on his work machine. So he’s still stuck. (Make it really quick, and then I’ve got to keep going because I’ve got some more.) Participant 10: I already know the answer, but you owe me a quid because you didn't say what DOM stood for. [laughter] Shawn: Aah! You do! You get a quid. Very good. Because I didn’t say DOM is ‘Document Object Model’. Very good.

Alright, let’s go...  (Illustration with labelled graphics of boxes, content, and people. at the top center is a pie chart, an image, a form, and text, labelled 'content'. coming up from the bottom left, a line connects 'developers' through 'authoring tools' and 'evaluation tools' to 'content' at the top. coming up from the bottom right, a line connects 'users' to 'browsers, media players' and 'assistive technologies' to 'content' at the top.) The other thing I want to talk about is, the other side of it is the developers. We talked about content, and people use browsers and assistive technologies to get at content. Well to create content, most people use authoring tools, and sometimes evaluation tools to help evaluate that content. What are some examples of evaluation tools, which you all know? I’m sorry, I asked the wrong question. What are some examples of authoring tools? [Participants answer, which Shawn repeats.] Homesite, Dreamweaver, FrontPage… [indecipherable participant comments] Shawn: We’re not making any comments about vendors at all… Participant: Notepad. Participant: Blogs Shawn: Word, yes! Blogs, right. Blogs are authoring tools. (People are going, ‘hmmm?’) What else? What about photo-sharing sites? What about social networking sites? All of these are authoring tools because people use them to create content. How many of these are accessible? Participant: Very few. Shawn: Very few. Here's another huge one: content management systems. Participants: Oooooo. Hiss. Hmmmm. Shawn: Content management systems are authoring tools. It’s vital that these support accessibility. I think, based on your reaction, most of the people here know a lot about accessibility issues. There are times when your authoring tool hurts you, that it stops you from making things accessible. On the other hand, there are a lot of really good things some authoring tools already do to support accessibility and to make accessibility easier. And we really need to increase the level of authoring tool support for accessibility. We talked about the millions of Web developers, and there are a few thousand, couple of hundred, couple of thousand, of authoring tools. Think if they would make authoring/making accessible content easier, how much better that would be. Whether it’s a complex content management system, or a blog comment, or one of the traditional authoring tools that we mentioned that my father-in-law uses for his farm website, any of those - we really need to increase the accessibility in the authoring tools. I think once we do that, that's the big change.

Once we can get the authoring tools to make accessibility easier, the Web can become a whole lot more accessible. Participant 11: Don't you think that is starting to happen? I for example… [indecipherable] …even as the CMS is accessible. Shawn: (The question is, ‘don’t I think that is starting to happen?’ You named a specific content management system that is doing better.) Absolutely, yeah. They’re getting a whole lot better. There's still a lot more that they could do. We not only want to make it possible, but we want them to encourage accessibility. So, when I put an image, then it automatically stores the alt text with that image, and the next time I put in the image, it brings it up and says, Do you want to use this alt text, or is the image in a different context and do you want to put in different alt text?' And it stores that in the database. So, there is a lot more that they can be doing to help.  (Illustration with labelled graphics of boxes, content, and people. at the top center is a pie chart, an image, a form, and text, labelled 'content'. coming up from the bottom left, a line connects 'developers' through 'authoring tools' and 'evaluation tools' to 'content' at the top. coming up from the bottom right, an arrow connects 'users' to 'browsers, media players' and 'assistive technologies' to 'content' at the top. below these are 'accessibility guidelines' which include 'ATAG' with an arrow pointing to 'authoring tools' and 'evaluation tools', 'WCAG' pointing to 'content', and 'UAAG' pointing to 'browsers, media players' and 'assistive technologies'. at the very bottom, 'technical specifications (HTML, XML, CSS, SVG, SMIL, etc.)' forms a base with an arrow pointing up to the accessibility guidelines.)

How do we know who does what? The W3C WAI has developed guidelines for each of these different components. We’ve talked about the Web Content Accessibility Guidelines. We have User Agent Accessibility Guidelines, and those define what needs to be done by browsers and assistive technologies and media players, (that’s what is meant by ‘user agents’) and other things like that. And then the Authoring Tool Accessibility Guidelines. What I would really like you to do is - this is a call to action. (Can you save your questions to the end because its been long and some people might want to go. So I want to get through a little bit more.) A call to action: I would really encourage you to lend your voice to the call to make the browsers and the authoring tools more accessible. Imagine a product manager for an authoring tool. They have so many feature requests and requests to make changes to the next release of their authoring tool or browser or whatever it is. If there are a couple of lonely voices saying, 'Oh and make it accessible,' that can easily be pushed aside. If instead everyone here sends an e-mail at the very least to your favourite couple of authoring tools and browsers and assistive technologies and says, 'Hey, this is what we want,' then we have this larger voice that’s going to do more in terms of getting more accessibility developed in the authoring tools and user agents, and people’s Web sites. So I just encourage you to really be active about speaking up on how important it is to have accessibility support in these tools.

Where WCAG 2.0 is in the W3C development process

Alright, I’m going to talk briefly about the Guidelines and answer your questions about WCAG 2.0 and where we are with the other Guidelines. We have version 1.0 completed for all those three Guidelines. For WCAG, we've been working on version 2.0 for quite sometime. WCAG is developed within a Working Group and all the drafts and e-mail communications and the minutes from the meetings are all publicly available. So you can see those at any time. Periodically we release Public Working Drafts, which is just an active call for input. There have been several Public Working Drafts of WCAG 2.0. Last year, in 2006, the Working Group said, 'Here, we think we’ve met all the technical requirements, and so this is our Last Call Working Draft.' and there was a real push to get feedback. We asked a lot of people for feedback and we got it, which is great. And so the Working Group has spent the last several months going through about 900 comments and addressing those and integrating the resolution of those comments within the Working Draft. Because there were substantive changes, (that’s the official word, it’s hard to say ‘substantive changes’), the draft went back to Working Draft status. On May 17th, they released of the WCAG 2.0 Working Draft again. If you're at all inclined to look at standards, we’d really, really love for you to look at this and comment. Because the hope is that we’ll get any additional or any new comments now, process those, and be able to release another Last Call Working Draft, and go through the next stages in the W3C process. I won't talk about what all those are. We've got a relatively new document that explains the stages, and you can read that.

Working together in the accessibility community

Alright, with the call to action where I said I’d like you to help with the authoring tool accessibility and user agent accessibility, but I’d also really like you to help with WCAG 2.0. It’s a community effort. What I think that we need to do for accessibility is come together and work together. There is great benefit in having debate and discussion and figuring out within the accessibility community how to make the Guidelines the best and what are the best techniques, and that's very important. I would hope that we can do that within the accessibility community, come together, develop standards and techniques and processes that we are all happy with, and then provide a united front in terms of saying, 'Accessibility is important,' and make sure that Web developers who aren’t actively involved in accessibility get the message that it's important and you can do it, rather than get confused by all the debates. I really encourage you to help with that. We would love to have your comments on the current Working Draft. We are developing techniques, as we go we’re developing techniques, remember we can change that document. There is a form for you to submit techniques, if you want to do that that way, or you can actively participate in the Working Group if you want to do it that way. So, help develop more techniques based on Web technology developing as we learn more and more about it.

Finally, I just want to say, 'Go for it!' Actively encourage accessibility on all levels, be positive about it, reward accessible Web sites and tools and developers. When we’re too critical about how things are being done - if somebody tries to make their site accessible and they mess it up, what we need to do is encourage the effort and help them, be positive in terms of doing more and doing better. So we’d love your help in doing that. And I thank you for taking one step and coming here this evening. Thank you very much! [Applause.] Right, so here’s the deal. It’s a little past 8. If you need to go, you’re welcome to. And, I think if you want to grab a book, they will be available. However, I’m going to stay and answer questions so please feel free to stay and ask questions. Now one thing, I’m going to repeat the questions and I can’t keep them very much in my head so I might need you to do it in stages and I’ll repeat it. Alright, question. Yes? Participant 11: The last slide before this, the last slide said that assistive technologies have user agent streams? You said that assistive technologies have user agent streams that they pass through a Web browser, or am I just being confused? Shawn: Assistive technologies have user agent streams? Participant 11: Yeah, you have… can you go back to the previous slide. Yeah you said something about assistive technologies having user agents streams, that they pass to user agents. Shawn: All I meant with that is that some people use assistive technologies in addition to common browsers or other user agents. Participant 11: Yeah, that’s because I haven’t seen any user agent streams specifically for assistive technologies. So I just got confused by it. [indecipherable comments from participants] Shawn: Oh, okay. That’s what you meant by it. I wasn’t understanding what you meant by user agent streams. Okay. Yeah, so the question was like is your browser aware that there is an assistive technology and then Tom commented that there is a privacy issue with that. So, yeah. Participant 11: Yeah, and I know that they don’t. I just got confused by that slide. I just wanted to make sure. Shawn: Yeah. Tom? Participant #: Education and Outreach, in terms of the producer of Flash-based, especially things that you d [indecipherable] how many tools.. how is that going to have an impact? People at most totally agree to do something quick impacts of being really get around to the principles in that [indecipherable] working group WCAG going to help manufacturers apply some techniques [indecipherable] hardware. Because that would be a massive [indecipherable] But does it happen? Shawn: (Let’s see if I can summarise this okay. The question was about education and outreach around the writing of techniques for other technologies because WCAG 2 is more principles based and might be harder for them to apply.) Well, a couple of things. We’re actively talking to some of the other technology developers. (Loretta Guarino Reid who is chair of the WCAG Working group, used to work for Adobe, you know.) And so the hope is that these technology developers will develop techniques documents. We won’t directly develop those within WAI, but we will definitely support that development. Participant #: Will it be a sanctioned version [indecipherable]? I see the situation where a third party Flash developer [indecipherable] Adobe's? Shawn: (The question is ‘Will it be a sanctioned version?’ You can see a chance for a third party Flash developer who does not like Adobe’s and develops their own’) I don’t see that we will officially sanction versions. I think we’re definitely going to need to look at how we define what is a sufficient technique to meet the success criteria. So we’ll need to look at that at a specific level. I don’t think it will have official sanction. But absolutely, we want to encourage other technologies to develop their own techniques.

Participant 12: I have a couple of questions. The first one is ‘Is there any research on the disabled users that involved evaluating various techniques and guidelines?’ Shawn: (The question was ‘Was there any research with people with disabilities.)’ Absolutely. We didn’t do any directly within the W3C, but the participants in the Working Groups conducted that research. Some of that went into, for example, defining what the contrast ratio would be. That’s a very difficult number to define and there was some research on that and some of the others, yeah. There’s still a need for more research. One of the areas that we need a lot more research is in cognitive disabilities. That’s one of the problems that we have had is that when we want to include issues of people with cognitive disabilities issues, but there's not a lot of research on that. Participant 12: And the second question is are you able to do things with [indecipherable] disabilities and how disabled users use the web. Are there any resources available to tell people how to empathise, because I think from an ordinary [indecipherable] but they are very coded in aspect [indecipherable] because we don’t have access to, example, video showing how people actually do this. So are there any publicly available resources so that people understand and empathise with disabled people? Shawn: (The question was, ‘are there any publicly available resources that help developers understand and empathise with how people with disabilities use the Web?) Yes. Number one, it’s not listed here but WAI has a document called How People with Disabilities Use the Web. There are several different videos, one I personally like, although I’m not officially sanctioning anything, (but partly because the guy who did it is a friend of mine), is from the Trace Research and Development Centre folks and it’s on Introduction to the Screen Reader. There are some other videos. I don’t know if there is a comprehensive list, but there definitely are.

Henny: We're going to be publishing, over the next few months, a series of articles and interviews with users on how they access the web. These will include all types of users and not just users with visual impairments so we'll be talking to people with cognitive problems, mobility problems, hearing problems as well as visual impairments. Shawn: (The comment was RNIB is going to be developing a series of articles that look across different disabilities.) Before I forget, the big thing I want to say is, what I suggest (and this is what the book is about) is, yeah, do all that research, watch videos, read what you can, but really get hands on experience. It may sound daunting, but it’s really not that. It’s fairly easy to find people with disabilities, it’s fairly easy to get someone to sit down and play with your Web site. There is some guidance in there like, things to do first, learn what things work well, have somebody demo a site maybe that’s similar to yours that’s very accessible to them, that they like a lot, and then have them play with your site and help you with that. Participant: I think the main reason why we ask for more publicly available research is it helps us evangelize things so that disabled users don't get missed because it's quite difficult to get some developers enthusiastic [indecipherable] as well as long term business stakeholders, but if we have video showing how [indecipherable] difficult it is for people to even use the Web site and get on with their lives, it would help us get investments to do research. Shawn: (The comment was ‘What’s helpful is to have the public videos to help with evangelizing and get people on board.’)

Yeah, there is nothing more powerful than watching someone with a disability struggle with your Web site and not be able to use it. It might be a little hard to get people in the same room, but have -- We have something called a ‘brown bag lunch’. Do you have that concept, you know, people get together at lunch and there’s some topic? Find some money where you’re going to say ‘Okay, we’re going to buy you lunch. You’re going to come sit in this room, and we’re going to buy you lunch.’ And you have people with disabilities demonstrate: first, have them show a site that they know well and they are really comfortable with and so you first of all get over the misconception that people with disabilities can’t use the Web, which is a misconception a lot of people still have, unfortunately. And then you have them complete tasks on your Web site. And that is incredibly powerful. Participant 13: Getting back to the point about it’s quite easy to find and recruit people with disabilities to test a site. I have found it quite the opposite and my experience in the past three years, not quite recently as I haven't tried recently, but it has been a real challenge. So, I guess I have got a question to the audience if they have found an easier way to recruit people. Shawn: (The question is ‘One gentleman has had some trouble recruiting people with disabilities, and a question to the audience—have you had a different experience?’) Participant 14: We've found that RBNIB and any other advocacy groups are very happy to put you in touch with people. This is good because you are communication with the disabled community through a trusted party rather than just approaching them. Shawn: Yes. Tom said: 'Yeah, if you go through an advocacy group, that it’s fairly easy.'

The other thing that I should have said: the entire book Just ask: Integrating Accessibility Throughout Design is online free. You don’t have to buy a copy. You can buy a copy because it is easier to read, but the entire book is online free. There is a little card here with the Web site address and go and look. It has some guidance on who to contact to recruit people with disabilities, what to say. If you make a couple of calls to an advocacy group, if you are looking for people with a certain profile, for example if you’re looking for seniors, call someone in that group and if you get the right person, you won’t have a problem. It might take a little bit of effort to get the right person but, from my experience, with a little effort, you can get what you need.

Participant #: Going back to that point I think its just hard financially to support that kind of approach sometimes because essentially if you are consulting yourself, working in a consultancy it's hard to recruit those people. So, it can get quite complicated. But, we’ve done it before, and it’s just not so easy. Shawn: Yeah. Here’s an example: We wanted to do some usability testing in a relatively small town. There’s what we call a ‘community college’ (this was in the States), it’s a small college. And we called up and we said, do you have a Disability Students Services group. Yes. We called and we said, 'We want to do some usability testing with people with disabilities. This is the criteria we’re looking for. Do you have anyone?' Answer: Absolutely. 'Oh, and by the way, we are going to pay them… (I think we paid them not much, they were students. [Participants burst into laughter.] I don’t remember if it was…let’s see. I think we did pay them 50 dollars, which is about 25 pounds. So not too bad. It may not have been that, maybe a lot less.) Anyway, I think we had two people arranged the first day and two people arranged for the second day, and we did two studies the first day. The next day we came back and the entire hall was a queue, there were 12 people lined up. Because the other thing is, and this is the key: is getting the right contacts. Once the word gets around, it tends to be a fairly communicative community and people will say, 'Hey, you know, I did usability testing with this group, it was really interesting. They listened to me. They cared about what I said. They want to make their stuff accessible. And you should go help them.' So, I’m not sure how things are organised here, but in the States, we have no problem. Even in the place where I live, we have senior citizen centres, each of the schools and the state and city have rehabilitation departments, we have support groups, for example for people with multiple sclerosis. Those won’t charge a thing. You should pay people, but in terms of finding people, I don’t think, if you make the right contacts, it shouldn't cost you anything. Okay. Yes?

Participant 15: Can I take you back to cognitive disabilities? Where are you with that? There wasn’t very much as in WCAG 1, ambiguous about sign language actually -- here wasn’t any in there either. Is WCAG 2 any better. It seemed like you were on a journey? Where are you on that journey? Shawn: (The question was about cognitive disabilities: 'there wasn't much in WCAG 1, there wasn't much about sign language either; where are we on that journey?') We’re trekking. We’re still trekking on that journey. We’ve done a lot. There’s explicit coverage of issues for people with cognitive disabilities in WCAG 2.0. There was in the previous version and there’s even more now. There is a success criterion for sign language in WCAG 2. It’s AAA, but it’s there. (We’re not going to require all sites to have sign language interpretation of everything to make it Level A or AA.) With the cognitive disabilities, if you follow the dialogue, you may have seen that with the release of the Working Draft in 2006, that was one of a group of comments we got, was on improved coverage of issues for people with cognitive disabilities. We’ve had a series of dialogues specifically with several people about cognitive disabilities. We’ve had special meetings with a broader community on how we can address that. There’s a lot that is already incorporated, especially in the release from May 17.

One of the things that we’ve found, I mentioned earlier, is that there’s not as much research in that area. So a lot of the issues have been included as 'advisory techniques' as opposed to specific requirements. I mentioned there is a document that talks about the changes from the last Working Draft to this version and there’s this section in there that talks about what we’ve done with cognitive disabilities. So I encourage you to read that. Right in front of you, another question? Participant 16: I was just wondering, do you know of any organisation documentation that’s actually gone thoroughly through the business benefits of companies using people to develop accessible websites because it seems talking to them from a freelancer point of view not big corporate, it seems that there’s money to be made for those freelancers and there are their clients who would benefit in a business sense actually implementing accessibility, don’t see a lot of that sort of information on the web. Shawn: Is your question about the business benefits of making your websites accessible or including people with disabilities?

Participant 16: Well, whether there is there any information out there for freelance developers where it is comprehensively put to them the advantages of them getting involved in developing accessible websites. Shawn: Okay. A couple of things and then I’ll ask you all for some additional answers. One, WAI does have a resource called Developing a Business Case for Web Accessibility. [Participant query.] We do. The W3C Web Accessibility Initiative has one. I don’t remember the exact title, I think it’s Developing a Customised Business Case for Your Organisation. And the theory behind it is that we wanted to provide a resource that would work in a bunch of different cases. Obviously, a business case for university is different from a business case for a grocery store, which is different from a business case for a bank. And so this is designed like a cafeteria or buffet, where there is all this different information and then you can pick from it what applies for your specific organisation. Participant 16: Pick and mix. Shawn: Pick and mix. There is a section on the social benefits, the financial benefits, technical benefits, and legal and policy benefits -- on the advantageous of accessibility beyond just it's the right thing to do. The other thing is, I think where there is an opportunity for us to do more as a community is to share some specific examples. I hear of examples. There’s a bank in, I think, the Netherlands that decided to make their site accessible. Did it and they focused only on accessibility, and within a week of after they released a new site, they shot up to the very top of search engine rankings. I said, ‘Please write that down!' I hear a lot of stories of really good business cases. We’ve got some documentation, what we need is community that shares some of these statistics that will help if you’re a freelancer and you want to say, 'Hey I want to incorporate accessibility, it might take me a little bit more time or money.' This is something we should do. A comment, there?

Participant 17: Ya, in the UK too, I know it to Tesco’s online supermarket. We’ve got… Legal and General say, I know people know about PAS 78. So, when we launched PAS, we had a couple of talks from all of the guys who did that. So if you look back hopefully somewhere in the wonderful archive the Web is, if you look through the presentations that were given when PAS was launched there’s a lot of this stuff in there. Shawn: Okay, so he shared a couple of others. One is Tesco's, and the other is Legal and General, that one as well, and then along with the PAS 78 release, you said that there were some other case studies? Mike Davies: I just want to say that I did a Legal and General case study in Stewarts Web Standards Group meet up in February and we saw a 230 percent improvement on customers actually buying the product online. [indecipherable] Shawn: So Mike was saying that he did a presentation recently talking about the improvements of the Legal and General and there was a 230 percent increase in the… Mike: …Number of people who actually completed the purchase online. Shawn: Number of people who completed the purchase online for home insurance. After redesigned for accessibility. Mike: Yeah. After …[indecipherable]… before. Participant 18: Sorry to interrupt, but were they pure accessibility changes or were they usability changes as well? Mike For home insurance they were accessibility changes. …[indecipherable]

Participant 18: Yeah, you know just because I’ll tell you, when I hear some of these examples and I like to use it myself but [indecipherable] I do believe sometimes they do require a leap of faith because actually there was a whole site redesign and accessibility was just part of and it improved site performance and usability is also looked at and I have a problem with people saying that making a site more accessible makes it more usable as that's quite subjective. Shawn: (We’re recording so I’m summarizing. There’s some question about: most of the time when people redesign their sites for accessibility, they also improve the usability.) In most cases you’re not able to say in black and white, clearly this change resulted in that improvement. When we have enough anecdotal evidence and we have enough studies that show the benefit of all these improvements – that’s what we need. Participant 19: This is simple I use it as basic quality control [indecipherable] I have been in this situation where a friend was trying to fill out application and that they said that it was not accessible [indecipherable] And the thing is you knew it was a bad website, but you needed something to measure against tell you the answer and it was really useful. And ultimately it was in the contract. Shawn: (This was a comment that it WCAG was very useful, within a contract, so you were able to use the Guidelines to be able to say that ‘No, this isn’t accessible.’ And having that as a benchmarker helped you out.) Okay.

Participant 19: [indecipherable] deploying web applications to the suppliers we have people saying that Oh, this is accessible and we say great! And then they want Section 508 and we're following WCAG version 1. What’s happening in this direction? Shawn: (Good question! Okay, she said that they’re buying pre-packaged web applications mostly from America, they say its accessible, you get it over, you test it, its not. They say it’s meeting Section 508 but it doesn’t meet WCAG 1.) Yeah, indeed, Section 508 is a subset of WCAG, so it doesn’t cover all of the issues. (It doesn’t cover text resizing, for example.) One of the main goals of WCAG 2.0 is to define standards that can be adopted worldwide. So throughout the last couple of years, we’ve been actively working with the Access Board, which is the group that defines the 508 standards, saying, 'tell us what you need, tell us what works, let’s work together so that when 508 is reopened, hopefully we can come together.' Well, 508 is now reopened. I don’t know if you guys have heard that news? (By the way, where I come from 'guys' is a gender-neutral term. Sorry, it's an expression. [With strong Texas accent:] However, where I used to come from I would say 'y’all', ‘cause I was raised in Texas.) [Laughter] Anyway, 508 is now open and WAI is on the committee to define the information that advises what the next version of 508 will be. So it is most definitely a problem. It’s definitely a problem when there are different standards all over the world, and one of the biggest problems is 508 differing from WCAG 1, and we’re hoping that WCAG 2 will help solve that. And the U.S. Access Board is helping. And I’m serious about this: Help make it clear, not only with 508 but around the world - there are countries and there are organisations for various reasons that are developing their own Web standards - and we need to say, 'You know what? It works better if we can have a single set of standards that work internationally so that whether you are purchasing products developed in other countries, or whether you are developing products that will be sold around the world, that we have a single set of standards that they can work on.’ Participant 20: [indecipherable] Are there standards on software interfaces as well as Internet? What's happening there and is there any connection between the two standards. Shawn: (The question was the ISO and other standards, and the connection between those.) Again, we are actively working in those committees. I’m not up to date on what the latest is, but I know that people within WAI are actively working on those. If you want to send me an e-mail, I can get you the right person to give you a better answer on that. Yeah, we do a lot of work, spend a lot of the time, working with various standards organizations around the world. Yes?

Participant 21: How long do you think we have to wait until WCAG 2.0 is actually released? Shawn: (How long do we have to wait until WCAG is actually released?) You know, it depends. [Shawn laughs.] Participant 21: Will it be months? Years?  Public working draft  Last call working draft  Candidate recommendation  Proposed recommendation  W3C Recommendation and Web Standard Shawn: (Are we talking months? Years?) Each of these steps has a required time period and given the minimum required period, I don’t think we could get it done this year. However, with each draft, it becomes more stable. And so I really hope that with this - the last Working Draft we got a lot of comments, and the Working Group spent a lot of time because there were 900 comments and each comment was addressed and the disposition recorded, for every single comment. (That’s a requirement for Last Call, they have to formally address each one.) I am hoping that with this next Public Working Drafts that is out now, that if we get any new comments, the Working Group will be able to address those quickly and proceed fairly quickly through the next stages. Last Call Working Draft, the same thing. We need to have a fair enough long review period. What the Working Group wants to do is: 'Ok we're done. Everyone review it next week and get back to us so we can go to the next stage.' You think you want it done! [Laughter] Yeah! The amount of time that people have invested in this is huge. Then the Candidate Recommendation, the purpose of that is to gather implementations because we need to prove that the standard can be implemented, that it will work. So we’re already encouraging people to go ahead and start working with it and start using it so we can get that feedback. And then Proposed Recommendation. One of those has a minimum timeline as well. How long it is going to take? It depends on how many comments we get. I promise you the Working Group is working very hard on it. They want it done more than you do. But we need it to be done well. And so we’re taking the time to get input and make sure that it’s done well. Now the other thing is, depending on where you are, there are some organisations that are already using WCAG 2. WCAG 2 is designed to be backwards compatible. So you can make a site meet both WCAG 1 and 2. So there is no reason not to start using it. You need to be aware that it could change. But you can start developing for WCAG 2 now. And then when it comes out, you’re ahead of the game. And you can still meet WCAG 1 while you need to do that, and also work on WCAG 2. But you can also be lazy and hopefully you don’t have to do much. [Shawn and few participants laugh.] (That was a reference to an earlier question, by the way, I’m not calling anyone lazy.) And hopefully there’s not much that you do need to do. So, as long as you’re aware that it’s changing, you don’t need to wait.

Participant 22: But you can’t actually have that reinforced in a legal contract? Shawn: (You can’t have it reinforced in a legal contract because it moves.) There are some organisations that have written into their contracts that the Web site needs to meet WCAG 1 now, and once WCAG 2 is available, then it needs to meet WCAG 2, within a certain time period. Again, number one, the fundamental principles of Web accessibility are the same. Number two, there’s really not that much difference. Number three, if anything it gives you more flexibility. I don’t know whether you are the contractor or the contractee here. If you’re writing a contract, absolutely say it needs to meet WCAG 2 within a reasonable period after it’s complete. If you are a contractee, go ahead and start working on WCAG 2 now; its going to put you at an advantage compared to your competitors that you can say ‘Yeah. I’ve been working with WCAG 2 already.’ Alright, last one. Getting tired? Participant 23: [indecipherable] Shawn: (Okay, pause a second because I have to repeat them all. The first question is: ‘how is WAI involved with different communities, one is governments and administration.’) One of the things I do want to clarify is that we are a standards-making body and we’re not a policy-defining body. So we’re not involved in policy, but where we can contribute to standards being developed, we do. We encourage a single set of shared standards to the benefit of accessibility overall. We cannot stop the government….

Participant: Do you have relationships with people from different administrations? Shawn: We do. Yeah. We have relationships but we don’t have… [Participant: authority] yeah, authority. All it is like consultative, ability to communicate what we suggest. (And then the second question was about the designer community. There are some that are very aware of accessibility and many that aren’t.) Tell me a little bit more about what you are thinking? Participant: I’m thinking just, well, yeah, from a business point of view. We are web developers. Sometimes you get a design that looks beautiful. Sometimes you get a design which you just can’t make it happen and make it accessible at the same time. And it feels like there’s a need for education. Yeah [indecipherable] Shawn: Right, right. How many people would say you’re more of a designer versus more of a developer? If you are more of a designer, raise your hand. If you’re more of a developer, raise your hand. Okay, so definitely more developers here. So, the question and comment was that sometimes as a developer, you get designs that are very difficult to make inaccessible. Participant: It’s just that accessibility is not only part of implementation but it’s a part of design and style. Shawn: Yeah, yeah. We’re definitely working on more of that. I’m on the road for six weeks (this is in the middle, and I'm going to be home for seven days). And part of that is talking to design conferences. (I don’t know, would call @Media a design or development conference? [Participants: Both] Both yeah.) So I’ve definitely been doing more, we’ve been doing more education and outreach with the design community. I think there are a whole lot of opportunities to do more. That’s something I’ve been preaching about for years (because obviously text resizing is a huge part of that) to try to change the idea for designers that with the Web, the important thing is that people can get the information. It’s not important that it look exactly the same for every user.

There is an article, I think by John Allsopp, a few years ago called The Dao of Web Design. It’s really really cool. I haven’t read it in years but I remember I loved it a long time ago and someone mentioned it at @Media in America last week. Yeah, we definitely need to do more outreach to the design community. Participant: But, how did you last. I don’t actually think that you if you could take an example of a simple CSS as some standard, [indecipherable] its very hard for you to … the site. Right now, it sounds rude, but I think people pushing CSS at some point will ask for CSS that lasts for years. Yes, I have also used CSS on my style. Perhaps that is what accessibility is turning out to a group of people pushing it to designers to be more [indecipherable] I think. Shawn: (He was just saying that what is needed is maybe something like CSS where there was a group of people really pushing it to designers.) Absolutely. Probably one of the huge things that turned CSS around is CSS Zen Garden. Right? What I’d like to do, (and I talked to David Shea and he said 'Yeah, you can do it.' we just don’t have the time, ), is to take all the CSS Zen Garden designs and show the ones that are accessible. Because they're not all, actually a lot of them aren't. Some of them are. Yeah, so what I think we need to do for designers particularly; number one is to say ‘Hey, accessibility is important’, some of the evangelizing, get to them and say, ‘this is why it is important, this is what a screen reader is… When I increase your text size and when my dad goes to increase the text size, I don’t care how it looks. I care that I can read it. And yeah you can make beautiful designs, optimised for certain sites but you need to make it flexible for anybody.’ And then the other thing is to have more examples of beautifully designed sites that are accessible. That’s one of the things I think we’re missing. We need to have more of those to get to the design community. Participant 23: I would like to say is most designers find like gadgets which show accessibility needs and can show how to scale things and the affects they have [indecipherable] These technologies also show designers how to solve accessibility problems. Shawn: (Some ideas on getting designers on board. That’s certainly a challenge.) Alright, you’re probably tired. [participants laugh] Again, thank you for coming. I’ll stay afterwards if you want to talk some more. Make the Web accessible! [Clapping]