Web accessibility can be an inexact science, and another unwelcome addition to work pressures for those who are not directly responsible for websites. But if we are to encourage and enable civic engagement, we must be as inclusive as possible: and that means being as accessible as possible.
A few months ago my friend Andy Mabbett gave a talk on basic web accessibility, tailored for people who create content rather than those who actually build websites. I transcribed it for him, and he has kindly let me publish it here in full.
Transcript of Andy Mabbett’s talk on basic web accessibility
Andy Mabbett is web manager for a large local authority. This work is licensed under the Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-nd/3.0/ or write to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA.
I can now take you through, point by point, the new WCAG 2 guidelines, explaining in detail what each one means. Hands up everybody who wants me to do that? Good, nobody. Right, hands up everybody who manages or creates – in terms of writing HTML – websites for a living.
Right, if you don’t understand accessibility – and if you don’t already do accessibility now – please leave the building, leave the country and leave the planet. Because if you’re doing that work professionally and you don’t already get accessibility, you’re in the wrong job. You’ve had fifteen or more years to get used to this: it’s time now that you knew what you were doing.
Today’s talk is for the rest of you: right? The people who use websites, put content onto websites, without having to know all the geeky stuff about what html tags are and labels for forms and all that sort of thing. The people who provide those tools should be making that work for you.
I’m going to try and illustrate some of the pitfalls of what you do on websites, or what you may be doing on websites, and how it may affect people in terms of the accessibility of your site.
Now most people think about accessibility – blind people using text readers. That’s a major issue in terms of accessibility but it’s not the only one. It’s about old people who have – as we all if we live long enough – a reduction in the ability to use ours senses or physical movement; it’s about people with physical disabilities, it’s about people who can’t use a mouse because they’ve knackered their wrist playing on the computers all the time, and have to use the keyboard or some other device; it’s about people with learning disabilities, it’s about people with hearing difficulties; you name it, it’s anybody who has some sort of difficulty. And if you make a website accessible for them, you’ll make it more usable for all your users.
Ok, that’s the preamble; here comes the talk.
I’m afraid this talk, to illustrate this point, isn’t very accessible.
[Low voice] The first thing I want to say is that you’re going to find it very hard to hear me; [raises voice] okay? So you didn’t hear that, did you?
There’s an analogy there: I was speaking in a very small font (it was probably Comic Sans). If you write in a small font, then people will not be able to read it if they’ve got poor eyesight; it stands to reason.
Now yes, there are tools in their browsers that can make the font bigger again; but they’ve already got the font on their browser set to the size that they need it at for a 100 percent text. If you make your text 90 percent in a footnote they can probably cope with that; but if you have some artistic design on your page and you design your pages to work at 80 percent – or 60 percent – then they’re going to have to use those tools to magnify the page to read your pages and then switch them back to read everybody else’s, and you’re putting barriers in their way.
So please, keep your font sizes reasonable and – if it’s within your control – make it possible for them to resize text.
Now I’m going to talk about one of three different things, and I want you to tell me which one you’d rather I talk about. Would you like me to talk about ‘here’, ‘here’, or ‘here’?
If you have links on your website that say ‘click here’ – ‘to read more about sport, click here’; ‘to read more about chocolate, click here’; to read more about music, click here’ – and all that links is the bit that says ‘click here’, or ‘here’, or something non-meaningful like that – then people using certain assistive technology have all the links separate to the rest of the page read out to them. So they can say ‘read all the links on the page out to me so I can see what to link to’. Then all they might hear is ‘here’, ‘here’, ‘here’: it’s meaningless.
Make your link text meaningful, standalone and unique on the page; so never have ‘more news’ twice if it links to two different pages. Each link – the actual link text – needs to be unique.
Now the next thing is, I want you to tell me which sentence in the previous illustration I gave was green. Come on, you all heard it; which bit of it was written in green ink? You don’t know, do you?
If you write a page on your website or on your blog and you say ‘all the things I like are in green and all the things I don’t like are in red’, then somebody who is blind and having that page read to them by their assistive software – or someone who is red-green colourblind, which is the commonest for of colourblindness; or somebody who’s looking at a black and white printout of that page; or somebody who’s looking at it on a monochrome mobile browsing device such is an early generation internet-aware mobile phone – can’t see that colour.
Never use colour as the only distinguisher for choices on your web pages or in your blogs. Always have ‘the things I like are in green and have an asterisk next to them; the things I don’t like are in red and have a hash symbol next to them’, or something like that. So there is a visual indicator that doesn’t rely on colour and there’s an indicator which can be read out, and the easy way to think about that if you’re not familiar with assistive technologies that read web pages, is imagining you’ve got to read that page over a telephone to a friend.
Which of the sentences in the previous explanation was on the left? And which was on the right hand side of the page that I was reading from? No, you can’t tell me!
Geo-spacial positioning of the content on your page is meaningless to a blind person. It is meaningless to someone who is reading your RSS feed.
If you look on my blog and do a search back you’ll find a post from about a year ago where somebody said ‘the icon on the right is our new logo’, and it was actually on the left in Google Reader; because Google Reader linearised the page and put the icon top-left.
Never refer to things on the right or left. Never put images side by side, and say ‘the image on the left is better than the image on the right’ or whatever; say ‘the first’ or ‘the second’ image, or label them ‘image a’ and ‘image b’: and that way the position of those images doesn’t matter because there is no position when the page is read out.
When you’re learning to code html [interruption from someone singing loudly], when you’re learning [more interruption], when you’re learning to [yet more interruption]; you can stop now John.
We’ve all been in the situation when you load a web page and it starts playing music to you. And if you’re trying to watch television at the time, or listen to music, that’s annoying. If you’re in an office full of people and it’s a page you shouldn’t be looking at at work it could be very embarrassing (so I’m told). If you’re a blind person who’s having that page read to you by assistive technology it stops you accessing that page; it stops you knowing what’s on that page. So never play music or other sounds on your pages, unless the user says ‘play it now’ by hitting a ‘play’ button or a ‘start’ button. Please.
So that’s an important lesson for your benefit as well as the benefit of your users.
One of the things you also need to think about with HTML design is to make sure your QRPs and your PTZs aren’t conflicting with your KLMs.
Or if you are going to use long acronyms such as I’ve just done, you’re going to have to make sure that they’re explained to your users. Don’t assume – unless you’re talking to a very specific audience – that they know what they mean; and if you are able to use the proper abbreviation element in html, to expand those abbreviations and acronyms.
Finally, I’m going to talk about the ‘alt’ text on images. Now I hope you all know what that is; I hope we’ve got past the stage where I have to explain that. I hope nobody in here has ‘alt’ text on their images that says ‘image’ or ‘f437.jpg’ or anything like that: if you do, go to the back of the class.
I’m going to close with an illustration of ‘alt’ text on two images; this is a real example which one of my friends found on a web page about a holiday site. The first image had a picture of a local animal; the second one had a picture of some people enjoying one of the activities that you could do at this holiday site.
Now the way to understand whether your ‘alt’ text is working – as with the examples I used earlier – is to imagine reading it over the phone. Because that’s what assistive technology does: it reads the page out and it reads the ‘alt’ text inline, as though it was part of the text of the page.
And this holiday site’s website had a picture of an animal followed by a picture of a holiday activity. And it said:
‘At Sunnyside Holiday Camp you can see a cow canoeing in the river’.
Thank you very much ladies and gentlemen.
Andy Mabbett , March 2009