The audit is not the decision

A small-business website can have a poor Lighthouse score and still let most visitors call, book or request a quote without friction. It can also show a modest accessibility report while a keyboard user is trapped in the navigation, a screen-reader user cannot identify a form field, or a customer cannot tell which button submits an inquiry.

That is why the choice between Core Web Vitals and accessibility fixes is usually framed incorrectly. Do not ask which category has more warnings. Ask which defect prevents a valuable visitor from completing a real task, and how confidently you know that defect exists.

My practical rule is simple: fix an accessibility barrier first when it blocks a primary journey. Fix performance first when field data shows that slow loading, delayed interaction or layout movement is making the same journey fail for a meaningful share of visitors. If neither condition is true, take the cheaper fix that reduces future risk, then measure the result.

This is a business decision, not a contest between an automated score and a different automated score. It belongs beside the broader question of whether the site generates qualified opportunities, as discussed in Measure Qualified Opportunities First. Use Traceable Revenue to Make Budget Decisions..

Which problem deserves the next hour?

Core Web Vitals are useful, but they are not a complete user-experience score

Google’s current Core Web Vitals measure three specific things: Largest Contentful Paint for loading, Interaction to Next Paint for responsiveness, and Cumulative Layout Shift for visual stability. Google’s recommended “good” thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1, evaluated at the 75th percentile of page views. (developers.google.com)

Those measures are valuable because they describe experiences visitors can feel. A large hero image that arrives late can delay the service area or phone number. A heavy booking widget can ignore a tap. A late-loading banner can move the submit button just as someone clicks it. These are not merely SEO defects.

But a green score does not prove that the site works well. Google says Core Web Vitals are one part of page experience, and its ranking systems still evaluate relevance and many other signals. A fast page with confusing copy, an unusable form or a broken keyboard path remains a bad business asset. (developers.google.com)

The other trap is treating a one-off lab score as reality. INP requires interaction and cannot be measured in a normal lab load in the same way as field data. CLS can also look better in a lab because many lab tools do not capture shifts caused later by interaction. (web.dev) For a small site, that means checking Search Console or PageSpeed Insights field data when available, then testing the actual pages and devices that bring leads.

A practical order for deciding

1. Map the revenue-bearing journey

   Choose the action that matters: call, request a quote, schedule an appointment, buy, or find a location.

2. Test the journey without a mouse

   Use the keyboard, zoom the page, inspect focus, and try a screen reader on the form and navigation.

3. Check real performance data

   Review field data by device and page template, then reproduce the slow or unstable interaction on a representative phone.

4. Rank blockers before warnings

   A defect that stops a visitor completing the journey outranks a low-severity warning that leaves the journey intact.

5. Make the smallest durable repair

   Prefer semantic HTML, labelled controls, reserved image space, lighter scripts and simpler widgets over cosmetic score chasing.

6. Re-test the task and the numbers

   Confirm that the person can complete the task and that the relevant field or test measurement improved.

Automated accessibility warnings need interpretation, not dismissal

The strongest argument for accessibility work is also the reason to distrust audit counts. Automated tools find real, recurring problems quickly, especially missing alternative text, missing form labels, low contrast and empty controls. WebAIM’s 2025 analysis of one million home pages found detectable WCAG failures on 94.8% of them. The most common categories included low-contrast text on 79.1% of home pages, missing alternative text on 55.5%, and missing form labels on 48.2%. (webaim.org)

Those figures should make an owner take accessibility seriously. They should not lead an owner to repair every warning in the order displayed by a browser extension. WebAIM explicitly notes that automated tools have limitations and that the absence of detected errors does not establish accessibility. The W3C likewise says conformance testing requires automated testing and human evaluation, with usability testing recommended as well. (webaim.org)

Practitioners report the same boundary. The UK Department for Work and Pensions says its best automated tools found only around 30% to 40% of a known set of accessibility issues. Deque’s analysis of more than 2,000 audits found automated rules covering 16 of 50 WCAG 2.1 Level AA success criteria, while also finding that common automated issue types can represent a larger share of defects in real audits. The two findings are compatible: automation can catch many frequent defects while still missing important classes of failure. (accessibility-manual.dwp.gov.uk)

For a small business, the implication is concrete. If the audit says a form input has no label, repair it. If it says a decorative image needs alternative text, inspect the context before adding meaningless words. If it reports contrast on a minor footer element while the booking control cannot be reached by keyboard, fix the booking control first.

The numbers change the priority

What a small-business owner should do this week

Start with the pages that carry commercial intent: the service page, contact page, booking flow, product page or location page. Do not begin with the home page merely because it is the page an audit tool opens first.

Run an automated accessibility check, but turn every result into a user task. Can a visitor identify the form fields? Can they move through the controls with a keyboard? Is focus visible? Can they understand an error and recover? Can someone using a screen reader tell what the navigation, buttons and status messages mean? Government service teams recommend combining automated checks with manual testing and assistive-technology testing for exactly this reason. (gov.uk)

Then inspect performance using real evidence. Look for a poor field metric on a page that matters, not a red score on a page nobody visits. If the problem is LCP, start with the main image, server response and render-blocking resources. If it is INP, inspect long JavaScript tasks and third-party widgets. If it is CLS, reserve space for images, embeds and banners. These repairs often improve accessibility too when they remove unnecessary scripts, stabilize controls and simplify the page.

There is one important exception: a visitor-visible speed improvement can still be the wrong first investment if the main conversion path is inaccessible. A fast form that cannot be completed with a keyboard is not an efficient funnel. Conversely, perfect markup will not rescue a page whose booking widget takes so long to respond that mobile visitors abandon it. The right priority is the first failure in the customer’s actual path.