A visitor told you about a barrier on your website. Here is what to do.
Someone could not use part of your site and took the time to tell you. This guide explains, in plain words, what each kind of barrier means and how to put it right. It is free, and you can use it with any website platform.
First, three things to know
- This is a real person, not a robot. The message was written by a visitor who had trouble on your page. They sent it from their own email.
- It is feedback, not a complaint. Most people who hit a barrier simply leave. This person told you instead, which gives you a chance to keep them and others like them.
- One barrier often affects many people. People who use a keyboard, a screen reader, voice control, screen magnification or larger text can all be stopped by the same problem.
Find the kind of barrier named in the message below. Each section says what the visitor met, how to check it yourself, and how to put it right.
1. Something can’t be reached or used with the keyboard
The visitor said: “I could not reach or use part of the page with the keyboard.”
What it means
Many people do not use a mouse. They move through a page with the Tab key, or with tools that work like a keyboard, such as screen readers, voice control and switch devices. If a menu, button or pop-up only works with a mouse, these visitors are stuck.
Check it yourself
- Open the page and put your mouse aside.
- Press Tab again and again. Can you always see where you are on the page?
- Can you reach every link, button, menu and form field?
- Press Enter or Space on each one. Does it work?
- Open any pop-up or menu. Can you close it with Esc and carry on, or are you stuck inside?
How to put it right
- Use real links and buttons. A link should be an
<a href>and a button should be a<button>. Clickable pictures and plain boxes do not work with a keyboard on their own. - Keep the focus outline visible. If your design removed it, put it back, with a clear outline that stands out from the background.
- Make sure menus open with Enter or Space, not only when a mouse hovers over them.
- In pop-ups, move the keyboard focus into the pop-up when it opens, keep it there, and return it to where it was when the pop-up closes.
- Check that the Tab order follows the reading order of the page.
For your developer: WCAG 2.2 success criteria 2.1.1 Keyboard, 2.1.2 No Keyboard Trap, 2.4.3 Focus Order and 2.4.7 Focus Visible.
2. Text is hard to read
The visitor said: “Some of the text was hard to read (too small, too faint or too cramped).”
What it means
Pale grey text on white, small print, and lines packed tightly together are hard for many people, including people with low vision, people with dyslexia, older readers, and anyone on a phone in sunlight. Some visitors make text bigger in their browser, and the page must still work when they do.
Check it yourself
- Look at your lightest text: placeholder text, captions, footer text and text on top of pictures. Is it easy to read?
- Test your text and background colours in a free contrast checker. Normal text needs a contrast of at least 4.5 to 1. Large text needs at least 3 to 1.
- Zoom the page to 200% (Ctrl and + on Windows, Cmd and + on Mac). Is anything cut off, hidden or overlapping?
How to put it right
- Darken text, or change the background, until it passes the contrast check.
- Use a body text size of about 16 pixels or more, and set sizes in units that grow when the visitor makes text bigger (such as rem).
- Give lines room: a line height of about 1.5 for body text.
- Do not put important text inside pictures. Use real text so it can be made bigger and read aloud.
- Let boxes grow with their text. Fixed heights are a common cause of cut-off text.
For your developer: WCAG 2.2 success criteria 1.4.3 Contrast (Minimum), 1.4.4 Resize Text, 1.4.10 Reflow and 1.4.12 Text Spacing.
3. A button, link, picture or form field has no clear label
The visitor said: “A button, link, picture or form field had no clear label, so I could not tell what it was for.”
What it means
Screen reader users hear a page read out. Voice control users speak the name of the thing they want to press. If a button is only an icon with no name behind it, a screen reader says just “button”, and voice control has no name to listen for. The same happens with pictures that have no description and form fields with no label.
Check it yourself
- Find every button that is only an icon, such as a magnifying glass, a menu icon, a cart or a cross. These are the most common cause.
- Look for links that say only “Click here” or “Read more”. Out of context, they tell the visitor nothing.
- Click on the text next to each form field. If the cursor does not jump into the field, the label is not connected to it.
- Run a free checker such as WAVE on the page. It lists missing labels and descriptions.
How to put it right
- Give every icon button a name, for example “Search”, “Open menu” or “Close”. Your developer can add it as hidden text or with
aria-label. - Write link text that says where the link goes: “Read our delivery times” instead of “Read more”.
- Add a short description (alt text) to pictures that carry meaning. Say what matters about the picture. Pictures that are only decoration should have empty alt text, so they are skipped.
- Give every form field a visible label that stays on screen, and connect it to the field. Placeholder text alone is not a label, because it disappears when the visitor types.
For your developer: WCAG 2.2 success criteria 1.1.1 Non-text Content, 2.4.4 Link Purpose (In Context), 3.3.2 Labels or Instructions and 4.1.2 Name, Role, Value.
4. Something moves, flashes or plays and can’t be stopped
The visitor said: “Something on the page moved, flashed or played by itself and I could not stop it.”
What it means
Sliders, background videos, animations and sound that start by themselves make a page hard to use for many people. Movement pulls attention away from reading. For some people it causes dizziness or nausea, and fast flashing can trigger seizures. Sound that starts by itself talks over a screen reader, so the visitor cannot hear the page.
Check it yourself
- Load the page and watch for 10 seconds. Does anything move, slide, scroll or play without you asking?
- If it does, is there a clear pause or stop button? Can you reach it with the keyboard?
- Does any sound start by itself?
- Does anything flash quickly?
How to put it right
- Do not start video or sound by itself. Let the visitor press play.
- If something moves for more than 5 seconds, add a pause or stop button that is easy to see and works with the keyboard.
- Stop sliders from changing by themselves, or add a pause button and stop them when the visitor moves into them.
- Remove anything that flashes more than three times in one second.
- Respect the “reduce motion” setting on the visitor’s device. Your developer can turn animations off for these visitors with the
prefers-reduced-motionsetting in CSS.
For your developer: WCAG 2.2 success criteria 1.4.2 Audio Control, 2.2.2 Pause, Stop, Hide and 2.3.1 Three Flashes or Below Threshold.
5. A form is hard to fill in, or its errors are unclear
The visitor said: “A form was hard to fill in, or its error messages were unclear.”
What it means
Forms are where visitors buy, book, sign up and get in touch, so a barrier here costs you the most. Common problems are fields with no label, errors shown only as a red border, error messages that do not say what is wrong, time limits, and puzzles (CAPTCHAs) that some people cannot solve.
Check it yourself
- Fill in the form using only the keyboard.
- Send it with a mistake on purpose, such as an empty required field and a wrong email address.
- Is each error explained in words, next to the field it belongs to?
- Is what you already typed still there, or do you have to start again?
- Is there a puzzle or a time limit? Is there another way through for someone who cannot do it?
How to put it right
- Give every field a visible label, and say which fields are required in words, not only with a colour or a star.
- Write errors in plain words that say how to correct them: “Enter an email address, like name@example.com”.
- Show each error next to its field, and do not rely on colour alone. Add an icon or the word “Error”.
- Keep what the visitor typed when the form comes back with errors.
- Let browsers fill in common details. Your developer can add
autocompleteto fields such as name, email and address. - If you use a puzzle to stop spam, offer a way that does not depend on seeing, hearing or solving a test, or use a spam filter that works in the background.
- Avoid time limits. If you need one, warn the visitor and let them ask for more time.
For your developer: WCAG 2.2 success criteria 1.3.5 Identify Input Purpose, 2.2.1 Timing Adjustable, 3.3.1 Error Identification, 3.3.2 Labels or Instructions, 3.3.3 Error Suggestion and 3.3.8 Accessible Authentication (Minimum).
6. A video or audio has no captions or transcript
The visitor said: “A video or audio had no captions or transcript.”
What it means
People who are deaf or hard of hearing need captions to follow a video. Many other people use them too: in a noisy place, in a quiet office, or when the language is not their first. People who cannot see the video need the important things on screen to be said aloud or described.
Check it yourself
- Play each video with the sound off. Can you follow it from the captions?
- Are the captions correct? Captions made automatically often get names, numbers and special words wrong.
- Play the video without looking at the screen. Did you miss anything important that was only shown, not said?
- For a podcast or other audio, is there a written transcript?
How to put it right
- Add captions to every video that has speech. You can start from automatic captions, but read them through and correct them.
- Include who is speaking and important sounds, such as “[phone rings]”.
- Add a written transcript for audio, such as podcasts. Put it on the same page or link to it right next to the player.
- When important information is only shown on screen, say it in the voice-over, or add a version with audio description.
- Use a player with controls that work with the keyboard.
For your developer: WCAG 2.2 success criteria 1.2.1 Audio-only and Video-only (Prerecorded), 1.2.2 Captions (Prerecorded), 1.2.3 Audio Description or Media Alternative (Prerecorded) and 1.2.5 Audio Description (Prerecorded).
How to reply to the person who wrote to you
- Answer, even before it is put right. A short “Thank you, we are looking into it” within a few days means a lot.
- Ask if anything is unclear. If you cannot find the problem, ask which part of the page it was and what they were using, such as a keyboard, a screen reader or large text.
- Tell them when it is done. Ask them to try again if they are willing. They are the best judge of whether it now works for them.
- Value their time. Feedback from people with disabilities who use your site is worth a great deal, and no automatic checker can replace it. If you would like more of their help, for example to try other pages, ask them, and offer to pay them fairly for the work.
The message you received was a favour. The person who wrote to you asked for nothing but a page that works for them.