Accessibility & Standards

Accessibility Audit

Definition

An audit is not a score out of a hundred. It names a standard and a level — usually WCAG 2.2 at level AA — picks a representative sample of pages, and records each failure against the criterion it breaks, with a location, a severity and a suggested fix. The automated half runs a rule engine such as axe-core, Lighthouse, WAVE, Pa11y or IBM Equal Access over the markup, which reliably finds missing alt attributes, empty links, low contrast pairs and invalid ARIA. The manual half is where most real problems surface: a keyboard-only pass through every interactive element, a screen reader pass, a read at 400 per cent zoom, a check that errors are announced and that focus goes somewhere sensible after a dialog closes. Published figures put automated coverage at roughly a third of WCAG issues, and the WebAIM Million survey has found detectable failures on around 95 per cent of home pages in every year it has run.

Why It Matters

The gap between a clean automated report and an actually usable page is where most of the money goes. A tool cannot tell you that the alt text says 'image1.jpg', that the tab order jumps from the footer back to the header, or that the modal traps nobody and dumps focus at the top of the document — all of which stop a real person cold. Audits also front-load cost: fixing a heading structure on a five-page site is an afternoon, fixing it after it has been templated across 200 pages is not. If a buyer or a regulator asks what you conform to, an audit is the evidence behind whatever you answer.

How It Works

Start by fixing scope: which standard, which level, which pages, which browser and assistive technology combinations. Sample by template rather than by page — one of each layout, plus every step of any journey that ends in a form — since 40 pages built from four templates contain four sets of problems. Run the automated pass first to clear the noise, then work manually: unplug the mouse and tab through, turn on NVDA with Firefox or VoiceOver with Safari and listen to a full page, zoom to 400 per cent, and submit every form wrong on purpose. Record each finding as the criterion number, the level, where it occurs, what a user experiences and what to change, then retest after the fixes rather than assuming. Worth saying plainly: 99helpers serves your files unchanged and does not scan or audit what you publish, so the testing happens in your browser and your tooling before upload.

Real-World Example

A small agency audits a six-page static site before publishing it at agency-site.99helpers.site. Lighthouse reported 98 and flagged two contrast pairs. The manual pass found four more serious problems the scanner could not see: a logo with alt text reading 'logo', a carousel unreachable by keyboard, a contact form whose error messages appeared silently, and a skip link that focused an element with no tabindex. Fixing those took a morning; the site preview was retested before the final upload, and the contrast pairs turned out to be the least of it.

Common Mistakes

  • Treating a green Lighthouse score as conformance — the engine tests what can be tested from the markup, which leaves the majority of WCAG criteria untouched
  • Auditing one page and generalising — problems live in templates and components, so a sample that misses the form layout misses the form bugs
  • Filing findings as a flat list of tool output with no criterion, severity or user impact — developers then fix the cheapest items first and leave the blocking ones in place

Related Terms

Put a file online in seconds

Drop in a document, an image, a page or a whole static website and share the link — free, with no build step and no server to set up.

Host a file free →