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.
Leave a Reply to Democratizing Accessibility