Testing what you build

1. Why you have to test by hand

Start with the number that decides everything else. Automated accessibility tools find roughly a third of the problems on a page. Different studies land on slightly different figures, but nobody has ever put it near a hundred, and nobody ever will, because most of what goes wrong is a judgement call.

Here is the difference in one line. A tool can tell you an image has no alt attribute. A tool cannot tell you the alt text says "image".

2. The fifteen minute pass

This is the sequence to run on any page, in this order, before you do anything cleverer. The order matters, because each step sets up the next one. Fifteen minutes gets you most of the way on a normal page.

If you only ever do step 2, you are already ahead of most teams. If you can only add one more, add step 4.

3. Testing with a keyboard

Put the mouse out of reach. Not to one side, out of reach, because the habit is stronger than the intention. Then put your cursor in the address bar, press Tab, and start walking.

The keys, and what each one should do

The seven questions to ask as you Tab

1. Can I see where I am, at every single stop? If the focus indicator vanishes even once, that is a finding. This is the most common failure there is.
2. Can I reach everything? Every link, button, field, tab, menu item and custom control. If you can click it with a mouse, you must be able to reach it with Tab.
3. Does the order make sense? It should follow the visual reading order. If focus jumps from the top of the page to the footer and back up, someone has moved things around with CSS.
4. Can I get out of everything I got into? Tab into a widget, then Tab out. If you cannot, that is a keyboard trap, and it can end the session for a keyboard user.
5. Does Escape work where it should? Open every dialog, menu and autocomplete and try to close it with Escape.
6. Where does focus land after something happens? Open a dialog, focus should move into it. Close the dialog, focus should return to the button that opened it. Delete a row, focus should go somewhere sensible rather than to the top of the page.
7. Is there a skip link? Press Tab once on a fresh page load. The first thing should usually be a link that jumps past the navigation.

Things that look fine and are not

• Focus is technically there but invisible. Someone set outline: none and put nothing back. Look carefully at low contrast elements, and at controls sitting on a coloured background.
• A control that only responds to a click. Very common on <div> and <span> elements with a click handler. You will notice because pressing Enter does nothing at all.
• A menu that opens on hover only. There is no hover on a keyboard, and none on a touchscreen either.
• A modal that lets you Tab behind it. Open the dialog, then keep pressing Tab. If the page underneath starts taking focus, the dialog is not modal in any way that matters.
• An off screen menu that is still tabbable. The menu is hidden with transform or a negative position rather than display: none, so focus disappears into a panel you cannot see.

4. Testing with a screen reader

This is the step people skip, because the first ten minutes are genuinely disorientating. Push through that. You do not need to become a proficient user. You need about eight keystrokes, and those eight will find real problems within minutes.

NVDA on Windows, which is free

The NVDA key is Insert by default, and Caps Lock if you choose the laptop layout during setup. It is written as NVDA below.

VoiceOver on a Mac, which is already installed

The VoiceOver keys are Control + Option, written as VO below. Use it with Safari.

The eight things to listen for

1. Does every control have a name? If you hear "button" or "link" with nothing before it, that control is anonymous. Icon only buttons are the usual offenders.
2. Do the images say something useful? Listen for a file name, the word "image", or a long stream of nonsense.
3. Does the heading list make sense on its own? Pull up the elements list or the rotor and read only the headings. It should read like a table of contents.
4. Does the link list make sense on its own? Same trick. Nine links all called "read more" is a finding.
5. Are the landmarks there? Press D a few times. You should hear banner, navigation, main and content information.
6. Do the form fields say what to type? Tab into each one. You should hear the label, the type of field, whether it is required, and any error.
7. Are the states announced? Open a menu. You should hear "expanded". Tick a checkbox. You should hear "checked".
8. Is anything announced that should not be? Decorative images, empty elements and repeated icon labels all add noise nobody needs.

5. Zoom, reflow and text spacing

Three separate checks that people tend to blur into one. They test different things and they break for different reasons.

Zoom to 200 percent

Press Ctrl or Cmd with + until the browser says 200 percent. This is the plain magnification check. Nothing should be cut off, nothing should overlap, and nothing should need sideways scrolling to read.

Reflow at 320 pixels

