The other day, I was doing a final check for a voter guide project. An elections office had created a sample PDF, asked me to check it and identify any problems, then figure out how to solve them. We’d gone back and forth for a few days.
When I finally sent off the email saying all the ducks were in a row, and that the office could start printing the PDF booklet, I breathed a sigh of relief.
And then, like you do, I took to Twitter to share some of my frustration. Much of my time had been devoted to handling the tedious minutiae of setting, checking, and double-checking technical settings I’d chosen in Word–wondering if I’d checked off the right option. So I tweeted this:
It’s not that you can’t create an accessible pdf from an accessible Word file.
It’s that it’s so easy to get it wrong.
I didn’t expect the tweet to launch a Twitter conversation that went on for two days. The response prompted me to write a longer form post.
PDFs are not always the best way to share information. Most of the time, you’d find me standing at the head of the line advocating for HTML. Sometimes though, PDFs are the right solution. Particularly for long reports or other documents.
For the voter guide project, PDF is the better option. And assuming you begin with an accessible file, turning it into a PDF ought to be the easiest, fastest way to get from digital source to an accessible printed report. Sadly this isn’t the case.
In the voter guide project I just worked on, the source file was Word. I’d heard that InDesign does do a better job of creating PDF files. And while that’s good advice, it doesn’t address the question of why it’s so hard to make a relatively simple, accessible Word file into an accessible PDF.
Worse, I’ve taken a look at the documentation on creating an accessible PDF from InDesign and it doesn’t look that easy. Powerful, yes. But not easy.
Why does it matter if it’s easy or not? You shouldn’t need an expert to create accessible documents! There simply aren’t enough experts to go around. Templates can help. Cheatsheets and checklists are good reminders. If accessible documents require experts to make them, it’s no wonder there are so few accessible documents out there. Without accessible documents, millions of people lose the ability to get the information to participate in their country’s elections.
But this is about more than elections. In every business and university, people create documents every day. People whose expertise or main focus probably isn’t technology or accessibility. This isn’t a criticism. It’s the real world–and we’re not yet serving everyone’s needs.
Designing for accessibility ought to be easy. It ought to be the default for software. The features to create documents shouldn’t be hidden behind 3 or 4 clicks–every single time you need to use those settings.
Here’s what a typical conversation sounds like helping someone through the process:
Them: I know I’m supposed to put alt text on this image, but I can’t figure out where it goes.
Me: It’s in the formatting properties.
Them: Where? I see Glow and Artistic Effects and things like that…
Me: See the little blue square with the arrows.
Them: Oooooh. That’s where it’s hiding.
And that’s a good conversation. Sadly, too many sound like this:
Me: See the luggage tag on the left. Open that. Now click on the thing that says “Tags” at the top of the panel and…
Them: Wait. What….what is all this? This looks…complicated. How am I going to learn this?
Me: Just send me the file and I’ll fix it.
In both cases, creating accessible information has been made harder than it should be, or downright scary. When accessibility is too much work, it’s a hidden tax.
The good news is we can fix this. I suggest two principles for programs that could make the world more accessible:
Make software defaults that support accessibility.
And make sure the defaults don’t actively harm accessibility. For example, the default Word option to “Bitmap text when fonts may not be embedded” seems like a good thing, but it turns text into little snippets of images. You might not notice this with a visual inspection, but it causes real problems for screen readers. Don’t take the option away…just make it clear what will happen. And don’t make it the default.
Make accessibility features easy to find.
Don’t hide or require several clicks to get to these features. Or make users guess at what they mean. For example, the table property to “Repeat as header row at the top of each page” also sets the row as a header for screen readers, but how would anyone know that this is important (or why it’s important). Maybe the default should be that the first row is set as a heading row. It can be changed, but if you do nothing, you have a more accessible table.
So, what happened to the elections project?
If you’re curious, the booklet was turned into 85 versions. They will be voter guides with information about the candidates and measures on the ballot (along with some basics about ways to vote).
There are 85 of them because there’s not just one ballot for the whole county or state. In New Jersey, where we have a lot of local government, each borough, town, and township has a different ballot. In many places, there are overlapping water districts, fire districts and school districts on top of the boundaries for local offices. I’ve seen the GIS mapping layers for suburban Cook County outside of Chicago, and just thinking about them makes my head hurt.
A large county can have hundreds of different ballots. Even a small county might have dozens. Each is a unique combination of contests for one geographical area. Because the schedule is crazy fast, there’s only a few days between when the list of candidates and measures are certified and when the booklets (and ballots) have to be ready to go to the printer and be posted on the web.
Getting it right is important. The right ballot content. The right languages. The right legal notices. And getting accessibility right, too.
But most of all, easy counts.
It’s the only way we’re going to make real progress.
What you can do
P.S. Since the most obvious recommendation is to “take it up with the vendors” when you have a problem–I did. Because if they never hear about the problems, they can’t fix them. I’ve been talking to both Adobe and Microsoft. They both have online forums. If this matters to you, let them know.
Whitney Quesenbery is the co-founder of the Center for Civic Design. She’s passionate about making interactions with government effective and enjoyable, and bringing more design literacy to elections and government workers. She’s co-authored three books— A Web for Everyone: Designing Accessible User Experiences (with Sarah Horton), Storytelling for User Experience: Crafting Stories for Better Design (with Kevin Brooks) and Global UX: Design and Research in a Connected World (with Daniel Szuc). Follow Whitney on Twitter.
Why Can’t We Make It Easier To Be Accessible?
Posted on 19 comments|
19 Responses to “Why Can’t We Make It Easier To Be Accessible?”
Offline HTML is often better than PDF.
Just because no one makes them doesn’t mean this isn’t so. I make prototypes of different types of web pages that can be downloaded into single HYML files that can be read offline in a browser. And they do usually look a lot better than PDF.
It would be great to see those kinds of tools widely available so that everyone can use them, not just web developers and designers.
You’re right, Whitney!
And the solution is to let Microsoft and Adobe — the two major manufacturers of our routine software — know that accessibility is at the top of our list.
I don’t think these companies fully understand what’s at stake for everyone.
And, help them understand the different ways their tools are used. I’ve had some interesting conversations recently about how hard it is to find the right way to do … anything. For example, there’s at least 4 ways to create a PDF in Word (Print to PDF, Export, Save As, and a plug-in). They all seem to create slightly different PDF files and handle document features differently. Whew! How do I know which one to choose … for the specific document I’m working on?
Thank you! As someone who has become the document accessibility expert, I worry about the supply and demand. I’d love much more transparency. The anecdote about hiding alt text in Word for graphics is the prime example. Thanks for sharing.
This is a tipping point, when a skill or service moves from specialists to being something that moderately skilled generalists can do, to a real general too. It’s always a little scary for the early experts, and it’s easy to fear that the skill will be diluted. But I believe that it usually comes out OK in the end. A good example might be photography. Far from ruining the photographic image, as cameras have become more general, we’ve discovered that many people can make amazing images when we give them the technical tools they need. And people with the best eye and best control of the tools will still make even more amazing images.
YES. YES. YES. I just read this and thought “WHITNEY IS ONE OF MY PEOPLE!!” LOL … Like, Sharon, I’m a document accessibility expert as well, and I would be more than willing to give up my job security to have this be a process that’s easier for everyone every time. (Have you built fillable forms in INDD and then exported to Acrobat? Holy hell. It should not have to be so difficult.)
Thank you for sharing!
You are now one of my people, too. 🙂
I don’t InDesign but I’ve heard the pain.
This is an important, but often neglected aspect of accessibility—helping people author accessible content. It’s why the W3C Authoring Tool Accessibility Guidelines (ATAG, http://www.w3.org/TR/ATAG20/) are so valuable.
In particular, to Whitney’s two key principles, part B of ATAG is focused on supporting the production of accessible content, including making accessibility features easy to find and apply. So we need to focus on increasing adoption of ATAG by digital content authoring tool vendors—and one way to do that is when we procure tools, demand evidence of ATAG conformance.
Anything that provides guidance about how to make tools easier to use is a Good Thing.
Even a little bit of usability testing, observing real people doing real tasks would be useful. It wouldn’t take long to see the enormous drain of repetitive steps to complete the same actions over and over. Or the sheer frustration of trying to solve some of the crazier problems that seem to happen in response to some small action.
This isn’t a new idea. UX people have been doing home/office studies to understand how people do things for decades. All we have to do is include creating accessibility as part of the critical functions of the software.
Great post but due to all the issues with PDF and the non-fixing of these issues (they’re never fixed even if reported); why can’t we suggest moving to HTML only or ePub files? Most visually disabled people I know will not even attempt to open a PDF because of all of it’s issues.
PDF’s do a poor job of supporting math while HTML and ePub’s already do. And if you have attempted to alter the tags or reading order within Adobe Pro, then you also know the issues that pop up there as well. (WHERE DID THAT TEXT LINE GO?!?!)
Why are we keeping an old technology relevant? Treat it like Flash and IE 6 and kill it with fire already!
As I say right at the start, there are many times when HTML is the right way to go. But there are also times when you want to post as exact a copy of a printed document as possible. That’s what PDF is for. If then making an accessible version is a lot of extra work, it’s less likely to happen.
Just curious: how do people feel about posting in multiple formats. Maybe HTML, ePub, and a PDF for printing only? Of course they’d have to be offered as equal choices, and clearly identified.
[…] a very thought-provoking article over at Rosenfeld Media by Whitney Quesenbery that I think can be applied to the WordPress space. It discusses the […]
“Designing for accessibility ought to be easy. It ought to be the default for software. ” No truer words have ever been spoken. It is as if you had been standing over my shoulder for the last 2 days.
Enabling default settings and other UX aspects is something I have been trying to promote in LibreOffice/OpenOffice Writer, by filing feature requests such as “Enable accessible/tagged PDF export options by default”, “always prompt for text alternative when inserting picture to create accessible documents by default” and “Uncheck ‘Allow row to break across pages and columns’ by default” (and several issues about the loss of accessibility information when exporting or importing specific formats). Filing bugs and feature requests is easy, but developers are needed to solve the issues. Many of the accessibility-related bugs I submitted are five years old. To be fair, some have been resolved and LibreOffice developers have recently been giving them more attention.
Thanks for all the things you’ve done. It can seem like a lot of extra work, but if we all took a moment to send in one comment every once in a while, it would add up. More people filing a few comments might even be better than one person filing a lot of them.
One other point I’d like to make is about the crying need for good design of accessibility features. For example, a modal dialog interrupting you for alt text as you add an image is just plain annoying. But have the place to enter it (and captions) easily handy any time you are working on the image, and being able to quickly see what the alt text says as you edit a document would be wonderful and make this small task part of the bigger goal of a great document.
Excellent article Whitney! I’d like to share a link to the Salsa project: http://salsa.usu.edu. IMHO it is a great example of what you are asking for 🙂
In 2010 I was working as an Instructional Designer building fully-online courses at Utah State University. I saw a critical need for accessible course materials, and I targeted the first document that most online students encounter: the syllabus. I started with a template for MS Word, progressed to simple document builders, and today Salsa is a web application that creates HTML documents that are accessible by default.
Salsa is free-to-use, and doesn’t require an account or email address. Salsa’s code is open source and available at http://bit.ly/salsaGitHub.
I’d love to see Microsoft Word make an effort to making PDFs more accessible right out of the box! They could do it, you know. But then they would have to collaborate with their enemy and admit PDF format is here to stay.
But hey, let’s start with Color Contrast — that’s important for accessibility in *any* format. How about having some color styles that are built for accessibility and a guide for the user to choose font colors that work with the background shading they’ve chosen?
How hard would it be for Microsoft to incorporate a color contrast checker…. like the CCA Paciello Group developed. It’s free by the way, but would make a nice addition to Microsoft Word.
Great article. I would love to see a similar review on Google Docs when utilized with our GrackleDocs accessibility Add-On. It automatically checks 15 different things as well as giving the ability to create tagged PDF. http://www.grackledocs.com