Guide
Performance and accessibility as one workstream
They are usually run as separate projects by separate people at separate times. They share most of their causes, most of their fixes and all of their failure mode, which is drift.
Performance and accessibility as one workstream
Most organisations treat these as unrelated. Performance is an engineering concern with a dashboard; accessibility is a compliance concern with an audit. They get separate budgets, separate specialists and separate remediation projects, usually eighteen months apart.
That separation is expensive, because the two share more than they differ. Both are properties of the rendered page rather than features in a backlog. Both are cheap when designed in and punitive when retrofitted. Both decay silently under normal development. And both are fixed in the same place — the shared components — rather than page by page.
Neither of these is a project you finish. They are properties you hold, and anything you cannot measure in the pipeline you will lose within two quarters.
Chapter 01
The causes overlap more than the disciplines admit
Walk a slow, inaccessible page and the same handful of decisions keeps appearing on both lists.
| Decision | Performance effect | Accessibility effect |
|---|---|---|
| Custom component instead of a native control | Ships more JavaScript, delays interactivity | Usually loses keyboard operability and semantics |
| Text rendered as an image | Larger payload, another request | Unreadable to a screen reader, breaks at 200% zoom |
| Layout that shifts after load | Directly measured as cumulative layout shift | Moves the target someone was about to press |
| Third-party script added by a tag manager | Occupies the main thread, delays input | Frequently injects unlabelled, untabbable interface |
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.
Chapter 02
Measure the same way: distribution, not a score
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.
Chapter 03
Budgets, for both
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.
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.
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.
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.
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.
Chapter 04
Fix components, not pages
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.
Chapter 05
Where the legal floor sits, and why it is not the target
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.
FAQ
Questions this guide gets asked
Which should we do first if we can only fund one?
Accessibility, on cost grounds rather than moral ones. Its retrofit penalty is much steeper: performance problems can usually be attacked incrementally against a running product, whereas an inaccessible component system has to be reworked wherever it was used. If a deadline under the European Accessibility Act applies to you, the question answers itself.
Can our existing team do this without specialists?
Largely, yes, and that is the better outcome. Both disciplines are mostly a small number of repeated patterns rather than deep expertise, and once the accessible versions of your components exist the marginal cost of doing it right is near zero. What outside help is genuinely useful for is the first diagnosis and the initial component pass.
Will this hurt our design?
Occasionally it constrains a specific decorative treatment, and almost never the design as a whole. The conflicts that arise are usually with low-contrast text over imagery and with animation that ignores the reduced-motion preference. Both have solutions that keep the intent, and both are easier to resolve in design than after implementation.
Contact
Have a project in mind?
Tell us what you are building — or what keeps breaking. You will get a considered reply from an engineer, not an autoresponder.