Published on | Prototyping: From UX to Front End — Medium Kinneret Yifrah

This post was written with Rotem Binheim, UX designer and AUX expert.
It was originaly published on Invision Blog.

Anyone writing microcopy knows there’s a thin line between providing a good, effective experience and evoking frustration — and the difference can be just one word or a quick hint exactly where it’s needed.

This is doubly true in the case of accessible microcopy and people who are unable to see the screen.

The good news is there are 7 simple guidelines we need to follow to make sure we’re serving these folks.

Of course, these guidelines are for the microcopy writers themselves, but since most of them aren’t in charge of actually implementing what they wrote, it’s important that product managers, UX designers, visual designers, and developers are also familiar with these principles.

How does your microcopy sound on a screen reader?

People who are visually impaired often use a screen reader to browse websites and use apps.

Navigating with a screen reader isn’t done with a mouse (as the user isn’t able to see the on-screen cursor), but rather by keyboard. Each press of the tab or arrow keys advances the screen reader one element further — from the top down or from left to right, or according to a hierarchy set during development. The screen reader audibly reads each element in focus and identifies it as a link, button, or image when necessary.

As a result, people using screen readers don’t perceive a full picture of the screen, or even a partial one of adjacent screen elements — they’re instead notified of each element separately.

Before we move on, take a look at this video to better understand how it looks and sounds (and the importance of setting it just right during development):

<a href="https://medium.com/media/9e3c30f42ea114d6e2b19bb4ae56c710/href">https://medium.com/media/9e3c30f42ea114d6e2b19bb4ae56c710/href</a>

How can we make our microcopy compatible with screen readers?

1. Think top-down and left to right

As mentioned, using a keyboard to navigate a website advances us from top to bottom and from left to right (and also back). So when we embed a piece of microcopy to help users complete a task or to prevent them from getting an error, placing the microcopy in front of the action is critical.

For example, on the form below, people will hear the field label (“Password”), and on the next tab they’ll enter their password. But when they create a password, they have no idea there’s a guideline written below the field (“Must be 6 or more characters and contain at least 1 number”) because they haven’t reached it yet. So users will choose a password and then find out there were further instructions. Then they’ll have to go back and choose a password that meets the requirements.

In this instance, screen reader users will also reach the drop-downs without knowing there‘s more information to the right. They, like everyone else, will be wondering why you’re asking for their birth date, but they wouldn’t know there’s an answer in a tooltip after the input fields.

They might skip this question, or even abandon the task, because they don’t see why they should give up this private information.

The solution here is to place the instruction right after the label, ahead of the input fields.

The accessible order of elements is therefore: Label > Instruction\Hint > Field

Here’s how Facebook does it:

And here’s how Walmart does it:

Note for developers: The elements can appear in any order on screen as long as you set the keyboard focus shift in the correct accessible order.

For the same reason, it’s important to not place any microcopy under a confirmation button. Someone with a vision impairment told us about her failure to complete an online purchase as she clicked the confirmation button (5 times) and nothing happened.

She then found out that there was an “accept conditions” checkbox under the confirmation button, along with an error message pointing to the fact it was a mandatory field.

Of course, she couldn’t see those things, nor did the focus shift to them automatically, so after all the time and effort invested in making the order, she wound up having to go to a brick-and-mortar store.

To sum things up

All the information needed to complete an action should be present ahead of it — above or to its right.

In cases that might result in errors, make sure during the development stage that the focus correctly shifts so no one misses the piece of copy that can help them stay on the right track.

2. Be witty, but not at the expense of the plain message

Will people understand where they are and what comes next, just from hearing the text read to them?

In the next image you see the loading time meter for a swimming school website.

It includes some clever microcopy (“Diving in soon”), but for users who will only hear the words and not see the entire screen, it’s not at all clear that they need to wait for the site to load.

A simple correction can solve this. Explicitly say something like:

The site is loading; we’ll be diving in soon

When users reach an empty state or 404 page, refrain from using just an image or clever words to explain where they are. And try not to use a combination of image and text that will be misunderstood if someone sees one without the other.

What will users who can’t see the screen understand from only hearing “It’s oh, so quiet”?

For errors or empty states, write: the page was not found, or there are no results, or there are no items in the cart or new notifications — and also explain how to proceed from here. All users will find this helpful.

On sign up or login pages, although it’s always worthwhile to welcome users with an inviting headline, don’t forget to say what the page is all about.

In this sign-up page for a wedding planning website, the headline “Let’s take our relationship to the next level” is appropriate for the desired voice and tone, but it doesn’t say that this is the place to sign up for the site.

When screen reader users arrive at the email field, they still don’t know there’s a password field and registration button below it, so they have no idea why their email is required. Maybe the next level is signing up for a newsletter?

Granted, they’ll discover the password field on their next click as the keyboard navigation proceeds, but you can save them from the hassle of wondering “What do I do here and why do they need my email?”

Oh, and it’s best to mention that this is a sign-up page for seeing users as well, and add a few good reasons they should register. Two birds, one stone.

Writing the basic message is especially important on confirmation and error messages.

Close your eyes and repeat out loud the message you wrote.
What do you understand from it?
Is it unequivocal?

In a confirmation message, do users who just hear the microcopy and can’t see the green V, or smiling emoji, experience the reassuring confirmation and understand they’ve successfully completed the action as they intended?

In an error message, do users who just hear the microcopy understand exactly what went wrong and how to proceed from here, even if they can’t see the field now has a red outline, or an added red exclamation mark?

3. A written alternative to every icon and every image

Every image or icon that bears visual information should have a short description — alt — set during development. This text will not appear on screen, but will be read to users navigating using a keyboard and screen reader.

