Manual testing

Six accessibility checks you can run on your own site with a keyboard

Automated testing measures roughly a third of accessibility barriers. The remainder require human judgement, and they are disproportionately the ones patients raise.

For practice managers and the people who maintain their sites. Reviewed September 2026.

We sell automated audits, so the boundary is worth stating precisely. A scanner can establish that an image carries no alternative text. It cannot establish whether the alternative text is correct. It can confirm a button exists and is named. It cannot confirm that a patient can reach it and operate it.

The six procedures below cover that second category. They need no software beyond the browser you already have, and they take about fifteen minutes on the pages that matter: appointment request, contact, and new-patient forms.

1. Keyboard operability

Disconnect the mouse and complete an appointment request using only Tab to move forward, Shift and Tab to move back, Enter to activate, Space for checkboxes, and the arrow keys inside menus.

Three failures to watch for:

• Focus visibility. A visible outline or highlight should always indicate the element you have reached. Where it disappears, a keyboard user has no way to know their position.
• Focus order. Focus should progress roughly in reading order. Jumps between the header and the footer indicate the DOM order and the visual order have diverged.
• Keyboard traps. Open the mobile menu, a modal, or a date picker, then attempt to leave with Esc or by tabbing out. Content you cannot escape ends the visit.

This single check surfaces more genuine barriers than any other manual procedure, and it takes about four minutes.

2. Text resize to 200 per cent

Press Ctrl and + (Cmd and + on macOS) until the browser reports 200%, then continue to 400%.

Content should not disappear, overlap, or be clipped, and no sentence should require horizontal scrolling. WCAG 2.1 requires resize to 200% without loss of content or function, and reflow at 320 pixels. A meaningful proportion of older patients browse at exactly this zoom level.

3. Error handling in forms

Submit your appointment form empty, then submit it with deliberately invalid input: a phone number in the email field, letters in a date.

A conforming form identifies which field is at fault, what is wrong with it, and how to correct it, in text, adjacent to the field. A red border alone conveys nothing to a screen reader and little to a colour-blind patient. A form that reloads and discards the entered data fails on a further criterion again.

4. Accuracy of text alternatives

Right-click a substantive image, select Inspect, and read the alt attribute. Then ask whether that sentence, read aloud, conveys what the image conveys.

alt="IMG_4471.jpg" passes automated testing, because the attribute is present. So does alt="dentist" on a photograph of a named provider, and alt="image" on the map showing your location. Decorative images should carry alt="", deliberately empty, so assistive technology skips them rather than announcing noise.

5. A screen reader pass

Both major operating systems include one at no cost.

• Windows: Ctrl + Win + Enter starts Narrator. NVDA is free to download and closer to what people use in practice.
• macOS: Cmd + F5 starts VoiceOver.

Without looking at the screen, locate your telephone number, then your opening hours. This is the most instructive fifteen minutes available on your own site, and it reliably produces a sequence of "link", "link", "button", "blank" in places assumed to be sound.

6. Mobile behaviour

On a phone, attempt to pinch and zoom the page. A page that refuses to enlarge has zoom disabled in the site template. That is a direct failure of the standard and among the most consequential in practice, since enlargement is the first thing a patient with low vision reaches for.

While there, attempt the small links in your footer and your social icons. Targets you miss repeatedly will also be missed by a patient with a tremor or arthritis.

What to do with the results

Record each finding as three facts: the page, the action taken, the result observed. Send that to whoever maintains the site. You do not need the technical remedy, and you do not need to cite a success criterion. A developer given a clear reproduction resolves most of these within a day.

Keep the list and the date. If a complaint is ever filed, a record of what was found and what was corrected carries considerably more weight than a vendor certificate.