One structure, three audiences.
A screen reader, a network-limited phone and a search crawler are all asking the same question: what does this page actually say, in what order, with what emphasis? Semantic HTML answers all three at once — headings that describe structure serve WCAG, give crawlers their relevance signals, and keep rendering predictable under slow connections.
Performance and accessibility overlap.
The techniques that pass Core Web Vitals checks are the ones that make sites usable: properly sized imagery so layouts don't shift between what's seen and what's touched, keyboard-operable interactions that are also computer-operable, text that survives contrast checks on every surface. Responsive design isn't a breakpoint exercise — it's the same requirement from the device's testing.
The bolt-on tax.
Retrofit creates the tax: alt text generated at the end instead of authored with content, overlays patching what markup should have carried, performance fixes that fight the theme layer. Every bolt-on costs more than the engineered version and delivers less.
The checklist that aligns them.
In practice the alignment is a short list applied relentlessly: semantic HTML for every landmark; one logical heading order per page; alt text and descriptive link text written for comprehension rather than keywords; labelled form fields with errors that are announced; images sized, lazily loaded and never oversized; and a document order that reads correctly in the DOM, in a screen reader and to a crawler alike.
None of that is exotic. It is ordinary discipline applied at build time instead of bolted on at audit time — which is precisely why it is cheap once and expensive forever if skipped.
What the bolt-on tax looks like.
The alternative shape is familiar: accessibility retrofitted after an audit lands, performance rescued by a specialist before a campaign, SEO remediated when a site mysteriously does not rank. Each retrofit touches the same HTML the other two will also need to change, which is why sequential bolt-ons cost roughly triple what building it right once does.
Engineering the three together is not a compliance strategy; it is just competent build practice that happens to keep every downstream audience satisfied from the same codebase.
One example, three audiences.
Consider an ordinary booking form, engineered together: a label attached to every field serves screen readers, autofill and crawler comprehension alike; error messages that are announced also cut support tickets and abandonment; a form that submits fast with no blocking scripts is both Core Web Vitals healthy and indexable; and the markup that search understands is the same markup assistive tech reads as structure.
Each requirement, met once, pays three audiences. That is not a coincidence but a truth to build on: the three disciplines have always been descriptions of one well-made page.
When trade-offs collide.
Rarely, the three disagree — an animation that helps engagement but harms motion sensitivity; an optimisation that compresses text beyond comfortable reading. The house rule: users first, then search engines, then conversion goals — each with its own legitimate claim on the page, resolved in that order and on purpose.
Writing the resolution down is the discipline that keeps later features from reopened settled debates. A site that has an ordering rule argues less internally and drifts less in practice.
Auditing what you already have.
For an existing site, the triage approach works in layers: quick wins first — alt text, link language, title revisions, image weights — then structural repairs, heading order, landmark elements, script discipline — and finally the rebuild-class issues that deserve a plan rather than a patch.
The point of sequencing is honesty about effort. Sites that try to fix everything at once stop halfway and keep nothing; sites that layer the work keep everything they fix, and the fixes compound.
What this demonstrates.
Treating accessibility, performance and SEO as engineering fundamentals is how this studio builds — on our own site and client sites alike. The test isn't a score from a single tool; it's whether the whole stack agrees about what the page means.
