If you are accessing this page using a screen reader and encounter problems please disable Javascript. If you continue to have problems please email enquiries@headscape.co.uk. Thank you.

Headscape

Creating attractive, usable websites

Download this presentation as a 796x600 quicktime movie (79mb).

Read the transcript of this video.

Paul Boag: Hello my name is Paul Boag, and I'm one of the founding members of Headscape. What you're watching is a presentation on web accessibility and it's a presentation that I've given a number of times at various conferences and workshops, and I thought it was worth sharing here online as well. Now I'm going to try and do it as best I can, just like a live presentation. So I am going to record it all through in one go, so if there are a few um's and ah's along the way then please forgive me.

The reason that I want to share that information online is 1) hopefully it'll challenge you and excite you about the subject of web accessibility, but 2) hopefully it'll provide a little bit of insight into how we at Headscape approach the subject and why we're so passionate about it. But I think the first thing to say, before we kick off, is that this is very much an introduction into the subject of web accessibility.

Web accessibility is an enormous subject and if you come into it new, it can be very intimidating. So this presentation, hopefully, will give you an introduction into how to get started. But if you're somebody that already has experience in web accessibility please continue to watch because I hope, as well, it's going to challenge you to think about web accessibility differently. So, hopefully there is something for you in the presentation as well.

So let's kick off. What is the fundamental emotion that goes through your mind when you think of the subject of web accessibility? What does it make you think? Well, I bet that right up near the top of your list is a certain degree of fear. I think web accessibility generates fear in a lot of people. There's a lot of scare mongering going on about web accessibility. Chances are, at some point you've received an email from somebody going, "Your site breaks the Disability Discrimination Act and is not accessible to people with disabilities. You are in violation of law. You're going to be in trouble." And normally this comes from a web design company that then offers you the solution of how to solve the problem.

So there's a lot of fear that surrounds the subject. But, just after fear, I think equally alongside that, sits a great deal of confusion. What is this thing, web accessibility? What's expected of me? What am I required to do? What's going on here? And I think those feelings of fear and confusion, actually, are not at all surprising, because the world of web accessibility is in a bit of a mess at the moment. And it's in a mess because of two reasons.

The first of those reasons is very unclear legislation. The legislation that exists about accessibility is vague. Vague is probably the best description. It is very vague. In the U.K. this is particularly true. Probably the main piece of legislation that exists when it comes to web accessibility is the Disability Discrimination Act. I mentioned it a minute ago. It's used as this kind of big tool to criticize companies for not making their site accessible, but actually, it doesn't reference web accessibility at all. It does talk about the need to make services accessible, but doesn't specifically mention the web.

Now there is supporting documentation that goes alongside the Disability Discrimination Act that does reference the web. But only in a single case study that refers to a ticketing company that sells airline tickets, and how they need to make that service accessible if they want to conform to the Disability Discrimination Act. So, the basic rule in the Disability Discrimination Act is that you need to make your service accessible. But what constitutes the service, and what constitutes making it accessible? What does that mean in reality?

Take for example the service aspect of that. I've just said that it does apply to a ticketing company. Does that mean, therefore, that it applies to all e-commerce sites? Does it apply to anybody providing any content online? Is that a service, by providing that content online? And how, exactly, are you meant to make this accessible anyway?

Now there is other legislation that exists as well, depending on the sector you work in, or the geographical location you work in. So, for example, there is legislation that exists specifically for the higher education sector that we work in quite a lot at Headscape. There are also things like the Disability Equality Act and there's various European legislation. But there are no test cases for any of this stuff, and it's test cases that help to clarify what the law actually means.

Now, two cases have been taken to court, but both of them were eventually settled out of the court, and so haven't helped to clarify the situation. So we are left with very unclear legislation that leaves everyone feeling very confused.

Add to that our second problem. Our second problem is, basically, never-ending guidelines. There are so many guidelines when it comes to the web. It's like everybody seems to have an opinion on the subject and have released some guidelines. Let me just give you a little indication of some of the stuff that's out there.

Probably the most well known is WCAG 1.0. Now, you may have heard of an organization called the W3C--the World Wide Web Consortium. They're like the governing body of the Internet, for want of a better word. They're made up of individuals and organizations that are basically sculpting the underlying language and programming that exists within the web. They're the people that create HTML. They're the people that create CSS. They're the people that create the building blocks of the web.

They comment on all kinds of things and provide guidelines for all kind of things, and one of those things is web accessibility. Back in the 1990s they produced something called WCAG 1.0--Web Content Accessibility Guidelines. Those guidelines have existed ever since but, as you can imagine, in the fast world of the Internet, they're beginning to look a little bit dated and a little bit rusty around the edges. But they are the definitive standard that currently exists.

