Marta orders her groceries online every Sunday. She is blind and uses a screen readerScreen readerSoftware that reads the screen aloud for blind and low-vision users, like VoiceOver or TalkBack.Open in glossary → on her laptop. This week the shop released a redesigned checkout. She reaches the payment step and hears: “button. button. edit text. edit text. button.” No labels, no hints. She guesses, gets an error she can’t hear, and gives up. She orders from a competitor instead, and the shop never finds out why it lost a loyal customer.

Nothing “crashed”. Every automated test passed. And yet, for Marta, the checkout was completely broken. Finding this kind of bug is what accessibility testingAccessibility testingChecking that people with disabilities can use the product, for example with a screen reader.Open in glossary → is about, and you don’t need special tools or a special job title to start.

Why it matters

Accessibility (often shortened to a11y, because there are 11 letters between the “a” and the “y”) means people can use a product whatever their abilities, devices or situation. The World Health Organization estimates that about 1.3 billion people, roughly 1 in 6, live with a significant disability. But accessibility helps far more people than that:

Kind	Example	What helps them
Permanent	Blind, low vision, deaf, one arm, tremor, dyslexia	Screen reader support, captions, keyboard access, clear language
Temporary	Broken wrist, eye surgery, lost glasses, ear infection	Keyboard access, zoom, captions
Situational	Holding a baby in one arm, bright sunlight on the screen, a noisy train, a quiet library	One-handed use, good contrast, captions, no sound needed
Age-related	Weaker eyesight, less precise fingers, slower reactions	Larger text, bigger targets, no time limits

See also: Usability Testing Basics for the wider question of whether all users can reach their goals easily.

The legal side (briefly)

Accessibility is increasingly a legal requirement, not just good practice. You don’t need to be a lawyer, but you should know why your team cares:

• European Union: the European Accessibility Act applies from 28 June 2025 to many consumer products and services, including e-commerce, banking, e-books, and passenger transport ticketing. Very small service companies (microenterprises) are exempt. In practice, teams meet it by following the European standard EN 301 549, which builds on WCAG AA.
• United States: the ADA (Americans with Disabilities Act) has been used in many lawsuits about inaccessible websites and apps. In 2024 the Department of Justice adopted WCAG 2.1 AA as the technical standard for state and local government websites and mobile apps (in 2026 it pushed the compliance deadlines back by a year). Federal agencies follow Section 508.
• Elsewhere: the UK, Canada, Australia, Israel and many other countries have their own laws, most of them pointing to WCAG as well.

WCAG in five minutes

The Web Content Accessibility Guidelines (WCAG)WCAGThe Web Content Accessibility Guidelines, the main international standard for accessibility.Open in glossary → are the international standard almost every law and company refers to. They’re published by the W3C. The current version is WCAG 2.2 (October 2023). Many contracts and laws still name 2.1, and 2.2 includes everything in 2.1 (except one obsolete parsing rule), so testing against 2.2 covers both.

The four principles: POUR

Every WCAG rule (called a success criterion) belongs to one of four principles:

Levels A, AA and AAA

Each success criterion has a level:

Level	Meaning	Examples
A	The minimum. Without it, some people can’t use the page at all	Images have text alternatives, everything works with a keyboard, no keyboard traps
AA	The usual target for laws and company policies	Text contrast 4.5:1, visible focus, text can be resized to 200%, consistent navigation
AAA	The highest level, for specialized content. Not required for whole sites	Text contrast 7:1, sign language for videos, no time limits at all

WCAG 2.2 added a few criteria testers should know, such as 2.4.11 Focus Not Obscured (Minimum) (a sticky header or cookie banner must not completely hide the focused element), 2.5.8 Target Size (Minimum) (click/tap targets at least 24×24 CSS pixels, with some exceptions) and 3.3.8 Accessible Authentication (Minimum) (don’t force people to solve puzzles or retype codes from memory to log in; allow password managers and paste).

Experience it

Reading about barriers is one thing. Feeling them is another. The lab below has a sign-up page for a grocery delivery app. This version is built correctly. Use the tools to see how it holds up:

🧑‍🦯 Experience it: accessibility lab

Switch on a simulation, then try to sign up. Each toggle mirrors a real way people use the web, or a tool testers use.

Keyboard only Blurred vision Zoom 200%Color visionNormal visionProtanopia (no red)Deuteranopia (no green)Tritanopia (no blue)Achromatopsia (no color)

greenbasket.shop/signup

