Measured, then fixed. Not estimated.

A client, a tender or a legal requirement says WCAG 2.2 AA and the site does not pass. Automated tools catch perhaps a third of it: contrast measured rather than eyeballed, keyboard navigation with a visible focus indicator, heading structure, form labels and errors, alternative text, reduced motion. The rest needs someone using the site with a keyboard and a screen reader, which is how this is done here.

Usually images, fonts and blocking scripts, in that order, and usually fixable in place within days. Where the slowness comes from a page builder and a stack of plugins, fixing it in place costs more than rebuilding and still ends up slower. You get told which case you are in before spending anything.

Reports generated on a fast laptop over office wifi mean nothing. Everything here is measured on the production build over a throttled connection, before and after, and handed over side by side. Where a number does not improve, that is in the report too, with the reason.

It is not. Public bodies across much of Europe are legally required to meet it, so a supplier who ignores it cannot bid for that work at all. And the same fixes — real contrast, keyboard access, sensible headings, no layout shift — are what make a site usable on a cheap phone in bad light, which describes most visitors.

It depends on what is making the site slow, so the first step is a measurement rather than a quote. Where the cause is images, fonts or blocking scripts, the fix is usually a matter of days and starts around €490, the same as a redesign. Where the slowness comes from a page builder and a stack of plugins, fixing it in place costs more than rebuilding and still ends up slower, and we will say so.

Contrast ratios measured rather than eyeballed, full keyboard navigation with a visible focus indicator, correct heading structure, form labels and error messages, alternative text, and respect for reduced-motion preferences. Automated tools catch perhaps a third of WCAG 2.2 AA; the rest needs someone using the site with a keyboard and a screen reader.

For what is in the code, yes, and it is measured before handover. What cannot be guaranteed is content added later: an image uploaded without alternative text or a PDF that was never accessible will fail regardless of how the site was built. That is why the audit covers how you add content, not only what is there on the day.

Lighthouse performance, accessibility, best practices and SEO, plus Core Web Vitals, measured on the production build rather than a local machine. You get both sets of figures. Where a number does not improve, you see that too, along with the reason.

That is most of this work. It starts with a measurement and an honest assessment, including the case where the site is beyond sensible repair and money is better spent rebuilding. You get that answer before committing to anything.