Now, in Britain the disability rights commission recognized that there was a need to clarify what was going on. So they undertook producing something called PAS78. PAS78 had so much potential because it was designed to be aimed at people like you, people that run websites but aren't necessarily experts in the subject of web accessibility. The idea of that was that they would clarify the situation and they would help guide people in the right direction.

Unfortunately, when PAS78 actually came out, it primarily recommended you follow WCAG 1.0, but then recommended a whole load of additional stuff on top of WCAG 1.0, really complicating the situation even further. So, PAS78 almost caused more confusion, in my opinion, than it provided benefit. I know other people disagree with me, but that would be my take on it.

Now, another name or set of guidelines you may have heard knocking around is Section 508. There is a kind of general belief that everybody needs to conform to Section 508. Actually, Section 508 is American legislation and I'm not going to get into that here because, as I said, this presentation is primarily for an English audience. If you're English you can ignore Section 508, but nevertheless it causes confusion, and you wonder what it is and how it applies to you.

But then, in addition to that, you have various lobbying groups out there. RNIB is a classic example of that. They're doing great work in the world of web accessibility. They're raising the profile of the need to make your site accessible, and they're prosecuting the high profile organizations that aren't making efforts in the arena of accessibility. They've also offered something called the "See It Right" accreditation scheme. The idea of See It Right is that you can get accredited and you can kind of check the box and say "OK. I've done with accessibility".

The problem with See It Right is that it's created by the RNIB, and they're primarily concerned with blind people. So the accreditation system doesn't take into account all the various other types of disability that are out there. So really that's not a whole lot of use.

The W3C are making efforts to improve WCAG 1.0 and are working on WCAG 2.0 at the moment, but that's still in draft. So, there's a lot of debate about whether it's doing the right thing and all the rest of it. So, there's more confusion, now. What's WCAG 2.0? How is that going to change it? It's certainly radically different from WCAG 1.0. So, more uncertainty creeps in there, more confusion creeps in there.

Just to finish things off, there's also a group of people that really felt that the W3C had lost their way when it came to accessibility. So they set up their own group called the WCAG Samurai. These are leading figures in the word of accessibility, and they're going ahead and creating their own set of guidelines based on WCAG 1.0, but with extras and some stuff removed.

So all in all, it's an incredibly confusing scenario with so many different and conflicting things. So, it's understandable that many of us, when it comes to accessibility, are asking where do we turn? Has accessibility reached a dead end? Are we now stuck?

Now, I'm a kind of positive guy, and I like to turn negatives into positive. I actually think that the current situation, although very difficult, is a positive, and I would encourage you to think of it as a positive because what this mess does away with is the covering-your-backside mentality.

Oftentimes web accessibility is about is arse covering. None of us want to get sued. We all want to tick the box that says, "Yes, we've done our best with accessibility". They all want an absolute where they can say "Yes, we've done accessibility, let's move on to the next thing".

But in reality web accessibility isn't that black and white. It's a lot more than check boxes. And if you are somebody that feels like they have got a grasp on accessibility because they fulfill the WCAG guidelines, for example, I would encourage you to think beyond that.

I would actually challenge you and say you probably haven't got as good a handle on accessibility as you think you have. Fortunately, the law doesn't provide that kind of black and white answer, and so it does encourage you to think more in depth about accessibility. I don't think it's enough just to check the boxes anymore. There's more expected of you.

So, if we're saying that it's not enough just to conform to WCAG or it's not enough just to do the See It Right accreditation or whatever else, then what should you be doing? How should you be approaching the subject of web accessibility? What I want to share with you now is how we at Headscape approach it. What's our approach? How do we go about it?

First off, we believe very strongly that accessibility is about more than just blind people. A lot of people, when they think about web accessibility are thinking about people that are blind that are using screen readers. But actually, there are lot of people that have vision impairments which don't classify them as blind but are still severe: people that have tunnel vision and people that have all kinds of different conditions. But it's more than even them; it's more than just blind people.

There are lot of other disabilities out there. There are people with cognitive disabilities, learning disabilities, with motor skill disabilities--all kinds of disabilities. Even the deaf, you need to really take into account. How is a deaf person going to hear this presentation, for example? In an ideal world we would provide a complete transcript of this presentation. I don't know whether that's going to be within our reach, certainly when this initially goes live, but that would be the aim that we would work towards.

So, there are all kinds of accessibility issues that are way beyond just the blind. But I would argue that it's even more than just people registered as disabled. There are a lot of people that aren't registered as disabled but have accessibility issues. The elderly are a good example of that. As you get older, your vision begins to fail, and you may get arthritis that makes using a mouse difficult, and so on.

But lets go even beyond that kind of physical and cognitive disability, and get into the realms of something entirely different. I would argue that accessibility is for absolutely everybody. What do I really mean by that when I say that?

