Twenty-four of the 26 SaaS homepages that met all three desktop Core Web Vitals thresholds also had a critical or serious finding in a separate automated accessibility check.

The figures come from Merge Rocks’ SaaS website performance and accessibility benchmark, covering 60 selected public B2B SaaS marketing homepages. Thirty-seven had complete, matched mobile and desktop field records; the 26 desktop passes came from that group.

Google's Chrome User Experience Report (CrUX) supplied rolling records of real visits. Axe checked dated initial page states, and the accessibility count includes a finding on desktop or mobile. The observations were not simultaneous, and this selected panel does not establish a market-wide failure rate.

The overlap shows why a team needs to be precise about what it is approving. Core Web Vitals cover loading, responsiveness and visual stability. A desktop pass provides evidence about those measures. The mistake would be to carry that result into a release discussion as evidence that a visitor can identify and use the page's links.

Writing in the published report, Ihor Ostin, Head of Growth at Merge Rocks, states his priority: “Before I ask a team to bring in more traffic, I want us to understand what happens to the people already arriving.”

“Fixed” needs a meaning too

Across all 60 homepages, Axe flagged serious color-contrast findings on 48 and serious link-name findings on 30. The categories overlap: a homepage can appear in both counts. These are sites with findings, not totals of defective elements.

Those findings invite different decisions. Contrast concerns the relationship between text and its rendered background. A link-name check concerns whether the link has a name that software can expose. Neither result, by itself, describes whether someone completed the intended task.

The study did not test task completion or diagnose the companies' processes. Its counts show how widespread the findings were in this panel. They do not set a repair order for another website.

Ostin describes a prioritization choice in the same report: after an earlier performance project, the team started with the pages attracting the most traffic and those generating sales before extending the work across the site. That was performance work, not an accessibility experiment. Its relevance here is how to choose where to investigate first.

For a page already receiving visitors, the team needs to understand what those people are trying to do and whether the flagged component supports that task. The most frequent warning in a benchmark cannot answer that question.

Consider a hypothetical resource card with a guide title, a muted category label and an arrow leading to the guide. It is an example for examining an acceptance decision, not a card observed in the study.

A local improvement can leave a shared problem

Suppose the card's category label looks readable in the design file but has insufficient contrast in the browser. The design may show a white background while the implementation applies a different surface or opacity. Matching the screenshot more closely would not necessarily resolve the rendered color pairing.

The first decision concerns the reach of the correction. A local CSS change could improve this card while leaving the same shared component unchanged elsewhere. Changing a shared text-color token could reach those other uses, but each background and relevant state still matters. A better pairing here does not establish a better pairing everywhere that token appears.

This is why “the color was changed” is a weak basis for acceptance. It describes an action. The evidence needed concerns the result: the implemented text against its actual background, including the affected states and uses.

A local correction is a defensible stopping point when the agreed work covers this card. Approval of the shared component requires evidence from its other uses.

A link called “Arrow” can leave its purpose unclear

The arrow on the same card creates another distinction. Its placement can make the intended action look obvious to a sighted reviewer. That visual relationship does not automatically give the link an accessible name in the browser.

Giving the link the name “Arrow” might clear a narrow automated name check. The visitor would still need to understand where it leads. The team could close the machine finding while leaving the purpose unclear.

Making the guide title the visible link text may address both questions more directly. It names the resource and gives the link useful wording. Whether that intention survives implementation depends on the actual HTML and what the browser exposes. An ARIA label can replace the visible wording in the accessible name, so adding one without a reason can create a mismatch.

The collected reports also show why reachability and naming deserve separate attention. In a retained desktop scan, Axe flagged a link that was in the keyboard tab order but had no accessible text. The record identifies a naming failure; it does not establish whether someone completed a task.

The useful evidence combines the implemented name with verification of the agreed interaction. Another screenshot or a cleared scan finding cannot stand in for that result. A scan without findings would not establish accessibility conformance either.

Accept the result the work actually demonstrates

The scope of the work determines how far an acceptance decision can go. Merge Rocks’ front-end development service, for example, distinguishes routine browser, device and error-state checks from scope-dependent accessibility targets and full QA. Hiring a development team does not, on its own, define the depth of a website accessibility audit.

For this card, the work could cover a better link name and verification that the link works, or extend to the shared component wherever it appears. Those choices involve different work. They also give the person accepting it different reasons to approve the result.

That distinction belongs in the same conversation as acquisition. Before bringing more visitors to a page, a growth team needs to understand what has been demonstrated about their experience there and what it is still assuming.