GreenBasket

Create your account

Fresh groceries at your door in 30 minutes.

Full name

Email

Password

At least 8 characters, including a number.

I agree to the Terms of Service

Create account

Already have an account? Log in

Screen reader Contrast

What a screen reader announces, item by item. Use the arrows like swiping on a phone, or Tab through the page.

…

TAB = reachable with the Tab key.

The most common failures and how to check them

Most accessibility bugs fall into a handful of patterns. For each one, here’s what to look for and how a manual tester checks it.

1. Keyboard access and visible focus

Many people can’t use a mouse: people with motor disabilities, power users, and everyone using a screen reader on a computer. Keyboard navigationKeyboard navigationUsing a website with only the keyboard: Tab to move, Enter or Space to activate, Esc to close.Open in glossary → must reach and operate every interactive element.

How to check: put the mouse away. Press Tab from the top of the page.

• Can you reach every link, button, field and menu? Custom controls (div “buttons”, custom dropdowns, sliders) are the usual suspects.
• Can you see where you are at all times? A clear focus indicator is required (WCAG 2.4.7). Designers sometimes remove it with outline: none because it “looks ugly”.
• Can you operate controls? Enter activates links and buttons, Space toggles checkboxes and presses buttons, arrow keys move inside radio groups, menus and tabs, Esc closes dialogs.
• Can you get out? Getting stuck inside a widget is a keyboard trap (2.1.2). Modals are the exception: they should keep focus inside on purpose (a focus trapFocus trapKeeping keyboard focus inside an open modal so users can't tab into the hidden page behind it.Open in glossary →) until closed. See Modal.
• Is the focused element hidden behind a sticky header or cookie banner (2.4.11)?

2. Focus order

Focus should move in a logical order, usually the visual reading order: top to bottom, left to right (2.4.3). Watch out for focus jumping to the footer, skipping a field, or going to elements hidden off-screen. When a dialog opens, focus should move into it; when it closes, it should return to the button that opened it.

How to check: Tab through and say out loud where you expect focus to go next. Any surprise is a finding.

3. Color contrast

Low-contrast text is the single most common failure on the web. The contrast ratioContrast ratioHow different text and background colors are; WCAG asks for at least 4.5:1 for normal text.Open in glossary → between text and its background must be at least:

What	AA	AAA
Normal text	4.5:1	7:1
Large text (at least 24 px regular, or about 18.7 px bold)	3:1	4.5:1
UI parts and meaningful graphics: input borders, icons, focus rings, chart lines	3:1	n/a

Typical offenders: light grey hint or placeholder text, white text on orange or yellow buttons, text over photos, disabled-looking but active buttons. (Truly disabled controls are exempt.)

🎨 Contrast checker

Pick two colors and see if the pair passes WCAG. Try the presets: they are real color pairs testers report all the time.

Light grey hintGrey placeholderWhite on brand greenWhite on orangeDark mode body

Text

Background

Small text: Deliver to my address

Large bold text

4.54

: 1 ratio

• AA normal text (4.5:1) Pass
• AA large text (3:1) Pass
• AAA normal text (7:1) Fail
• AAA large text (4.5:1) Pass
• UI parts and icons (AA) (3:1) Pass

How to check: use the color picker in a contrast tool (or in DevTools: inspect the text, click the color swatch in the Styles pane, and DevTools shows the contrast ratio with AA/AAA checks). Check states too: hover, focus, error, and dark mode.

4. Don’t rely on color alone

About 1 in 12 men and 1 in 200 women have some form of color vision deficiency. If an error is shown only by turning a border red, or a chart uses only red and green lines, some users miss it entirely (1.4.1).

How to check: use a greyscale or color-blindness filter. Can you still tell what’s wrong, what’s selected, which line is which? Errors need text (and ideally an icon), links in body text need an underline or other non-color cue.

5. Images and alt text

Every meaningful image needs a text alternative (1.1.1). Screen readers read the alt textAlt textA text description of an image that screen readers read aloud.Open in glossary → instead of the image.

How to check: in DevTools, inspect images and look at the alt attribute, or use an extension like WAVE that shows alt text on top of the page. Then ask: if I couldn’t see this image, would the alt text give me the same information?

6. Form labels and error messages

Forms are where accessibility bugs hurt most, because they block sign-ups, payments and bookings.

• Every field needs a visible label that is programmatically connected to it. Otherwise a screen reader just says “edit text”.
  Dev note

  <label for="…"> or aria-labelledby.
• Placeholder-only labels fail: the placeholderPlaceholderHint text shown inside an empty input field that disappears when the user starts typing.Open in glossary → disappears as soon as you type, it’s usually low contrast, and users with memory difficulties lose track of what the field was for.
• Errors must be described in text (3.3.1), say how to fix it (“Enter a date like 31/12/2025”), be connected to the field and be announced when they appear.
  Dev note

  Connected with aria-describedby and aria-invalid="true".
• Required fields must be indicated in a way that isn’t color alone.

See Text Field and Login and Sign Up for more form-specific checks.

7. Headings and structure

Screen reader users don’t read pages top to bottom: they jump between headings to skim, just like sighted users scan. Pages need a logical heading structure (1.3.1, 2.4.6): one h1, then h2 for sections, h3 inside them, and no “fake” headings made of big bold text.

How to check: use a browser extension that shows the heading outline (WAVE, or the “Headings” view in a screen reader). Does the outline make sense on its own?

8. Link and button text

Screen reader users often pull up a list of all links. A list of “click here, click here, read more, read more” is useless.

9. Zoom 200% and reflow

People with low vision zoom in. Text must be resizable to 200% without losing content or functionality (1.4.4), and at a width of 320 CSS pixels (the same as 400% zoom on a 1280 px wide window) content must reflow into one column without horizontal scrolling (1.4.10).

How to check: press Ctrl/Cmd + + until the browser shows 200%, then 400%. Look for cut-off text, overlapping elements, buttons pushed off-screen and sticky headers that cover half the screen. On mobile, also test the system text size (iOS Larger Text / Dynamic TypeDynamic TypeThe phone setting that lets users make text bigger or smaller across apps.Open in glossary →, Android Font size).

10. Motion and animation

Parallax effects, zooming transitions and auto-playing carousels can cause dizziness and nausea for people with vestibular disorders. Anything that moves, blinks or scrolls automatically for more than 5 seconds needs a way to pause, stop or hide it (2.2.2), nothing may flash more than 3 times per second (2.3.1), and sites should respect the user’s Reduce motion setting.

How to check: turn on Reduce motion (macOS: System Settings › Accessibility › Display; iOS: Settings › Accessibility › Motion; Windows: Settings › Accessibility › Visual effects › Animation effects off) and check that big animations calm down. Look for a pause button on carousels and videos.

11. Captions and transcripts

Videos need captions for speech and important sounds (1.2.2 for pre-recorded video, 1.2.4 for live video at AA). Audio-only content like podcasts needs a transcript. Auto-generated captions are a start, but check that they’re accurate, especially names, numbers and product terms.

How to check: play every video with the sound off. Can you follow it? Are captions in sync and correct?

Common bugs

#	Bug	What you see	Typical severity
1	Field without a label	Screen reader says “edit text” with no name	High (blocks forms)
2	Focus outline removed	Tabbing through the page, you can’t tell where you are	High
3	Custom control not keyboard operable	A div “checkbox”, dropdown or button that Tab skips or Enter/Space ignores	Critical when it blocks a key flow
4	Low text contrast	Light grey hints, placeholders, white on yellow	Medium
5	Error shown only in color	Red border, no message; screen reader says nothing	High
6	Icon button with no accessible name	Screen reader says just “button”	High
7	Missing or bad alt text	File names read aloud, or “image” with no meaning	Medium–High
8	Fake or skipped headings	Big bold text that isn’t a heading; h1 → h4 jumps	Medium
9	Broken layout at 200% zoom	Text cut off, overlapping, content needs horizontal scrolling	Medium–High
10	Focus lost after a dialog closes	Focus jumps back to the top of the page	Medium
11	Auto-playing motion with no pause	Carousel or background video that never stops	Medium
12	Videos without captions	Deaf users can’t follow the content	High

Find the bug

This is the same sign-up page, built the way it often happens in real projects. It has six accessibility bugs. Use the lab tools to find them:

• Tab through the form with Keyboard only and try to create an account.
• Step through it with the Screen reader tool.
• Submit the empty form, then switch on Achromatopsia.
• Use Pick colors from the page on any text that looks faint.

🐞 Bug hunt: GreenBasket sign-up

This demo has 6 hidden bugs. Explore it like a tester, then check your findings.

Found0/6

Keyboard only Blurred vision Zoom 200%Color visionNormal visionProtanopia (no red)Deuteranopia (no green)Tritanopia (no blue)Achromatopsia (no color)

greenbasket.shop/signup

GreenBasket

Create your account

Fresh groceries at your door in 30 minutes.

Full name

Email

Password

At least 8 characters, including a number.

I agree to the Terms of Service

Create account

Already have an account? Log in

Screen reader Contrast

What a screen reader announces, item by item. Use the arrows like swiping on a phone, or Tab through the page.

…

TAB = reachable with the Tab key.

1. 1

   Hint: Step to the first text field with the screen reader tool, or Tab to it.

   The Full name field has no label

   The screen reader announces just "edit text, blank". "Full name" is a plain <div> that only looks like a label, so it is not connected to the input. Fix: use <label for="…">. WCAG 1.3.1 Info and Relationships, 4.1.2 Name, Role, Value (A).

   Reveal answer✓ I found this
2. 2

   Hint: Contrast tab: pick colors from the small text under the Password field.

   The password hint has very low contrast

   Light grey #B4B9C3 on white is about 1.96:1. Normal text needs at least 4.5:1. With blurred vision on, the hint disappears completely. WCAG 1.4.3 Contrast (Minimum), AA.

   Reveal answer✓ I found this
3. 3

   Hint: Keyboard only: Tab through the form. Ignore the numbers. Can the page itself show you where you are?

   No visible focus indicator

   Every focus outline was removed with outline: none and nothing replaced it. A sighted keyboard user has no idea which field they are typing into. WCAG 2.4.7 Focus Visible, AA.

   Reveal answer✓ I found this
4. 4

   Hint: Submit the empty form. Then switch on Achromatopsia, and listen with the screen reader.

   Errors are shown only by a red border

   Invalid fields only get a red border: no message, no icon, no aria-invalid. In greyscale the red border looks just like the normal grey one, and the screen reader announces nothing. The user can't tell what is wrong or how to fix it. WCAG 1.4.1 Use of Color and 3.3.1 Error Identification (A).

   Reveal answer✓ I found this
5. 5

   Hint: What does the screen reader say for the eye icon next to Password?

   The show-password button has no accessible name

   It announces just "button". The icon has no text alternative. Fix: aria-label="Show password" plus aria-pressed to announce its state. WCAG 4.1.2 Name, Role, Value (A).

   Reveal answer✓ I found this
6. 6

   Hint: Keyboard only: fill in every field and try to accept the Terms, then create the account.

   The Terms checkbox cannot be used with a keyboard

   The "checkbox" is a <div> with a click handler. Tab skips it, Space does nothing, and the screen reader reads it as plain text with no role or checked state. Keyboard and screen reader users can never create an account: a blocker. Fix: use a native <input type="checkbox">. WCAG 2.1.1 Keyboard, 4.1.2 Name, Role, Value (A).

   Reveal answer✓ I found this

For the full report structure, see Writing Bug Reports.

Tools and how to use them

Screen readers: a beginner’s cheat sheet

You don’t need to become an expert user, but you should be able to turn one on, move around, and turn it off again. Learn how to turn it off before you turn it on. Start with short sessions and lower the speech rate.

VoiceOver (Mac)VoiceOver (iOS)TalkBack (Android)NVDA (Windows)

Built into macOS. Works best with Safari.

Action	Keys
Turn on / off	Cmd + F5 (or hold Cmd and press Touch ID three times)
Next / previous item	VO + → / ← (VO = Control + Option)
Activate	VO + Space
Rotor (lists of headings, links, form controls)	VO + U, then arrow keys
Stop speaking	Control

Settings › Accessibility › VoiceOver. Tip: set Accessibility Shortcut to VoiceOver so a triple-click of the side button toggles it.

Action	Gesture
Next / previous item	Swipe right / left with one finger
Activate	Double-tap anywhere
Read from the top	Two-finger swipe up
Rotor (headings, links, form controls)	Rotate two fingers like a dial, then swipe up/down
Scroll	Three-finger swipe

Settings › Accessibility › TalkBack. The shortcut is usually to hold both volume keys for 3 seconds (if enabled). Exact menus vary by manufacturer.

Action	Gesture
Next / previous item	Swipe right / left
Activate	Double-tap
Scroll	Two-finger swipe
Change reading control (headings, links, controls…)	Swipe up then down (or three-finger swipe), then swipe up/down to jump
TalkBack menu	Three-finger tap, or swipe down then right

Free and open source (nvaccess.org), widely used with Chrome and Firefox. Windows also has Narrator built in (Ctrl + Win + Enter).

Action	Keys
Start	Ctrl + Alt + N (if the desktop shortcut is set up)
Quit	NVDA + Q (NVDA key = Insert by default)
Next item / line	↓
Next heading / link / form field	H / K / F
List of elements	NVDA + F7
Stop speaking	Ctrl

What to listen for on every element: name (“Email”), role (“edit text”, “button”, “checkbox”), state (“checked”, “expanded”, “invalid data”) and value. Custom components need ARIAARIAHTML attributes that tell assistive technology what custom elements are and what state they're in.Open in glossary → to provide these, and ARIA used wrongly can make things worse than no ARIA at all.

Automated checkers

Automated tools are fast and great at catching the obvious issues. Run one on every page you test:

• lighthouseLighthouseA free tool in Chrome DevTools that audits a page's performance, accessibility, SEO and best practices.Open in glossary → (built into Chrome DevToolsDevToolsDeveloper tools built into browsers for inspecting pages, network traffic and errors.Open in glossary →, Lighthouse tab, check Accessibility): gives a score and a list of failed audits. Its accessibility checks use the axe engine.
• axe DevTools (free browser extension by Deque): adds an axe DevTools tab to DevTools with a detailed list of issues, the failing element and how to fix it.
• WAVE (free extension by WebAIM): draws icons directly on the page for missing alt text, contrast errors, empty buttons and the heading structure.
• DevTools Elements › Accessibility pane: shows the computed accessible name, role and ARIA attributes of any element you inspect.

A quick manual routine (about 10 minutes per page)

Example test cases

Checklist

Accessibility test checklist

0 of 15 checked

Copy

• Every interactive element can be reached and used with the keyboard alone
• The focused element is always clearly visible and never hidden behind sticky content
• Focus order follows the visual reading order; dialogs move focus in and back out
• There are no keyboard traps (except modals, which close with Esc)
• Every form field has a visible, connected label (not just a placeholder)
• Errors are described in text, linked to the field and announced to screen readers
• Normal text contrast is at least 4.5:1, large text and UI parts at least 3:1
• Nothing relies on color alone (errors, required fields, links, charts)
• Meaningful images have useful alt text; decorative images have empty alt
• Icon-only buttons have an accessible name
• Headings form a logical outline; link texts make sense on their own
• Content works at 200% zoom and reflows at 320 CSS px without horizontal scroll
• Motion can be paused and respects Reduce motion; nothing flashes more than 3 times a second
• Videos have accurate captions; audio has a transcript
• Key flows were tested with a real screen reader, not only an automated tool

Check your understanding

Quick quiz

0/6 answered · 0 correct

1. 1.Which WCAG level do most laws and company policies require?

   ALevel ABLevel AACLevel AAADNo level, just a Lighthouse score of 90+

2. 2.What is the minimum contrast ratio for normal-size body text at level AA?

   A2:1B3:1C4.5:1D7:1

3. 3.A screen reader announces a field as just "edit text". What is the most likely bug?

   AThe field is disabledBThe field has no label connected to itCThe contrast is too lowDThe page is not responsive

4. 4.Lighthouse gives a page an accessibility score of 100. What can you conclude?

   AThe page meets WCAG AABNo manual testing is neededCThe automated checks passed, but many issues can only be found manuallyDScreen readers will work perfectly

5. 5.Invalid fields only get a red border. Who is affected?

   AOnly blind usersBOnly color-blind usersCColor-blind users, screen reader users, and anyone who can't tell what the error isDNobody, red is universal

6. 6.What is the right alt text for a decorative background swirl?

   Aalt="swirl.png"Balt="decorative image"CAn empty alt attribute (alt="")DNo alt attribute at all

Key takeaways

• Accessibility helps people with permanent, temporary and situational disabilities: about 1 in 6 people, and really everyone.
• WCAG 2.2 level AA is the usual target. Its four principles are Perceivable, Operable, Understandable, Robust.
• The most common failures: missing labels, removed focus outlines, low contrast, color-only errors, missing alt text, unnamed icon buttons and custom controls that ignore the keyboard.
• Test with your keyboard, zoom, a contrast checker, a color filter and a screen reader: VoiceOver, TalkBack or NVDA.
• Automated tools (Lighthouse, axe, WAVE) are a great first pass but catch only part of the problems.
• Report accessibility bugs with the WCAG criterion, the assistive technology used, and the impact on affected users.