Writing accessible copy at Booking.com

Easy ways to add a11y to your UX writing toolkit

Published in

Booking.com — UX Writing

7 min readJan 7, 2019

Joining Booking.com in September 2017 started the biggest and steepest professional learning curve I’ve been on as a writer. I was immersed in a topic that was brand new for me: accessibility. This post is a summary of what I learned then and links to resources I find useful over a year later.

You could think of accessibility as “UX+” or as an extra skill, but that would be missing the point in a way. Accessibility is fundamental UX, and it doesn’t take too much to add it to your toolkit.

Every time you make an accessibility improvement you’re empowering people, with a variety of needs, to experience the world. And that’s powerful.

You might have seen or heard the term a11y (pronounced ‘alley’) when reading about accessibility. If not, you will soon. It’s a handy numeronym that uses the first and last letters (a + y) and the number of characters between them when ‘accessibility’ is spelled out in full. Just a heads up — I’m going to use it in the rest of this post.

Accessibility improves your site for everyone

Confession time. My first a11y challenge was learning what it is. I started with the vaguest idea that it affects blind people. And previously I didn’t spend much time thinking how my work would affect people who couldn’t see it.

I was wrong.

Let’s start with a quick look at who is positively affected by an accessible website:

Everyone

Accessibility doesn’t mean ‘make it work for people with disabilities’. Although around 15% of the world’s population lives with a permanent disability, at some point in their lives 100% of people will experience some form of impairment. These can be either permanent, temporary, or situational.

Hands poised above a laptop keyboard. Adding accessibility to your UX toolkit as a copywriter is just another way to make sure you’re making your message as clear to as many people as possible. (Kaitlyn Baker via Unsplash.com)

Website accessibility tends to focus on making the site better for people with visual impairments (especially screenreader users). But it’s important to note that impairments aren’t just visual.

There are many ways in which impairments present themselves. People might have a combination of specialised needs rather than just one impairment. Their needs will change over time too.

Examples of impairments and possible UX impact

These groupings aren’t exhaustive, but hopefully they’ll start you thinking about different sorts of impairments.

Visual impairments — anyone who can’t see your designs or copy the same way you do. Anyone who uses a screenreader probably has a visual impairment, whether they’re fully blind or partially sighted. But it also could include someone who has lost the glasses or contact lenses they rely on, or even those who struggle to read brightly lit screens by the end of the day. They might use a larger font or zoom in on their browsers. What if they’re colourblind? Will your design flex to accommodate these things?

Neurodiversity — examples of this might be dyslexia or the autistic spectrum. People with neurodiversity needs might struggle with processing complicated language, solid blocks of text, or prioritising information when there’s competition for their attention.

Hearing loss — as with sight, levels of deafness vary considerably. If you have content that relies on audio — whether that’s uncaptioned videos or sounds that prompt (or are linked to) user actions, they might miss out.

Mobility, manual dexterity or cognitive impairments — examples include conditions such as epilepsy, side-effects of illnesses like cancer, or maybe broken fingers on your dominant hand. People with these impairments might physically or mentally struggle to engage with your site.

How do we connect these impairments at an abstract level e.g. ‘a blind person’ with improving a UX experience? Same way we do it for any UX design challenge— creating personas so that we can write more realistically.

I don’t have (and wouldn’t suggest) a set of specific a11y personas, but I struggled with making sweeping generalisations about impairments. Fortunately, I found this post: An Alphabet of Accessibility Issues from the Pastry Box Project — it’s a great portrayal of ways that impairments present in the real world. And it still helps me think in more rounded terms when writing for Booking.com users.

Image shows a woman and two men — one younger, one older — smiling at the camera/each other. What if this lady lost her glasses and needed to zoom her browser to 200% to get through a day’s work? How about if the man on the right is colourblind or dyslexic, and can’t remember details very well as a side effect of chemotherapy? These are all considerations that an accessible website can flex to include. It’s important to note that ‘accessibility’ doesn’t just mean the disabilities that you might first think of, although it can make browsing your site easier for these users too (Nathan Anderson via Unsplash.com)

