Skip to main content
Accessibility
for teams

Accessibility for content designers

full guide

As a content designer, you decide what people read and how it is structured. Clear, well-structured content helps everyone, and for many disabled people it decides whether they can use a page at all. This guide is a starting point.

How to write accessible content

chapter 1

Writing

Write in plain language

Use short sentences and common words. Put the most important information first. Plain language helps people with cognitive disabilities, people who read in a second language, and anyone who is in a hurry.

Don’t

“Should you wish to terminate your subscription, please be advised that a notice period of one calendar month applies.”

Do

“You can cancel your subscription at any time. It ends one month after you cancel.”

WCAG 3.1.5 Reading Level (AAA)

Write link text that makes sense on its own

A link should tell people where it goes. Screen reader users often jump from link to link, or bring up a list of all links on a page. Then they hear the link text without the sentence around it.

The underlined words are the link text.

Don’t

“To read our opening hours, click here (link).”

Do

“Read our opening hours (link).”

Watch out

Avoid “click here” and “read more”. In a list of links, they all sound the same.

WCAG 2.4.4 Link Purpose (In Context)
Explain abbreviations and jargon

Write out an abbreviation the first time you use it, and explain words your readers might not know. Not everyone knows the jargon of your organisation or your field.

Don’t

“Send the signed NDA to HR before the KO.”

Do

“Send the signed non-disclosure agreement (NDA) to the human resources team before the kick-off meeting.”

WCAG 3.1.4 Abbreviations (AAA)

Structure

Use headings to structure your content

Headings help people scan a page and find what they need. Screen reader users can jump from heading to heading, just like sighted users skim a page.

Use one main heading per page, don’t skip levels, and never use a heading only to make text look bigger.

The headings of a page about opening hours.

Don’t

Heading 1: Opening hours

Heading 4: Weekdays (it looked nicer)

Bold text: Holidays

Do

Heading 1: Opening hours

Heading 2: Weekdays

Heading 2: Holidays

WCAG 1.3.1 Info and Relationships
Use real lists

When you sum things up, use a bulleted or numbered list in your editor instead of dashes or line breaks. They look the same, but only a real list tells a screen reader that a list starts and how many items it has.

What a screen reader says.

Don’t

“Dash passport. Dash proof of address. Dash bank statement.”

Do

“List, 3 items. Passport. Proof of address. Bank statement.”

WCAG 1.3.1 Info and Relationships
Give every page a unique title

The page title is the first thing a screen reader reads when a page opens, and it is the name of the tab in the browser. Start with what is unique about the page, and end with the name of the website.

The title of the page with opening hours.

Don’t

“City Library | Information”

Do

“Opening hours | City Library”

WCAG 2.4.2 Page Titled

Images and media

Give images a text alternative

People who can’t see an image rely on its text alternative. Describe what the image means in this context, not every detail. A decorative image gets an empty alternative, so screen readers skip it.

A bar chart in an annual report.

Don’t

“Chart”

Do

“Library visitors doubled between 2020 and 2024, from 40,000 to 80,000.”

WCAG 1.1.1 Non-text Content
Provide captions and transcripts

Video needs captions for people who are deaf or hard of hearing. Audio and video both need a transcript: a text version that people can read at their own pace, and that search engines can find too.

WCAG 1.2.2 Captions (Prerecorded)
Don’t put text in images

Text in an image can’t be resized, translated or read aloud like real text. It also becomes blurry when people zoom in. Use real text instead, and if you must use an image of text, repeat the text in the text alternative.

WCAG 1.4.5 Images of Text

Instructions

Don’t rely on shape, colour or position alone

Not everyone can see colour, and a screen reader user doesn’t know what is on the right. On a phone, “on the right” may even be below. Use the name of the button instead.

Don’t

“Click the green button on the right.”

Do

“Select Send.”

WCAG 1.3.3 Sensory Characteristics
Write clear labels and error messages

Every form field needs a visible label that says what to fill in. When something goes wrong, the error message says what happened and how to fix it.

The error message when an email address is missing its @.

Don’t

“Invalid input.”

Do

“Enter an email address, like name@example.com.”

WCAG 3.3.3 Error Suggestion

How to find accessibility issues

chapter 2

Check headings and links with bookmarklets

These bookmarklets show the headings or the links of any page, the way a screen reader user can bring them up.

Drag these links to the bookmarks bar in your browser to install them. Clicking them on this page does nothing: they work on the page you want to check. Using a keyboard? Copy the link address and save it as a new bookmark.

Check your writing

Read your text out loud, or let your computer read it to you. Sentences that are hard to say are often hard to read. Even better: test your content with people from your audience, including disabled people.