Well, take for example, people using old technology. Not everybody has got the latest browser. Not everybody has even got the understanding to be able to install the latest browser. Not everybody has got a broadband connection. Not everybody has got the most up-to-date computers. You need to make sure that your site is accessible to this audience as well.

Just to give you a little bit of context, the people in the UK registered as disabled have an estimated spending power of 53 billion pounds. Add to that people with other forms of disability, and on top of that people using old technology, and you begin to reach a very large audience that you may well be currently turning away from your site if your site is not built with accessibility in mind.

But it's not even just people with old technology; it's also people with cutting edge technology. People, for example, that are using mobile devices to access the Internet. The iPhone has really revolutionized the web, and is changing the way that we access information online. It's created a plethora of other devices that provide real Internet connectivity on the move.

This has all kinds of impacts from an accessibility point of view. Many websites aren't as accessible as they could be on these mobile devices. So there are accessibility issues there. But you know what? There is one single individual that has greater accessibility needs than anybody else, and who we really, really must cater for.

That individual is Google. Google is the archetype of disabled users. Google cannot see the images on your page, isn't concerned with the layout. It's concerned only with the content. It has trouble with things like Flash, with JavaScript, and other kind of proprietary technologies. It has all kinds of accessibility issues. And if you want to be rated high on Google, then you need to take the subject of accessibility seriously.

But when it comes down to it, what is our accessibility campaign all about? Why do you bother with accessibility? Ultimately, accessibility is about meeting the needs of your users. Who are your users? Do they actually have a common disability? For example are the majority of your audience, people using your site, male? If they are, then a considerable number of them will be colour-blind. You need to take that into account when creating your site.

Are the majority of your audience over 50, where people start suffering, as I've already said, from poor vision or motor control. If they are--here's a little tangent, here's a little tip for you--take two sets of gloves and put them on, both sets. Then try using a mouse, use your keyboard and you'll get a sense of what somebody suffering from arthritis might have to go through in order to use the computer. It's very enlightening. Definitely give it a go. So, get to understand your audience and build your accessibility solution around their needs and who they are.

So, this is all very airy-fairy stuff, but how do we start? How do you go about laying a strong foundation. Well, I would argue that actually the initial building block is the WCAG 1.0 guidelines that I mentioned earlier. But don't get hung up if you disregard some of what it says. There are some things in the WCAG Guidelines that just don't make any sense anymore. There are problems with things like access keys and empty form fields, all kinds of stuff that you may or may not know about. But don't get hung up on ticking box and saying 'Yes I have completed every element of WCAG 1.0'. Don't get hung up on that. Rather, use that as a building block on which to go further.

One other comment when it comes to using things like WCAG 1.0. There are a lot of tools out there that supposedly automatically check whether you've complied with WCAG 1.0. Don't rely on these tools to heavily. Computers can only go so far at assessing problems. They're very good at doing basic "yes" or "no" things. Does an image have a description, yes or no? But it can't tell whether that description is a good description or not. It can equally do some calculations about colour and stuff like that, but basically a lot of it is down to subjective decision making. Don't rely on automated checkers.

So, we're saying that WCAG 1.0 is our building block. What's the bare minimum here that we're talking about, the bare minimum that you can start with just to get you going, all right? Well, one thing that the WCAG guidelines talks about is something called "alt attributes", also known as "alt tags." You may be aware of these already. Basically, alt attributes are a description of an image.

For example, the image that you're seeing here would have an alt attribute that would say something like "Empty room with light bulb hanging down from ceiling, " and that would be it, a very simple description. But interestingly it's very possible to screw up your alt attributes. I've seen a lot of really bad uses. For one, in order to pass automated checkers I've seen people put alt attributes into their code because the automated checker wanted it there, but just put a star in it and no actual description at all. Now, obviously that's not only useless, it's also really annoying to people with screen readers that's going to read out, every time it hits an image, "star."

Also, I've seen alt attributes that have got far, far too much text, which is very annoying when that's being read back to you. It just takes forever to get through it and adds no real value. I've heard marketing spiel put into alt attributes as well, which are more about selling products than describing the image. I've also seen people use them for search engine optimization purposes where, to all intents and purposes, the content is gibberish, just a load of keywords shoved in.

All of those things can be incredibly damaging from an accessibility point of view. And that's what I mean. It's not enough just to follow the guidelines that say you must have an alt attribute, you've to go a step further and make sure that alt attributes actually has some kind of value to it.

Very similar to alt attributes is something called "title attributes". Title attributes basically can be applied to pretty much any element of your page and can provide a description of what that element is about. So it's often used, for example, on links to provide more information about where the link goes.

Now, I've seen this abused, as well, in much the same way as the alt attributes, but also with the added bonus that sometimes they put the same text in the alt attribute and the title tag. The result is that it gets read out twice if you are a screen reader user, just to double the annoyance. So, put in alt attributes, do them carefully. Put in title tags, consider them carefully.

