Published: December 2008
Gerry Gaffney:
This is Gerry Gaffney with the user experience podcast. My guest today promotes web accessibility at the World Wide Web Consortium’s Web Accessibility Initiative.
She also holds a research appointment at the Massachusetts Institute of Technology (MIT) Computer Science and Artificial Intelligence Laboratory (CSAIL).
She is also the author of “Just Ask: Integrating Accessibility Throughout Design”, and that book incidentally is available for free online as well as being purchasable from the usual outlets.
Shawn Henry, welcome to the User Experience Podcast.
Shawn Henry:
Thank you so much for having me. I appreciate this opportunity.
Gerry:
Shawn, can you start by telling me how it is that you came to be involved in the field of accessibility in the first place?.
Shawn:
I was a user interface designer, doing a lot of user interface design for software, primarily developing graphical user interface guidelines and teaching user-centred design process, when I began to have problems myself both visual and physical.
It got pretty bad for a while. I thought I was going to have to quit work. And that’s when I learned about accessibility, about accessibility of hardware and software and, later, web.
So at first, it was purely self-interest, quite frankly.
But then, once I learned about how empowering accessible technology can be for people with disabilities, I really became quite passionate about it. And so even when I started getting better I’ve stayed focused on accessibility and really can’t imagine doing anything different.
Gerry:
It’s funny isn’t it because I guess the web as a medium and the online area in general has been empowering for people in general and for people with accessibility and disability issues, but there’s so much more that can be done in that regard.
Shawn:
Absolutely. We’ve got a good start, we’ve come a long way but there’s so much more needs to be done. And the primary issue is awareness. That’s really the major issue. There are other more complicated aspects to it but the number one thing is people just aren’t aware. It’s not taught in courses, and they don’t understand. If you don’t have a disability and don’t know people who do, you’re just not aware of what you need to do to design for accessibility.
Gerry:
You did a couple of great presentations at the first UPA Europe conference in Turin in December 08, and at that time there was quite a lot of buzz about the fact that Version 2 of the Web Content Accessibility Guidelines (WCAG) was finally approaching. There was a lot of excitement about that and they have, in fact, just very recently as we talk been released.
Not to put too fine a point on it, why has it taken so long? Because I think it’s about 8 years since version 1 came out.
Shawn:
It has taken quite a while to develop the Web Content Accessibility Guidelines 2.0, and there’s a good reason for that. Basically, it’s designed through a process – through the World Wide Web Consortium (W3C) process that’s designed to ensure broad community input and also to encourage consensus development.
Basically how it works is there’s an international working group with representatives with a broad range of perspectives. That group works on the core work and then periodically they would publish working drafts. And with those we presented and encouraged broad public review and comment. So over the last few years we’ve gotten thousands of comments from around the world, for disability organisations, from web developers and designers, from IC policy makers and others. All this has gone into the development of the Web Content Accessibility Guidelines 2.0, and obviously this process takes time to bring together these broad perspectives, this range of perspectives, and to develop consensus, to make sure that we’ve gotten this international input.
But it’s really worth it, because now in the end we have this result that we can all buy into.
Gerry:
That leads me into my next question. One of the issues with Version 1 I know was that there was a certain – I think vagueness is possibly too strong a word – but there was a certain lack of specific advice to web developers in terms of exactly what they would do. I believe from your presentations – and I have to confess I’m not familiar with Version 2 of the guidelines at this point – but I believe that that’s been largely addressed in Version 2.
Is that the case and can you tell me a little bit about that?
Shawn:
Absolutely. That was one of three key goals – and requirements, actually, for developing 2.0.
One of the goals was to make Version 2.0 more broadly applicable to different technologies – more advanced technologies today as well as to be applicable as technologies change.
Gerry:
So are we talking about mobile devices and the like there?
Shawn:
That’s included. And also Ajax and non-W3C technologies as well – things like Flash, etc.
So that was one of the goals. Another one was to make the guidelines easier to use and understand and to provide additional supporting material.
The third one is exactly what you mentioned – to provide clearer criteria.
An example of that is in Version 1 the checkpoint that that talked about colour contrast said “Ensure that foreground and background colour combinations provide sufficient contrast when viewed by someone having colour deficits.”
That’s really vague as you said [laughs]. And it’s hard to determine what meets that checkpoint or not. So the equivalent in Version 2.0 says “The visual presentation of text and images has a contrast ratio of at least 4.5 to 1.”
So it’s very specific and there are tools available where you just put in your colour and it’ll tell you “Yes it passes” or not.
Gerry:
Does that apply across the board to the guidelines? Are they all that clearly defined and that clearly measurable?
Shawn:
The goal was that they would be as clearly measureable as possible. And that was a significant issue in defining the guidelines and what we call success criteria for the guidelines.
Now that one has a specific tool you can run. Run the tool, it clearly says yes or no.
There are some things that a tool won’t be able to clearly give you a yes or no. So there is some element of human evaluation that’s needed to be able to say whether a website meets the guidelines.
But they have been designed so that it is much more clear and if you have two experts evaluating the same thing they should be able to come to the same conclusion.
Gerry:
I’m talking to you only a few days – a couple of days actually – after the release of Version 2, so it might be a little bit early for me to be asking this question. Do you have any idea about the sort of reaction you’re getting from the web development community to the new version?
Shawn:
For the most part, it’s been excellent. Many people have been involved in the process, and a couple of years ago there were some pretty, ah, heated critiques. And some of those were justified. A few of the comments were right on. The guidelines were too technical back than and etc, etc.
Some people were very critical and what’s been exciting is to see even those people who were critical of some of the early drafts come out now publicly and say “hey, this is much better, it’s good, let’s get behind it.”
It’s been really neat to see the support that we’ve had, and that the blogosphere is abuzz and we are tracking that of course to see what feedback we’re getting, and it’s been largely quite positive.
Another exciting aspect with WCAG 2… As I mentioned we’ve worked really hard and very actively to get international cooperation and participation. One of the things that we’re seeing with WCAG 2 is the plans for translation. We already have several organisations who have committed to making authorised translations of the Web Content Accessibility Guidelines 2.0 and that’s very exciting.
Gerry:
Shawn, a perennial problem in design in general and in web design is that companies and organisations just don’t want to expend extra effort and money “just” to make things accessible. How do you react to that?
Shawn:
A couple of ways. My first reaction is if people really understood the impact of accessibility on individuals and on their organisation and on society and maybe even on themselves some day, then they wouldn’t need convincing. They’d just do it.
But that’s not the case so let’s look at it a different way. With web accessibility, almost everything that you do for accessibility to make your websites more usable to people with disabilities had additional benefits that help all users and/or the website owners themselves.
For example, there’s significant overlap between what you do for accessibility and what you do for mobile web design. There’s significant overlap between what you do for search engine optimisation and for what you do with accessibility.
There are significant benefits for what you do for accessibility. And we have a resource that talks about that. It’s “Developing a Business Case for Your Organization“, and it outlines and describes the technical factors, the financial factors, the social factors, and the legal and policy factors in the business case for accessibility. It talks about looking at the return on investment.
If you really understand the business case and those additional benefits then web accessibility is a comparatively easy sell within most organisations.
Another aspect of that is the issue with getting accessibility integrated early on in the development process. When accessibility comes in at the end then it does cost more and it is seen as more of a burden – it really is more of a burden. But if instead accessibility can be integrated from the very beginning of a project, then it can have very little negative impact in terms of cost or time. And then you can just realise all the positive impacts in terms of better design and better products.
Gerry:
And this is the “curb-cut” analogy. I was talking to my brother and he’s talking about… they’re spending a lot of money in north Dublin at the moment retro-fitting the curbs so that they’re suitable for wheelchairs and prams and wheels in general.
Shawn:
And if you sit and look at those, look at how many people without disabilities use them. They’re incredibly useful for all types of situations and that’s a perfect analogy.
Gerry:
You made an almost throw-away comment, I think not an entirely serious remark at UPA Europe that people should only use people with disabilities when doing usability testing. I hope I’m not misquoting you there. Why did you say this?
Shawn:
Here’s the thing. If you make a product, be it a website or anything, that works well for all people with disabilities including people with mild cognitive impairments, people who are born deaf and English or whatever language… is not their primary language, people who are older and have dexterity issues, lack of fine motor control etc… If you make your product work for all people with disabilities then it will work better for everybody, for people without disabilities.
And when you do usability testing, people with disabilities will find the same usability issues as people without disabilities. They may find additional ones as well. But often they’ll find the same ones and they’ll be magnified, they’ll be amplified. It’ll be even more apparent what these general usability issues are. They’ll come out more clearly when you’re using people with disabilities for your testing.
So I have this theory, and I’ve not proved it yet which is why I kind of mumbled it or whatever when we talked…
Gerry:
Some people were listening.
[Laughter]
Shawn:
I have this theory, unproved theory that if you were to do usability testing with a few carefully chosen people with disabilities, so you get a range of disabilities, that you would get better results than if you did the same test with the same number of people without disabilities.
There are so many reasons to use people with disabilities that, yeah, I’m joking that it’s a waste to ever bother using people without disabilities.
Gerry:
At the UPA Europe conference it was quite notable… I was sitting next to Malcolm Jarrett and when your first slide came up on screen, or your second slide, Malcolm turned to me and said “It’s easy to see that she’s the accessibility person”, because your presentation materials were extremely clear and legible. Is this something that you pay a lot of attention to?
Shawn:
Well there are two answers to that. The first one is because I sometimes have low vision and I naturally make things pretty legible. But what’s more interesting is that the broader answer to that, and that consideration of accessibility issues such as describing key images in a presentation and things like that.
Twelve years ago or so I was not aware of accessibility issues and probably didn’t do a good job of all these things, but since then I’ve learned about making my work accessible, whether it’s product user interfaces or presentations or whatever, and now, it’s become second nature, so to speak. I automatically do it without thinking and really without much additional work. Pretty much what I do is fully accessible.
And that’s where we really need to get with accessibility. You know, when I was talking about integrating it in the process and doing it early on and the business case… The issue with accessibility is it does take time to learn it initially, and it takes time to integrate it into the way we work because unfortunately it’s not in most training and processes. But once you do, once you learn the basics and it’s integrated into the process and the way you think, then most of it doesn’t take any additional time and effort. It just is the way you do things.
Gerry:
I notice that, for example, you read the URLs. A lot of presenters, most presenters – myself included – would say things like “And there’s the URL” as a throwaway, and if somebody actually reads it out people in the audience who actually need to write it down for example have the opportunity to do so. I guess those sorts of things, once you start doing them, just become the norm.
Shawn:
They become the norm, and I have to say it’s really hard for me when people don’t do that. I went to a presentation actually at a UPA conference. It wasn’t this one but a previous one; I won’t say what but they were talking about… They did a presentation on making their website accessible for people with low vision. And I was in the audience and they were doing all sorts of things that were difficult to read. You know, the font was too small and they had a chart with a bunch of stuff… And then the brought up a list of findings or something and they said “Oh, we’ll just be quiet and let you read that.”
Ugh! Challenging! [Laughs]
The other thing is, once you’ve experienced it… you know, go around north Dublin in a wheelchair, sit in a presentation without your glasses, and you get awareness pretty quick.
Gerry:
Shawn, now that Version 2 of the accessibility guidelines has come out, what should developers do? Should they be rushing out there and reading the entire thing, or what’s the process?
Shawn:
They should be rushing out there if they haven’t yet, and definitely reading it. We’ve got a lot of support materials along with WCAG 2 that we didn’t have with 1.0, that makes it a lot easier to get started. So we have an overview page, and everyone should start with the overview page. That will step you through the different layers of guidance. One of the things that’s particularly useful for developers, that we didn’t have before, is called “How to meet WCAG 2.0: a Customizable Quick Reference”. This is a neat tool that allows you to essentially create whatever level of checklist that you want.
So you can select what technologies you’re using, you know, whether you’re using multimedia, whether you’re using scripting, etc. You can select what level of accessibility you’re trying to go for. You can select what detail of support material you want linked, and then create your own tool to help you work through WCAG and the requirements and the techniques and all the guidance.
That’s really the main tool for developers, and one of the tips I hope you’ll pick up quickly when you start with the overview page is that the WCAG material is designed so that you can… There’s a whole bunch of information, and it’s not really designed so that you read it from start to finish, but instead that you can drill down and find the detailed information as you need it.
The other thing I would say is to let us know if you have questions or suggestions. The Web Content Accessibility Guidelines 2.0 themselves are a stable standard. So the guidelines themselves will not change. However, the supporting information, like the guide to understanding and implementing WCAG and the techniques for WCAG; those documents are ones that we can update and plan to update periodically with additional best practices, and as technologies evolve, etc.
So we welcome comments and suggestions for additional information making it more clear.
Gerry:
And, ah, when is Version 3 coming out?
Shawn:
[Laughs]
Well, probably not nine years from now. We designed 2.0, as I mentioned, so that it would be more applicable as technology changes. So the guidelines themselves are, as I say, broader, and then that specific information, the specific details are included in those supporting documents which we plan to update.
I don’t know if there will be a Web Content Accessibility Guidelines 3.0; we may have something different. You may be aware right now from the Web Accessibility Initiative, in addition to the Web Content Accessibility Guidelines, we have the Authoring Tool Accessibility Guidelines, and we have guidelines for browsers and other user agents.
So we have separate guidelines for those right now, and, you know, these are all merging. Where at one time we thought of authoring tools as separate software, now you have things like blogs and wikis and social networking sites and photo sharing sites and all these that are both websites that people use and tools that you use to create content for the web.
So, we’ll see what happens in the future. For now, we’re very excited that WCAG 2.0 is completed and we’re working on the support materials for those, and continuing to work on Version 2.0 of the other guidelines like the authoring tool accessibility guidelines, the user agent accessibility guidelines and WAI-ARIA, which defines how to make accessible rich internet applications.
Gerry:
Of course, people can find all of this stuff by just typing WCAG 2 in their favourite search engine. We will include links to all the materials you’ve mentioned at www.uxpod.com, as well as a link to your book “Just Ask: Integrating Accessibility Throughout Design”, which as I said earlier is available for free as well as as a regular purchase.
Shawn Henry, thank you so much for joining me today on the User Experience Podcast.
Shawn:
Thanks so much Gerry. Again, I really appreciate the opportunity to spread the word about accessibility.
Published: December 2008