This is the harder one. WCAG asks that content works in a window 320 CSS pixels wide without a horizontal scrollbar. You can get there two ways. Narrow the browser window until it is about 320 pixels, or zoom a 1280 pixel wide window to 400 percent, which comes to the same thing.

What usually breaks here is a fixed width, a wide table, or a long unbroken string such as a URL or a line of code. Tables and code blocks are allowed to scroll inside their own box. The page is not allowed to scroll sideways. That distinction is the whole criterion.

Text spacing

Some readers increase spacing to make text easier to follow. WCAG says your layout has to survive it. The four values to apply are:

Reading the four values does not tell you much. Watching them land does. Both cards below hold exactly the same words, and at rest they look the same. The one marked fixed height sets a height on the card and on the button, the way a great deal of real code does. The one marked minimum height sets a floor instead and lets the box grow. Tick the box to apply the four values to both.

The button in the fixed height card gets sliced in half by the edge of the box. Not scrolled, not hidden behind anything you could reach. Cut off, with the bottom of the label simply not painted, and that is the failure the criterion is written for. The minimum height card gets taller instead, which is allowed and is the correct answer. Growing is fine. Losing half a button is not.

6. Colour, contrast and motion

The contrast numbers have their own page with a live checker, so this section is only about how to test rather than what the thresholds are. Three quick checks.

• Turn the page to greyscale. Then look for anything you can no longer tell apart. A required field marked only in red, a chart with a colour key and no labels, a selected tab that is only a different shade. If it disappears in greyscale, colour was doing the work on its own.
• Check the things that are not text. People check body text and stop. The border of an input, the icon inside a button, the line on a chart and the focus indicator all need to be visible too, at 3 to 1 against what is behind them.
• Turn on reduced motion and reload. On a Mac it is System Settings, Accessibility, Display, Reduce motion. On Windows it is Settings, Accessibility, Visual effects, Animation effects. Parallax, auto sliding carousels and long transitions should all calm down or stop.

While you are there, look for anything that moves, flashes or plays for more than five seconds without a way to pause it. Motion that starts on its own and cannot be stopped is a failure regardless of how tasteful it is.

7. Automated tools, and what they miss

Use them. They are fast, free and they catch the boring things reliably. Just know what you are holding.

One habit worth building. When a control seems wrong, open the browser inspector, find the accessibility pane, and read the computed name and role. That is exactly what a screen reader will say. It turns an argument about what the code ought to do into a fact about what it does.

8. Testing on a phone

Most people will meet your site on a phone, and a phone screen reader works by gesture rather than by key. It is worth half an hour to learn.

Turn VoiceOver on from Settings, Accessibility, VoiceOver. Turn TalkBack on from Settings, Accessibility, TalkBack. Set up the accessibility shortcut while you are there, because turning a screen reader off again with the screen reader running is a memorable first experience.

Three checks that only show up on a real device:

• Tap targets. Anything you struggle to hit with a thumb is too small. WCAG 2.2 asks for at least 24 by 24 pixels, and around 44 by 44 is far more comfortable.
• Rotation. Turn the phone sideways. The page must work in both orientations unless there is a genuine reason it cannot, such as a piano app.
• Pinch zoom. Try to zoom in. If it refuses, someone has set user-scalable=no in the viewport meta tag. Delete it.

9. Writing a finding up

A finding that nobody can act on is a finding nobody will act on. The same rule applies here as on a building site. Never write "not accessible" on its own. Write what you did, what happened, and what should have happened instead.

Severity, so the list can be ordered

Give every finding one of three levels. Teams argue about five level scales and never argue about three.

• Blocker. Someone cannot complete the task at all. A checkout that cannot be reached by keyboard. A form field with no label. These get fixed first, always.
• Serious. The task is possible but painful or confusing. Poor contrast on body text, a heading order that makes no sense, an unlabelled icon in a place with context around it.
• Minor. Annoying rather than blocking. A decorative image that gets announced, a redundant link title.

One more habit that changes how a report is received. Alongside the failures, note two or three things the team already got right. It is honest, it is useful, and a report that is only bad news tends to get read once and filed.

10. A test record sheet

Print this and fill one in per page you test. It is the digital twin of the field sheet on the measuring page, and it exists for the same reason. Notes made at the time beat memory made later, every time.