Case study 01 · Education organisation

30+ pages, one clear fix list

An education organisation wanted to know, page by page, whether everyone could use its online service. We tested it the way people use it and handed the team a plan it could act on.

Three students crowd around one laptop in a library while one of them types and the other two lean in. Three people, one screen, three opinions about where the menu should go.

At a glance

BuzzBronco audited an education organisation’s online service against WCAG 2.2 Level AA. We tested more than 30 pages, before and after sign-in, in light and dark modes, using a screen reader, keyboard only and dictation software. The team received three reports and a fix list ordered by impact on users.

30+ pages

tested before and after sign-in, in light and dark modes

3 methods

screen reader, keyboard only and dictation software

3 reports

findings, a developer fix guide and a copy review

What did the organisation need?

The organisation runs an online service with public pages and a signed-in area. Accessibility sits at the centre of what it stands for, so the team wanted proof, page by page, that everyone could use the service. They also wanted a site that explains its offer well enough to turn visitors into sign-ups.

How did we test the service?

We ran automated scans first to catch the obvious problems. Then we tested by hand, the ways many people move through a site:

  • Screen reader: listening to every page as a blind user hears it
  • Keyboard only: reaching every link, button and form field without a mouse
  • Dictation software: controlling the site by voice

We tested more than 30 pages against WCAG 2.2 Level AA, in light and dark modes, before and after sign-in. We rated each finding by its effect on users: Critical, Serious, Moderate or Minor. In parallel, we reviewed the website copy for plain, clear language.

What did we find?

We found issues in 7 of the 8 core accessibility areas we checked.

  • Critical: barriers in keyboard use, forms and page structure. Many came from missing standard building blocks, such as real buttons, links and headings, that assistive technology depends on.
  • Serious: low contrast, such as grey text and icons on grey backgrounds, and links that users struggled to recognise.
  • Minor: repeated text that makes a screen reader announce the same label twice, and letters clipped at the bottom, which hurts readers with low vision.
  • What passed: the video content met every criterion.

How does the team close the gaps?

We ordered the fix list so each hour of developer time reaches as many users as possible:

  1. Shared parts first. Headers, footers, menus, forms and repeated cards. One fix here reaches many pages.
  2. Busiest pages and key journeys next. The home page, sign-in and contact forms.
  3. Contrast and content clarity.
  4. Cosmetic items last, during routine updates.

What did the client receive?

  • A high-level findings report for decision makers
  • A developer fix guide with exact fixes, for their own team or any developer they choose
  • A website copy review, so the accessible site also sells the offer

Want the same clarity for your site?

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 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.

Case study 03 · Mission-driven service

What real users found that scans missed

An expert audit plus five sessions with assistive technology users, giving the team evidence its partners trust.