Hearing Is Not Seeing: Why Screen Reader Testing Still Goes Wrong in UK Web Teams

Web Sighted takes its name from a simple but uncomfortable truth: most web teams still judge accessibility by what they can see. Automated scans, visual QA and sighted walkthroughs have their place, but they cannot tell you whether a page makes sense when it is spoken aloud at speed by a screen reader. In 2026, that gap remains one of the most persistent weaknesses in UK digital delivery.

The problem is not usually malice or neglect. It is an assumption. Teams assume that because a page looks orderly, because the heading structure appears sensible in the CMS, and because an automated tool reports few errors, the experience must be broadly usable. That assumption is the 'Sighted' trap. It confuses visual order with navigable order, and it treats compliance as though it were the same thing as comprehension.

The visual audit trap

Automated testing is useful for catching certain failures: missing alternative text, low contrast ratios, duplicate IDs, some ARIA misuse. It is fast, repeatable and inexpensive. But it cannot judge whether a link label makes sense when read out of context. It cannot tell you whether a custom donation widget traps keyboard focus. It cannot explain why a screen reader user gives up halfway through a form because the error message appears visually beside a field but is never announced.

Sighted QA has a similar limitation. A designer can tab through a page and see the focus ring move. A developer can inspect the DOM and confirm that ARIA attributes are present. Neither experience replicates the cognitive load of listening to a page, building a mental model of its structure, and navigating by headings, landmarks and form controls. Accessibility is not only about whether an interface can be operated. It is about whether it can be understood under the conditions in which disabled people actually use it.

What assistive technology reveals

Screen reader testing exposes the distance between the page as authored and the page as experienced. A visually hidden heading may be technically present but announced in a confusing order. A cookie banner may be keyboard accessible but interrupt the reading order on every page load. A charity donation form may look clear, yet announce 'edit text, blank' without the label that tells the user whether it is asking for a title, a card number or a Gift Aid declaration.

These are not edge cases. They are ordinary failures on ordinary websites, including sites run by UK public bodies, charities and membership organisations. The common factor is rarely a lack of technical skill. It is a lack of direct exposure to assistive technology users and the strategies they employ. Teams learn to test what they can see, and then mistake that for the whole of accessibility.

A low-cost route to blind and low-vision testers

The idea that user testing with disabled people is expensive is often overstated. It can be, if an organisation procures a large agency research project with recruitment, incentives, transcription and analysis. But a small, focused round of screen reader usability sessions is achievable for many UK organisations without a six-figure budget.

Start with local and national sight loss organisations. RNIB Connect communities, Thomas Pocklington Trust, local sight loss councils, Henshaws and regional societies for blind and partially sighted people can help you understand appropriate routes to recruitment. Do not ask them to provide free labour. Pay participants at a fair market rate, cover their time and expenses, and be explicit about what the session involves. A modest incentive is nearly always cheaper than rebuilding a broken service journey after launch.

Remote sessions can reduce travel barriers and make it easier to recruit people across the UK. Use the participant's own device and assistive technology where possible, because that reflects real use far better than a lab setup with unfamiliar equipment. Obtain informed consent for recording, store recordings securely, and give participants the right to withdraw. Avoid simulation exercises in which sighted team members wear blindfolds or use screen readers for the first time and call it user testing. That is training, not research.

Running a screen reader usability session: a practical checklist

A useful session does not need to be elaborate. It needs to be focused, respectful and observed carefully. The following checklist is a reasonable starting point for a UK web team running its first round.

• Define three to five realistic tasks, not a tour of the whole site. For a charity, that might mean finding eligibility criteria, making a donation, signing up for an event or downloading a policy document.
• Recruit three to five participants with relevant lived experience. A small sample is not statistically representative, but it will expose repeated barriers quickly.
• Ask participants to use their own screen reader, browser and device where possible. Note the combinations, because behaviour varies.
• Brief the participant in plain English. Explain that you are testing the website, not them, and that they can stop at any time.
• Use a neutral moderator. Avoid rescuing the participant too quickly. Observe where they hesitate, backtrack or ask for help.
• Ask for a running commentary if the participant is comfortable with it, but do not insist. Some people prefer to work silently.
• Record the session with consent, and take timestamped notes on keystrokes, announcements, focus order and points of confusion.
• Do not rely on a single session. Compare notes across participants and separate one-off preferences from recurring barriers.
• Debrief promptly, agree which issues are genuine blockers and assign owners. A report that sits unread is not testing.
• Pay participants promptly and tell them what changed as a result of their involvement.

Making it routine

The wider lesson for UK web teams is that screen reader testing should not be a one-off audit before launch. It should be part of the delivery cycle, alongside content design, front-end review and automated checks. That means building a small panel of disabled testers, budgeting for their time, and treating their findings as product requirements rather than optional extras.

Web Sighted is not suggesting that every organisation must run a formal research programme. But every organisation can stop pretending that a visual walkthrough is the same as an accessibility test. The name of this site is a reminder, not a compliment. If a team only tests what it can see, it will keep missing what disabled users hear.