A UX Copywriter’s Guide to Accessibility

4 ways we’re thinking about writing for everyone at DocuSign

Let’s start with a brief manifesto

I’d like to start this with a bit of a manifesto about why UX writers need to care about accessibility.

When we build robust web experiences we need to build them for the actual, real people who use them. This means making sites that work:

• For those with motor, vision, hearing, or other disabilities
• For those using small screens, large screens, and any screen in-between
• Via mouse, keyboard, stylus, voice, or touch
• On fiber, bad cellular connections, and any bandwidth in-between

The short version of this is: however someone is accessing the web, our products need to support them.

UX copy might only be one part of how users experience our sites, but it’s crucial to how they navigate them. Because of that, we have a responsibility to push for accessibility whenever we sit down to write.

Wait, wait, wait. Who are you and why are you qualified to talk about this stuff?

Great question. I’m a UI Copywriter at DocuSign, working on a product called DocuSign CLM.

Accessibility isn’t necessarily my speciality, but it’s something that I’m passionate about. I wouldn’t consider myself an expert, but I am a practitioner and I’m lucky enough to be at a company that prioritizes this stuff.

Ultimately, the important thing to remember is that making accessible sites and products is simply the right thing to do. And everyone should care about doing the right thing.

So how is this article going to help me make my site more accessible?

It helps to think about accessible UX copy by breaking it into four basic parts:

1. Language
2. Page structure
3. Visual cues
4. Images

I’ll go into what I’ve learned about each area as well as examples around how we’re tackling them at DocuSign. Hopefully this will help you get a better idea of how to apply these tips in practice.

1. Start with language

At a really basic level, accessible language means language that people can read. If your users can’t understand your content, then what’s the point of writing it?

To do that, we have to make sure copy in our products is consistent, clear, and concise.

1.1 Breaking down the 3 Cs

Being consistent means using the same word to describe an action. For example, you’ll want to make sure that “Save” and “Edit” mean the same thing throughout your product.

Making sure your copy is clear and concise is a little trickier, but as a general rule:

• Keep your sentences short
• Use the active voice
• Replace polysyllabic words or jargon with simple alternatives
• Put your main points higher on the page
• When writing for the general public, try and hit an eighth-grade reading level

If you do all that, your content is likely to be quick to read, concise, and able to reach everyone.

1.2 How are we doing at DocuSign?

Overall, I’d say DocuSign does a great job of hitting these three goals. But there are always places and ways to improve.

For example, here’s a snapshot from DocuSign CLM’s integration page:

This text is tough to read, but even technical descriptions like this can usually be made clear.

That paragraph is written at roughly a Grade 16 reading level, but the average American’s reading level is around eighth grade. This results in a lot of people not being able to understand it, and for those who can understand it, the grade level adds unnecessary friction.

Remember: people don’t read web pages. They scan them. We need to write content that fits within how people actually interact with our products.

Fortunately, we don’t have to sacrifice correctness in our pursuit of clarity. We could say something like:

“Any integrated apps have their own folder for the documents and folders they create. You can change the name of the folder and how much access you give to the integrated apps here.”

It communicates the same information but it’s at a seventh-grade reading level.

1.3 When in doubt…

If you’re ever in doubt, try copying and pasting your text into Microsoft Word’s reading level tool, Hemingway App or Datayze’s Readability Analyzer. These tools can help you check the reading levels of your text (as well as other writing issues like passive voice).

They aren’t perfect, and you’ll have to use your professional judgment, but they’re a great resource and way to check your writing.

2. Be thoughtful about page structure

The next big area of focus is your page structure. When we talk about web page structure, we’re talking about the way headers, paragraphs, and links are arranged on the page.

2.1 Make it skimmable

We know from eye tracking studies that most readers on the web read in an F-pattern and we know that only 16% of users read word-for-word.

That means we need to help readers skim through our content, including readers with disabilities who might use a screen reader or navigate exclusively with a keyboard.

We do that by providing structure.

2.2 Block your content

If this post was just one long, unbroken string of text then it would be really hard to skim. The way to fix that is by organizing your content into chunks — blocks of content like paragraphs, sentences, images, and videos — that make sense together. Then you use header tags (<h1>, <h2>, <h3>, etc.) to mark the start and end of different chunks of content and give them a hierarchy.

This makes the content’s structure easy to skim for all your users so they’ll be able to easily find what they’re looking for.

Properly coding these headers also helps users who are utilizing a screen reader or navigating the web with their keyboard. Keyboard users use the “Tab” button to move forward and down the page while screen reader might be set up to read the headers to the user first, before the rest of the content.

2.3 Do you have a good example?

DocuSign’s “Send for Signature” page does a pretty good job of showing this. The important stuff is high up, the content is neatly divided into coherent chunks, and the headers are pronounced.

You probably don’t have to read the whole page to navigate around and get a document ready for signature.

DocuSign’s “Send for Signature” page is pretty easy to scan and understand.

3. Consider your visual cues

When we write using visual cues, we’re excluding users with visual impairments. We need to be mindful enough to avoid thinking and writing in visual terms.

This can be hard to avoid, though. After all, the “Buy Now” button is orange. The link to the PDF is there on the right. That form is on the left side of the page.

This section will help provide you with some tools to stay mindful of visual cues in your writing.

3.1 Avoid directional language

One trap that is really easy to fall into is using directional language. When I say directional language I mean using words like “above” or “below” or “left” or “right.”

This is a problem that we’ve faced at DocuSign that we’re trying to fix. For example, in our CLM workflow designer, the instructions for how to add steps to the canvas uses directional language.

The paragraph text under the “Add Steps” header uses directional language. It also is hard to read because of the font color and italics, but that’s a different issue.

In this case, a quick rewrite is all that’s necessary. Something like:

“Drag steps from the list onto the canvas to add them to your workflow.”

The reason we want to avoid things like directional language and visual cues is that in a lot of cases, these words are meaningless to the user. And not just those who are legally blind or visually impaired either. Smartphone users (ideally) see streamlined versions of the site, where things will have moved to accommodate the dimensions of their screens. Users with screen readers won’t have “right” or “left” as a reference. Color-blind users will have difficulties if you require them to distinguish buttons primarily by color.

Avoiding these cues doesn’t just help make what users need to do clear, it also shows empathy and consideration for all the ways that people navigate the web.

3.2 Create flexible solutions

I also like to think about this selfishly. If a product designer makes significant design changes, any copy requiring visual cues will need to be reworked to align with the new design. More work for me is bad enough, but it also leaves more opportunities for a design and copy mismatch.

Sure, that call to action might be on the left side of the page now, but maybe after a redesign it will be on the right. Or even below the content.

3.3 Mind your verbs…

It’s easy to assume that we understand how people use our products and navigate our sites. But I would gently suggest that avoiding verbs like “Click” that make assumptions about how a user is navigating the web is a smart policy. Users who are navigating with a keyboard or on a smartphone aren’t going to be clicking anything. Instead, a verb like “Select” is general enough to include users who are clicking, tapping, pressing, or navigating the web in ways you haven’t even considered yet.

Of course, the best way to write UX copy is to think about the end result, not the process. Think about what happens when a user selects that button rather than focusing on the fact that they have to select the button. As an example, if they are verifying their account by clicking select, “Verify” is probably the right verb to use.

Using context like this is not just more accessible, but it’ll lead to better, clearer copy in the long term.

3.4 …And also your links

Another thing to consider is the language we use around links and buttons. A button or link that says “Read More”, “Click here”, or“More” is ambiguous and can become unusable if out of context. If you need to use that kind of link, you’ll want to work with your developers to include hidden text that provides more context for screen reader users.

A simpler solution is to just write links or button labels that are specific. This helps users navigate around the page and know what to expect when they select the link.

It’s especially important for users who are relying on a screen reader to navigate the web because one screen reader navigation mode allows users to jump between links and buttons. So, screen readers are skipping content to help these users navigate more efficiently.

For example, when a user lands on CLM Reporting, they’re presented with a dense cluster of actions they can take on an existing report: Edit, Export, Delete, Search. Each button is clear and distinct.

Clear button labels help users navigate more efficiently.

It can also help to vary the link text. Repeating “View Post” as the link to every new blog post will get repetitive as your screen reader jumps from link-to-link, while not giving you any indication about what the posts in question are about. It also doesn’t help users skim for what they’re looking for.

Finally, if a link is going to download a file, it’s a great idea to indicate filetype and (especially) file size. That way your user will know if they have the app they need to open the file, approximately how long the download will take, and how much space it’ll be using.

4. What about images?

Finally, we have images. Images present a big hurdle for accessibility. Sometimes when web products get a snazzy visual refresh, accessibility gets ignored or sacrificed. But, as a writer you can help!

4.1 Be thoughtful about alt text

The biggest way to help is by providing great alt text on all the images your designer gives you. Alt-text is literally an alternative to seeing the image directly. Both screen readers and search engines need alt text to understand what the image is because they can’t see the image in the way that you or I can.

Without alt text tags (alt=“[Description]”) users with impaired sight will have no idea that a picture of your cute cat was a picture of a cat. They would just know that there was some kind of image there.

This is a 500 error page, so instead of the image saying something like: “Drawing of a woman screwing in a lightbulb”, it makes more sense to use “500 internal server error” as the alt text.

4.2 Follow this cheat sheet

However, getting concise and clear alt text is easier said than done. In fact, there’s lots of nuance to how you can approach it.

Here are some quick tips:

1. Ask yourself: what is this image supposed to communicate? Do you have a clever image that ultimately is just telling users that there’s been a 404 error? Then maybe the alt text should read “Page not found” instead of addressing that the image is of a monkey at a typewriter.
2. These alt tags need to be relevant to users, so aim for clear descriptions rather than inserting as many keywords as possible. Keyword stuffing makes alt tags less useful to users who need them. Plus, Google doesn’t appreciate it.
3. Maybe this is just a stylistic quirk, but I would avoid describing the gender, age, or race of people in images, unless it’s specific to the content being understood. A picture of a doctor who is female and in her mid-fifties just needs to be described as “doctor.”
4. Avoid using “image of” or a similar phrase. By using an alt tag, it’s already implied that there’s an image there.
5. Icons need alt text too. An icon of a house that takes a user to your site’s homepage probably should be labeled “Home” and a gear icon that takes a user to the settings page should be labeled likewise.
6. If the image is decorative, just leave the alt tag blank. Screen readers will know to skip it.
7. Don’t use an image of text as a button. Use live text.
8. Include captions and transcriptions on any video that you have uploaded.

Conclusion

Ultimately, I think the thing to remember about writing copy is that you want your users to be able to use your product as effectively as possible, so the words you choose have to work for everyone.

We want to write clear content that people can understand quickly, we want to give a clear structure so everyone can scan quickly, we want to avoid visual cues because those aren’t intelligible to everyone all the time, and we need to provide alt tags so everyone can understand what the images are of.

Again, this guide just scratches the surface, but hopefully it can help get you started towards making your product more accessible.

Did I miss something? I’d love to hear your thoughts or additional tips in the comments!

Acknowledgments

🙌 Special thanks to Javier Yep for his wonderful illustration. Shout-out to Dania Marinshaw and Jeff Caruso for their ruthless editing.

👋 Want more from the DocuSign PX team? Follow us on Medium and on Dribbble. Want to work together? We’re hiring!