Where copywriters can make a11y improvements

Fixing accessibility isn’t something that a copywriter can do alone. It’s an ongoing process at Booking.com as there’s legacy code to tackle as well as making new products and features compliant.

However, it’s something I consider as part of my regular workflow and I’d encourage you to include it too. The main things that we need to remember as copywriters are: context/structure (and how much we take it for granted) and clarity — especially on action points/instructions.

As a rule of thumb, your copy will need optimising for accessibility if it:

relies on a visual clue for meaning (e.g. icons, colours, graphics)
is designed to be read in continuing parts (e.g. one sentence running between a header and subheader)
works with a functional bit of your site (e.g. buttons, or placeholder text in a search box)

When I say ‘optimising’, this might mean adding a label in the code so that the screenreader knows to read it in a certain way. Or you might have to simplify your sentence or structure.

Why is this so important?

If you’ve never used a screen reader, give it a try. Until you hear how your site reads, without the support of visual/contextual clues, it’s difficult to imagine how confusing navigation can be. If you use a Mac — good news, you already have VoiceOver installed. For PC users there’s NVDA (free) or JAWS (free trial then paid licence).

Headings are one of the key ways to help users of assistive technology navigate your site. And headings with correct semantics (i.e. <h1> — <h6>) provide a really clear idea of the structure of a page and the relative importance of the information on there. Using landmarks (the major regions of the page) is another way for people to grasp this. The alternative is navigating line by line.

Labels! Tell me about the labels thing!

ARIA attributes (stands for Accessible Rich Internet Applications) are another way for assistive technology users to get the information they need. It might be explaining where a user needs to click to close a tooltip, or that they can navigate through a calendar with their keyboard, or connecting two separate bits of text for audible continuity.

An example of an aria-label — it tells you what the button action is (“Choose your currency”), and the existing state (“Your current currency is Euro”)

It’s better to make sure the html is semantically correct than label things willy-nilly, but it’ll be a conversation with a designer/dev to know which option to go for.

What do you mean by clarity?

Accessibility is a short-hand for making a site really usable for everyone. So by clarity, I mean clear functions as well as understandable information. Imagine, for example, that you have a five step process for your user to click through to buy your product.

If every button in that process just said ‘continue’, how many continues before you lose track of where you are? How about if the buttons read: ‘let’s go!’ / ‘Sounds ace’ / ‘I’m in!’ / ‘Great!’ / ‘BOOM!’ — any idea what you’re agreeing to and what’s coming next? Doubt it.

Clarity, in this case, is striking a balance between function and motivation. Reassuring customers where they are in your process is useful for everyone.

*Buttons for subsequent steps in the process of making a reservation on Booking.com*

One set of buttons for subsequent steps in making a reservation on Booking.com reads: Search / Choose your room / I’ll reserve / Next: Final details / Complete booking. This is one example of CTAs that take into account the different stages of a user journey. This is (hopefully) clearer for everyone than either of the extreme approaches above.

Links to resources I found useful

Guidelines:

Accessibility is based on a comprehensive set of standards called the Web Content Accessibility Guidelines (WCAG) set by The Web Accessibility Initiative (WIA) which covers all aspects of website design and functionality. Here are their writing guidelines. When you or your team is ready to figure out what you need to fix, and how to prioritise it, I’d suggest running your pages through the WAVE Evaluation Tool which will evaluate your sites’ web accessibility in Chrome.

Videos and simulators:

Playing with simulators is another good way to get into your users’ experience — Funkify.org is pretty cool, and I’m sure there are more.

Want a quick way to hear how screen readers *should* sound in different languages? This video has English, Spanish read as if it were English and Spanish read as Spanish.

The A11ycasts youtube series (starting here) is a deep dive into the topic from Google developers.