I’m here today to talk about accessibility as it relates to web content. Our cultural picture of disability is often a physical disability, and something like being in a wheelchair doesn’t affect your web use. So what do we mean when we’re talking about content accessibility?
Cognitive impairment: we’re talking things like learning disabilities, dyslexia, and attention deficit disorder. Cognitive issues tend to come into play when we have bad formatting, and use dense language or lots of jargon. Anything that makes our content hard to understand runs up against cognitive issues.
Hearing impairment: 20% of adult Americans – that’s 50 million people – have some form of hearing loss. For people over 65, if you serve an older audience, it’s a full one-third of the population.
Vision impairment: Almost 22 million Americans (that’s just under 10%) have some form of visual disability that can’t be corrected with glasses. The number is much smaller if you look at people who qualify as “legally blind”, but it’s growing, because almost 40% of people with diabetes have some level of damage to their retina (and as I’m sure you’re aware, diabetes is one of our largest national health issues).
Motor impairment: fine motor impairment; this is people who aren’t using a mouse to move around your site. This can be anything from carpal tunnel to ALS, from Parkinsons to arthritis. They may be using voice-controlled software full-time, or may have a temporary hand or finger injury. We don’t actually have good numbers for motor disabilities, because “people who prefer a keyboard in the mornings when their joints are bad” – they don’t show up on surveys.
In summary: somewhere between 18 and 132% of your users have some sort of disability. It doesn’t actually matter what the real number is, because it’s not zero.
People who have issues seeing, or hearing, or using a mouse, or wading through jargon, have always been, and will always be, a significant part of your audience.
So how can we make sure that your content is available to all of your users?
Here are my core beliefs for building accessible content:
Progress, Not Perfection
Accessibility is not a checklist; it’s an intention.
I don’t think it’s helpful to think of accessibility as pass/fail. Not only because there’s a gradient of accessible content, but also because it’s discouraging. I want to shift, instead, to approaching accessibility as an intention: as we’re developing content, when we realize that we’re falling short of our accessibility goals, we don’t berate ourselves, or shame others. We react to that shortcoming by shifting our priorities, and fixing the problem that we’ve recognized. Like all content strategy, this work is not about perfection, but about progress.
The other side of Progress Not Perfection is to start small. Trying to fix everything at once is a quick path to frustration. Instead, start by picking just one thing – look for something that’s controlled by you or your team (so that you don’t, initially, have to get organization-wide support), or find just one gap and fill that, across the board. You want something small, so that you can do it, and you can point at it and say “look, we fixed that, we are making progress, and it is not that hard.”
Pattie Moore is an industrial designer focused on aging, she works on product design, and also on environmental design (like rehab facilities, senior housing, public transit). She believes that there’s no reason to have two sets of products: one for “fit and agile” and another for “disabled”.
Here’s an easy example of this idea: we can call this “handicapped ramp for wheelchair people who can’t use their legs”. Or we can call it “a ramp”: it is an alternative to the stairs. Everyone can use it, everyone will use it: a person in a wheelchair, a dude who twisted his ankle, a pregnant woman, a lady carrying a box full of books. It’s a ramp.
Pattie Moore uses the term universal design, and she’s saying that the affordances that we build in the name of accessibility are useful to everyone.
When we start thinking about things like plain language, better formatting, clear writing – the principle of universal design makes a lot of sense for web content, too.
Weave it in from the beginning
A big part of normalizing accessibility is that we can’t treat it as an add-on or an extra. We have to find ways – even small ways – to make accessibility part of the creation process the first time. Because A) there’s never budget or energy to go back and fix stuff later, and B) Framing accessibility work as a special “other” part of the process keeps it at arms length, and encourages the mindset that people who need affordances are not “normal” users, that they are freaks and weirdos who need special attention. No.
These three principles can be applied to all of the content you create, but today we’re going to look at three of the worst offenders when it comes to accessibility.
Video & Audio
People are very excited about video and audio content right now. With good reason! It can be very compelling to watch a person explain something, or to have both visual and aural cues when you’re learning about a new program, or trying to understand something complex.
And the technology needed to make videos and audio recordings, of course, is getting smaller, and cheaper, and easier to use every day.
However! If you have vision issues, video is not really that great. If you have hearing issues, video and audio are not really that great.
So when we present our content as video or audio files, what do we need to do to make sure everyone has access to that information?
There’s a really simple answer here: transcripts. There are tons of professional transcription firms;you send them a file, they send you back a transcript. You’ll still have to proofread it (especially for names and special words and acronyms), but the bulk of the work is taken care of.
Cost-estimate, for clean audio: $1/minute. That’s dirt-cheap! If you’re producing one 20-minute audio piece every week, that’s $100/month for full transcripts. And frankly, if you have the budget to produce that much video or audio each month, you have the budget to get it transcribed.
Or, if you don’t have the budget to get it transcribed, you can do it in-house. It’s not particularly hard, but it is time consuming: you can estimate 5:1, so a 20 minute speech will take ~90–100 minutes to transcribe.
If we’re thinking about weaving it in from the beginning, a really important shift we have to make around video and audio, is that we don’t post it on the website until we have a transcript. Right? It can’t be an afterthought, because afterthoughts don’t happen. We have to think of the audio or video file as being only one-half of the content; it’s not ready for the website until the entire package is complete.
That sounds good, right? Heck yeah, transcripts!! But maybe – maybe that’s just not happening. What then?
Think: progress, not perfection. If the audio is of a speech, or a press conference: who wrote the speech? If your department produced a video: was it created from a script? Publish those.
Sure, they won’t match the finished product exactly, but the alternative is that you have no text at all, and you’re sending the very clear message that “this content was intended for the rest of our audience, not you.” That’s a jerk move, and you guys are fine upstanding citizens; I can see it in your eyes. You’re not jerks.
I’m not gonna lie, transcripts are work, but they are work that has huge payoff, so far beyond the surface:
In terms of universal design: transcripts are the wheelchair ramp of web accessibility. Everyone uses them.
There are so many reasons to want text instead of rich media. I’m sure that every one of us has at some point clicked a link expecting an article, been presented with a video instead, and been like “aww, man”.
Some of your users are in quiet places, or noisy places, or they’re not strong in spoken English, or they have crappy bandwidth, and that’s before we even get to Google and SEO! Transcripts are amazing for SEO.
You do – you do want people to find your content, right?
A transcript is going to contain not only your keywords, but your keywords repeated in a variety of appropriate contexts, with natural language and other relevant topics worked right in – this is literally exactly the kind of content that Google and other search engines are training their algorithms to look for.
Transcripts are so useful, on so many levels.
Let’s talk about the big ogre of accessible content: PDFs.
A lot of organizations put a lot of content online in PDF format. They like it because it looks like print; if you make a lot of printed materials, saving it as a PDF is a tiny step and then you can say “this content is on our website!”.
I got bad new for you: PDFs, they’re not accessible. Well: sort of accessible? Not really accessible. It’s complicated. Here’s the deal:
Back in the olden times, like 3 years ago, PDFs were profoundly inaccessible. A PDF is, fundamentally, a picture of a document, so there was no way for assistive technology to read the words, because it wasn’t words, it was a picture. (Remember how it used to be impossible to select and copy a chunk of text out of a PDF? Same thing – it’s just a picture.)
In the last few years, Adobe expanded the PDF standard to include markup – so it’s still a picture, but now there’s code behind the picture. Which means you can select text, there are headers, you can put alt text on the images – it’s pretty good. A person with a screenreader, or keyboard-only navigation, they can use this document.
There are two catches:
- You have to do the work. PDFs aren’t accessible by default; you have to make them that way.
- The other catch, and this a huge one, is that even if you make your document perfectly accessible – a model of what PDFs should be – it is not fully accessible on any mobile device.
“Voiceover” (which is Apple’s screenreader) and “Talkback” (which is Android’s): they can’t read the accessibility tags on PDFs. They can mostly read the basic content, but they can’t see the alt text on pictures, they can’t jump from header to header, they can’t skip directly to a section in the middle, and trying to deal with a PDF form? Ugh. Pit of despair.
Why is this important? I will remind you of some statistics:
- 17% of American adults use their phone as their primary – or only – access to the internet.
- Those numbers jump to 42% for Black Americans, and 51% for Hispanic Americans.
- Low-income households, especially those without a college degree, 50% use their phone as their only access to the internet.
(And those numbers are from 2012; they are only getting higher.)
Add to that something like that ~31% of visually-impaired Americans live below the poverty line, and as we start to compound minority statuses: if your audience is non-white, and non-rich, and has a disability – chances are nearing 100% that those folks are accessing the internet on a phone. If your content isn’t available on mobile, your content does not exist.
So I would love to say, stop putting your content in PDFs. Just: stop.
But, we live in the real world. Getting PDFs up onto your site is probably the smoothest content workflow you have, and nothing short of a catastrophic coup is going to kill that process.
So: Progress, not perfection. How can we make this better?
First! Do the work to make your PDFs accessible. This is all done at creation-time, and it’s not a big deal. There are 3 parts:
- Create the PDFs digitally, natively from the source file. Do not scan a printed document. (You’re probably doing this already.)
- In your source file, learn to use “Styles” rather than manually formatting your text. And use them semantically: don’t use “heading 4” because it’s bold and underlined, use it because the content is a 4th-level-header. (Adobe has a decent tutorial on how you should create and organize your document to prep it best for accessible-PDF conversion.)
- The latest version of Adobe Acrobat Pro (XI) has an accessibility wizard. It walks you through your document and leads you through setting page titles, writing alt text for your images, and so on. It’s not difficult, and it doesn’t take very long. You just have to find the one person in your office who has a current version of Acrobat Pro and run the wizard on each document once before you upload it.
Also! On the webpage that links to this document, provide a summary and some key points of what the user can expect to find inside. Don’t make them download it and struggle through the crappy technology experience just to find out that this isn’t the file they’re looking for.
In terms of universal design: accessible PDFs are great for SEO. Search engines crawl PDFs now – you know this, because you see PDFs in your search results list – but robots can’t read pictures. The work you do to make these documents accessible, also makes them searchable.
And document summaries: document summaries are amazing. Everyone finds them useful. Why wouldn’t you want your users, when faced with a list of 7 or 8 PDFs, to know what was in each one, and to download the right one on the first try?
Taking Accessibility Back to Work
I am not an accessibility specialist. It’s not the niche-focus of my career, I’m not a leader in the field. But I’m somehow considered expert-ish, because I care about it, and I’m familiar with the terms, and I can have intelligent and productive conversations.
Literally, depressingly, at least 50% of being considered an accessibility expert is being the person who remembers to bring it up.
In terms of weaving it in from the beginning, I’ve got a big ask here: I’m gonna ask you to Be That Guy. You don’t have to be obnoxious about it, but one of the biggest barriers to creating accessible content is that people just don’t think about it. It’s not part of their regular conversations.
I mean, before 3 minutes ago, how many of you knew that iPhone’s Voiceover had problems with PDFs? Yeah, not many. But now: you know.
You can talk about how great transcripts are, you can be that person who chimes in and says “We’ll need to write a summary for each of those PDFs, so people know what’s inside them before downloading.”
Don’t segregate those discussions into “accessibility meetings”, or wait for people to ask “oh yeah what about accessibility”. Instead, just slide this stuff in to your current workflow. It’s totally normal, totally boring run-of-the-mill content stuff; it just happens to make the website better for everyone.
And you might be saying, “Is this even part of my job? Who am I to become the accessibility expert in my department?”
I don’t have a real good answer for that, except to ask: Well, who are you not to?