Not every illustration needs a description. If it’s a stock photo that doesn’t enhance understanding or is important for setting the experience, it’s actually better to spare this information from users navigating with the keyboard because they’re inundated with information as it is.

There’s no need to describe the scene appearing on the TV nor the TV itself, as there is a description of it on the right

If an image fails to load, due to connectivity problems for example, the alt will be visible to seeing users as well — so it helps everybody.

Icons are images, too. If you have icons representing actions or features and they’re unaccompanied by words (like a cogwheel or a house), add an alt to them that says where they lead to, like: Homepage or Settings.

For example, the icons at the bottom of the screen on the Medium app are unaccompanied by text, but a screen reader will read the alt assigned to each: Home, Bookmarks, Write, Activities, You.

See and hear it in this 9 sec video:

<a href="https://medium.com/media/8d34fe39bfd2ad3fd8a505e5951b0944/href">https://medium.com/media/8d34fe39bfd2ad3fd8a505e5951b0944/href</a>

If we don’t add an alt, the screen reader will just say image or link or button (depending on the setting decided by developers), and users who can’t see them won’t know about the extra actions or features present.

The icon for more information, indicated by an image of the letter i, or of a question mark or exclamation mark, should also have an alt describing what lies ahead. For example: How to choose a password or More info. If we fail to give these tiny-but-important icons an alt, users who can’t see them won’t be aware of this crucial information.

These question marks should have an alt description so users know there’s more information here

Heads up #1 There’s no point in being clever with alt text. It should be clear and unequivocal.
Heads up #2 If the information is extremely salient, consider displaying it at all times rather than as a tooltip.

Emojis have preset alts
Want to know what users hear when you use Emojis in your microcopy?
Watch this video:

<a href="https://medium.com/media/58cfb938bce02a39fd0c2d61b15f2d58/href">https://medium.com/media/58cfb938bce02a39fd0c2d61b15f2d58/href</a>

4. Be more descriptive than “Read more” for links and buttons

Navigating with a keyboard allows you to jump between screen sections:

Navigate between headlines only
Navigate between links and buttons only

People who aren’t able to see the screen in its entirety can thus quickly grasp what the important elements on the page are, then choose to navigate directly to what most interests them.

So what does someone hear when jumping between buttons in the following screen?

Since the headlines aren’t links, this person will just hear “View post” repeated 3 times, with no indication whatsoever as to what these posts are about.

It only takes a minor adjustment to solve this — no need to be overly clever. For example, you could replace each “View post” with: My graduation outfit, How to stop chasing success, To the gift guide.

When links or buttons give a little bit more information about the page they lead to, everyone wins: people with screen readers can decide if it’s relevant, and everyone gets a good specific prompt to keep on reading.

5. All microcopy should appear as live text — not as an image

Screen readers only read live text. So if your button is actually an image; if the word beneath the icon is saved with it as one image; if you put a large image on your 404 page, with text in it explaining the situation — none of this text will be read to users who can’t see.

Ask yourself if you can understand and proceed without reading this text. If the answer is no, turn the text into live text or give it an appropriate substitute in the image alt text.

The creative, thoughtful text on the right is part of the image, and visually impaired people have no clue it exists (unless there’s alt text in the background). But even if it were live text, will someone be able to understand — without seeing the image on the left — that the page they wanted couldn’t be found?

6. Readability: Permanent text in high contrast

All the instructions, hints, and notes regarding filling a form or taking any other action should always be available — permanently visible or in a tooltip you can return to and read at any point in time.

Placeholders that disappear as soon as the field comes into focus are inaccessible, even to seeing users.

If set by developers as available to screen readers, placeholders that change location are passable for visually impaired users as far as accessibility, but their movement might confuse users with cognitive impairment.

So if you have abundant space, place the labels outside the field — always visible and static.
If space is at a premium, make sure whatever appeared in the field is also available when it’s in focus.

Placeholders that move are accessible for screen readers, but less so for cognitive-impaired usersInaccessible — the label appears as a placeholder and disappears when field is in focus

Contrast — all microcopy should appear in high contrast (to the background it appears on) so users with a vision impairment or dyslexia can easily see and read it. This will also be much more convenient for others, making it easier for all users to read basic info.

Placeholders — if they contain information important for completing a task, they too should adhere to the high-contrast standards and not appear too bright. If they don’t contain pertinent information, why are they there? Delete them — it’ll benefit all users.

Inaccessible — placeholders in low contrast. But these placeholders are redundant and shouldn’t be enhanced but rather deletedMost accessible — sign-up form for the Tesco website. The labels are permanent and out of the field, there is high contrast in the field

7. Simple is best

We tend to imagine writing for people who instantly comprehend what they read, but not everyone is actually able to do that. Many users won’t necessarily understand — or have the patience to try to understand — abbreviations, acronyms, or the use of puns and word play.

A note to microcopy (UX) writers: Ever since I’ve learned the principles of accessibility written here, I’ve overcome a big challenge in writing microcopy at large. I got a clear answer to my question of how clever I should be when writing microcopy. I imagine the screen reader reading the text, or a user with a cognitive impairment reading it, and I immediately arrive at where and how much cleverness I can use and where to draw the line. My writing has become simpler and clearer, with witty wording only in the right places.

The login form above is very cool, but it’s inaccessible. Even if everyone understands that “magic word” refers to password, will they all understand that “I don’t have a magic word yet” means “I don’t have an account”? This is cleverness upon cleverness that doesn’t serve anyusers. Also note the low contrast in the light blur fields and how difficult it is to read them.

So keep on writing rich, interesting, character-filled microcopy — but always remember to ask yourself if everyone will understand what you’ve written.

7 guidelines for writing accessible microcopy was originally published in Prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

7 guidelines for writing accessible microcopy

Top Stories