Performance and accessibility as one workstream

Walk a slow, inaccessible page and the same handful of decisions keeps appearing on both lists.

The practical consequence is that a single review pass finds both sets of problems, and a single fix at component level resolves both. Running them as separate engagements means paying twice to look at the same markup.

A performance score from one synthetic run and an accessibility score from one automated checker share a flaw: both describe a single sample and both invite optimisation of the number rather than the experience.

For performance, that means field data over lab data wherever you have it — your visitors are a distribution and the slow tail is where complaints come from. The diagnosis approach is covered in Core Web Vitals optimisation.

For accessibility, it means accepting that automated tooling catches a minority of real issues. It cannot judge whether a label is meaningful, whether focus order matches the visual order, or whether an error message explains the problem. Those need a person with a keyboard and a screen reader, and no amount of green in a checker substitutes.

The mechanism that makes either of these stick is the same: a threshold in the pipeline that fails a build. Without it, both decay, and they decay invisibly because nothing breaks — the page still works, it is just gradually worse.

1. 01

   Set the thresholds from where you are

   A budget set at an aspirational number fails immediately and gets disabled within a week. Set it just tighter than current reality, then ratchet.

2. 02

   Fail the build, do not warn

   A warning is a notification somebody learns to scroll past. If the threshold is worth having, crossing it should stop the merge.

3. 03

   Run the accessibility checks in the same job

   Not because they catch everything, but because the ones they do catch are regressions in components that were previously correct, which is exactly what a gate is for.

4. 04

   Review what the gate cannot see, on a cadence

   A quarterly keyboard-and-screen-reader pass over the main journeys. This is the part no pipeline replaces.

Both problems repeat because they live in shared code. A custom select that traps focus is not one defect; it is one defect multiplied by every screen that uses it. Remediation reports that list pages rather than components produce long lists of the same underlying cause and encourage fixing the symptom in forty places.

This is why we treat it as implementation work on the component system rather than as an audit followed by a remediation backlog. It is also why the deliverable includes documented patterns: without them, the next feature reintroduces what was just fixed.

A remediation list organised by page is a list of symptoms. Reorganise it by component and it usually collapses to a fraction of its length.

The European Accessibility Act points at the harmonised standard EN 301 549, whose currently referenced version cites WCAG 2.1 AA. That is the binding yardstick today. Build to 2.2 AA anyway — the increment is small and it removes a future migration. The scope tests, including the microenterprise exemption, are set out in the EU compliance guide.

Performance has no equivalent legal floor, which is why it tends to lose budget arguments against accessibility once a deadline exists. That is the wrong lesson to draw. The commercial case for speed is more direct than the compliance case for accessibility: slow pages lose people before they convert, and that is measurable in your own funnel rather than inferred from a regulation.

We do implementation rather than certification, and keep the two separate deliberately. We are not an accredited assessor and do not issue conformance statements — including for our own work, where doing so would be marking our own homework. If you need an independent audit, say so early and we will tell you what to look for in one.