Also, think about media alternatives. So with things like Java Script, Flash, Quicktime, audio, video, anything like that, you need to think about can people access that same information in an alternative way. Always look to convey that information in an alternative way. It's just good practice and good manners, to be perfectly honest, but also has benefits for things like Google and stuff like that.

It's this area that a lot of organizations get tripped up on, because they feel it's very expensive to provide alternatives to the all the various media they provide. I'm not claiming it's always easy, but there are tools out there that help, and you don't always need to provide the information in exactly the same way. So, there are always alternatives available to you.

The final one--well, there's a couple more actually. The next one I wanted to mention is Java Script. Java Script is a very interesting one. Java script is hugely popular at the moment from things like Google Maps to things like Gmail--lots of Java script being used on the web. But you need to think carefully about how you use it because it can cause all kinds of problems, not only to Google, that I mentioned earlier, but also to people working in corporate networks, where often Java script can be turned off because of security concerns. Also, it can be a problem for screen readers that kind of half read Java script and half don't.

So, consider carefully how you use Java script on your site, and make sure that your site still operates even when Java Script is turned off. Keep an eye on Java Script, it's a slippery one. You get seduced into using it because it does all this cool stuff. I'm not saying you shouldn't use it, but you just need to think about what happens to users that don't have it enabled.

Another one I wanted to mention is resizable text. Always try to make the text on your site resizable. I've seen people do things like go, "I'm trying to make my website accessible; therefore I'm going to make the text really big". That's a mistake, because not all users want text to be that large. Some people actually have forms of tunnel vision where they can only see a very small area of the screen, so you need to make the text small, not large.

So put the user in control. And that's good practice generally when it comes to accessibility: always give the user as much control as possible, and they can decide how they want to organize things and structure things.

The final one--and this really is the final one in my "Bare Minimums" that you should be looking at--is standards. You might have heard of something called web standards. If you haven't, google it. I don't have time to cover it in detail here. But suffice it to say, standards is about separating design from content. By doing that, you allow all kinds of possibilities to people accessing your site through alternative devices. You can style the content to be appropriate to people on mobile devices. You can get rid of the styling entirely for people that don't see it, like screen reader users. Separating out content from design really opens up all kinds of possibilities. Now, put a question mark beside it because it is possible to be accessible without using web standards, but it's certainly good practice to do it if you possibly can.

The next hint about how to really start out with accessibility is to talk to your users. Test your site with real disabled users. Ask your users what the major accessibility issues are that they're encountering and engage with your community wherever possible. It's really important to do this. Interacting with your users will go a long way to solving all kinds of accessibility problems, but also all kinds of complaints.

And when you do come across problems, when people do encounter problems with your site, then respond quickly. If you get a complaint, fix them. Fix it quickly. Be responsive. If you can't fix it, explain why you can't fix it. Engage in a dialogue with the people that are asking questions about accessibility.

People don't sue without warning first. A really big example of this, one of the big cases that people often use for fear-mongering, is Target in America. Target is a huge chain of shops out in the states that got sued because of the accessibility problems with their site. They were initially approached by somebody that said, "I'm having problems accessing your site." Target ignored them. That person then took it further, started getting legal people involved. They were ignored. They were ignored time and time again. Eventually Target was sued, and that's the kind of model. People don't sue you as a first line of attack, so to speak. They sue you as a last resort. So, if you respond quickly and have a dialogue with people, you'll very rarely get into that kind of situation.

Let's summarize everything we've been saying and wrap things up. Accessibility is for all. It's not just about disabled people and it's certainly not just about the blind. It's more than checklist, move beyond the checklist mentality, and really start trying to engage with your community, to talk with people, to really get into accessibility, to put together your own accessibility policy, rather than just doing a checklist and being done with it. Lay solid foundations. Get the basics right first.

There's a temptation to feel like you have to do everything. Don't try and run before you walk. Do the easy stuff first. Pick the low-hanging fruit, as they say. Lay those solid foundations and build on that. Then start talking and consulting with real users, with real disability problems. When problems do arise, when people do complain, make sure you respond quickly.

So, there you go. That about sums it up. Thank you very much for taking the time to listen to this. I know it's a very long presentation. If you want to find out more about either Headscape or myself, you can find out more about Headscape at Headscape.co.uk, find out more about me at Boagworld.com. You can send me an email from either of those sites. I'd love to talk about the issue of accessibility with you.

Just to finish up, here's a thank you to all of the people that provided the photographs for this. I got all of my photographs from Flickr, and I want to just give them credit for that. Thank you very much for watching and I hope you found it useful.

This page is an accessible version of the main Headscape website. For the full interactive experience visit our homepage.