Case study 03 · Mission-driven service

What real users found that scans missed

A mission-driven organisation needed evidence strong enough to show its partners. We tested its service with the people it serves, and found problems no scan would catch.

A woman with albinism types on the laptop in her lap, sitting between a vase of eucalyptus and a vase of dried flowers. If your text turns to mush when she zooms in, she's gone, and the flowers aren't the only thing drying up.

At a glance

BuzzBronco tested a mission-driven organisation’s web service against every applicable WCAG 2.2 Level A and AA criterion, on five key page templates and the main menu. We ran five moderated sessions with people who use a screen reader, speech input or screen magnification, plus a neurodivergent participant. The written report followed about two weeks after the first test.

5 sessions

with people who use assistive technology every day

66 checks

covering every applicable WCAG 2.2 A and AA criterion

2 weeks

from first test to written report

What did the organisation need?

The organisation runs a web service for people who often rely on assistive technology, read in a second language, or use the service under stress. The team knew that automated scans and internal checks miss the problems that stop real people. They needed findings their external partners would trust.

How did we test the service?

  • Expert audit of every applicable WCAG 2.2 Level A and AA success criterion, 66 checks in all
  • Five moderated sessions with people using a screen reader on desktop and mobile, speech input and screen magnification, plus a neurodivergent participant
  • A review of the translated versions of the site

We chose the five page templates by traffic and use, so the findings landed where most people go.

What did users run into?

50 of the 66 checks showed at least one barrier, and 25 of those involved Level A, the most basic level of the standard. Some users could not complete core tasks.

  • Mouse-only controls. Parts of the main menu and some search functions did not work by keyboard or screen reader.
  • Focus jumping to the top. Choosing a filter sent keyboard users back to the start of the page, so they could not work through it.
  • Hidden page structure. A participant using high magnification missed a whole column of content. A screen reader user described the page as disorganised.

What worked well?

  • Every page had a unique title
  • No keyboard traps and nothing that flashed
  • A screen reader user called the plain-language guidance helpful

How does the team fix it?

We grouped the recommendations by severity (Critical, Serious, Moderate) and gave each one an effort estimate, with a short “where to start” list on top. Most of the critical items sit in shared components, so one fix reaches many pages. The team can hand the list to its developers as it stands.

Why test with real users?

People who use these tools every day did the testing. Their sessions give the team evidence it can put in front of partners, with each problem ranked and a cost attached to each fix.

Want evidence your partners will trust?

Book a 30-minute conversation. We’ll tell you where your site stands and what to fix first. No jargon, no pressure.

More case studies

Case study 01 · Education organisation

30+ pages, one clear fix list

We tested 30+ pages of an education service with a screen reader, keyboard and dictation, then ranked one fix list by impact on users.

Case study 02 · Training programme

From a broken form to a full cohort

We audited a sign-up website, then fixed contrast, labels, navigation and the contact form ourselves.