Core Web Vitals: what each metric measures and how to fix it
LCP, INP and CLS measure different failures with different causes. Knowing which metric is failing tells you almost exactly where to look.
ZooBieDoo Infotech Engineering TeamRead
Key takeaways
- Automated tools find a portion of issues; manual testing finds the rest.
- Prioritise by whether a defect blocks, impedes or merely degrades.
- Most failures cluster in a small set of recurring patterns.
- Without pipeline checks and editor guidance, remediation decays.
Audit properly before planning
Automated tools identify only a portion of real barriers — typically contrast, missing alternative text and some structural issues. They do not tell you whether a journey can be completed with a keyboard or whether a screen reader announces something coherent.
A useful audit combines an automated pass across representative templates with manual testing of the critical journeys, using keyboard only and at least one screen reader.
Prioritise by user impact
Not every failure is equal. A form that cannot be submitted with a keyboard blocks a task entirely; a slightly low-contrast caption is a degradation. Rank findings by whether they block, impede or degrade, and fix in that order.
Journeys matter more than pages. Fixing every issue on the homepage while leaving the checkout unusable helps nobody.
The recurring offenders
- Interactive elements built from
divandspanwith no keyboard handling or role. - Focus states removed for visual reasons, leaving keyboard users lost.
- Form inputs without programmatically associated labels.
- Modals that do not trap focus or return it on close.
- Images carrying meaning with empty alternative text, and decorative images with verbose descriptions.
Prevent regression
Remediation without prevention decays. Add automated accessibility checks to the pipeline so obvious regressions fail the build, and add keyboard operation to the definition of done for interactive components.
Then address content. Editors add images, links and headings daily, so editorial guidance and a well-configured editor do more for long-term compliance than any single audit.
Documenting conformance honestly
Organisations increasingly need to state their accessibility position publicly or in procurement responses. An accessibility statement should say which standard you work to, what is conformant, what is not yet, and how someone reports a problem.
Claiming full conformance when known issues exist is worse than acknowledging them with a remediation timetable. Procurement teams and disabled users both respond better to an honest statement with dates than to an unsupported claim.
Keep it current. A statement dated three years ago signals that accessibility stopped being maintained, which is usually an accurate signal.
Frequently asked questions
It depends on jurisdiction and sector. Public bodies in many countries are bound by it, and private organisations increasingly face accessibility obligations. It is also referenced routinely in procurement, which makes it a commercial requirement even where it is not a legal one.
It depends on how the site was built. Sites using semantic HTML and a consistent component library are usually inexpensive to bring up to standard. Sites built from bespoke interactive widgets can require substantial rework.
They are widely criticised by disabled users and do not fix underlying markup problems. They can also introduce new barriers. Fixing the source is the durable answer.
