Key Takeaways
- A load test measures how your servers behave under traffic. It cannot tell you whether a page is accessible, and there is no standard “accessibility metric” you can read off a load test.
- Performance and accessibility do meet in a few places that WCAG 2.2 names: time limits (2.2.1), moving content (2.2.2) and status messages (4.1.3). Those are worth testing under load.
- Automated checks cover only part of accessibility. axe-core’s README says it finds on average 57% of WCAG issues automatically, and Lighthouse lists ten checks it leaves to manual testing.
- Run accessibility checks next to your performance tests in the same pipeline, not inside the load generator.
Can performance testing measure accessibility?
No, not directly. Response time, throughput, error rate and percentiles describe a system’s speed and capacity. Accessibility describes whether people can perceive, operate and understand the page with a keyboard, a screen reader, zoom or voice control. A load test that sends HTTP requests never renders the page, so it cannot see a missing label, a keyboard trap or poor contrast. Earlier versions of this post listed metrics such as “ARIA role processing latency” and “time to interactive for screen readers”. Those are not defined by WCAG, Lighthouse or axe-core, and no tool reports them, so they are gone from this version.
What performance testing can do is tell you when the conditions that break accessible behaviour are present: slow responses, timeouts and errors. That is the honest overlap, and the rest of this post stays inside it.
Where performance and accessibility actually meet
WCAG 2.2 (a W3C Recommendation since 12 December 2024) contains success criteria that depend on timing and on what the page does when something goes wrong. These are the ones a performance engineer can influence.
| WCAG 2.2 criterion | What it asks | Why load matters |
|---|---|---|
| 2.2.1 Timing Adjustable (Level A) | If content sets a time limit, the user can turn it off, adjust it or extend it, with listed exceptions | Short session or form timeouts hit hardest when responses are slow, because a user who needs more time to read or type loses the form |
| 2.2.2 Pause, Stop, Hide (Level A) | Moving, blinking or scrolling content that starts automatically and lasts more than five seconds needs a way to pause, stop or hide it | Loading spinners and animated placeholders that stay on screen under load can turn into this case |
| 4.1.3 Status Messages (Level AA) | Status messages can be programmatically determined through role or properties, so assistive technology can present them without receiving focus | The messages that appear under load, such as “still loading”, “retrying” or an error banner, must be announced, and they appear far more often when the system is slow |
| 2.3.3 Animation from Interactions (Level AAA) | Motion triggered by interaction can be disabled unless essential | Heavy animation also costs CPU on weak devices, so cutting motion helps both |
(Source: WCAG 2.2, w3.org/TR/WCAG22/, read 23 October 2026.)
The practical test is a degraded-state check. Put the system under realistic load, then use the application like a keyboard and screen reader user would and look at what you get. Does the loading state announce itself? Does an error message reach assistive technology? Does a session timeout offer a way to extend it, or does it silently drop the user’s work? None of this produces a number from the load test itself. It is a manual or scripted functional check that runs while the load is on, and it needs a person to judge the result.
What automated accessibility checks do and do not cover
Two tools do most of the automated work, and both are open about their limits.
axe-core is an open-source rules engine that you can run inside your existing functional tests with axe.run(). Its README says it finds “on average 57% of WCAG issues automatically” and returns elements as “incomplete” when a human has to review them (github.com/dequelabs/axe-core, read 23 October 2026).
Lighthouse scores accessibility as a weighted average of pass or fail audits, with weights taken from axe user-impact assessments. One unlabelled button fails the whole button-name audit, with no partial credit. Its page lists manual checks that never enter the score, among them logical tab order, trapped focus, whether focus moves to new content, and whether custom controls have ARIA roles and labels (developer.chrome.com/docs/lighthouse/accessibility/scoring, read 23 October 2026).
The consequence is simple. A perfect Lighthouse accessibility score does not mean the page is accessible, and a score that only moves when someone fixes a markup issue says nothing about what happens under load. Treat automated results as a regression alarm, and keep keyboard and screen reader testing in the plan. For tool options, see the roundup of website accessibility testing tools.
How to run accessibility checks next to your performance tests
This is a suggested workflow, not a product feature of any tool named here.
- Keep the jobs separate. Run axe-core or Lighthouse accessibility audits in the functional or browser test stage of your pipeline. Run load tests in their own stage. A load generator should spend its capacity generating load.
- Pick the same key journeys for both. Sign-in, search, checkout or whatever your load scenarios already cover. Accessibility defects in a page nobody reaches matter less than in the checkout.
- Check degraded states on purpose. While a load test runs against a test environment, run one scripted browser session through the journey and scan it with axe-core. Look at timeouts, error banners and loading states, the places where 2.2.1 and 4.1.3 bite.
- Track the accessibility score as a trend, not a gate. Lighthouse’s accessibility category can be tracked over time. LoadFocus page speed monitoring runs scheduled Lighthouse audits that capture the Performance, SEO, Accessibility and Best Practices categories plus Core Web Vitals (loadfocus.com/page-speed-monitoring, read 23 October 2026), so a drop in the accessibility category shows up in the same history as your speed regressions.
- Keep a manual pass. Before a release, a person tabs through the main journey and listens with a screen reader. No score replaces it.
Related performance work still applies to everyone, including users on slow connections or older devices: see how network latency affects load test accuracy, the practices in spike testing and endurance testing, and monitoring Core Web Vitals with alerts.
Why is this on the roadmap in 2026?
Law is part of the reason. The European Accessibility Act, Directive (EU) 2019/882, applies from 28 June 2025 to a range of products and services, including e-commerce. The European Commission’s digital strategy site put it plainly on 27 June 2025: “On June 28, the European Accessibility Act (EAA) enters into application in the EU” (read 23 October 2026). In practice the technical benchmark most guides point to is EN 301 549, which refers to WCAG for web content, so check the current status of the harmonised standard for your market. This is not legal advice. WCAG 2.2 is the current W3C Recommendation, so it is the sensible target for new work.
Frequently Asked Questions
What are accessibility metrics in performance testing?
There is no standard set. WCAG 2.2 defines success criteria that you pass or fail, and Lighthouse turns a subset of automated checks into a weighted score. A load test reports speed and capacity numbers. Combine the two views rather than expecting one tool to produce both.
Can a load test find accessibility problems?
Not by itself. It does not render the page, so it cannot see labels, focus order or contrast. It can create the slow or failing conditions under which you then check status messages, timeouts and loading states.
Does a high Lighthouse accessibility score mean my site is accessible?
No. The score covers automated audits only, and Lighthouse lists manual checks, such as tab order and focus handling, that do not affect it. axe-core’s own README estimates 57% of WCAG issues are found automatically.
Which WCAG criteria relate most to performance?
2.2.1 Timing Adjustable, 2.2.2 Pause, Stop, Hide, and 4.1.3 Status Messages. They deal with time limits, moving content and messages that appear while a page is working or failing.
Should accessibility tests run inside the load generator?
No. Keep them in the functional test stage and run a separate browser check while load is applied if you want to see degraded states.
Sources
Read on 23 October 2026.
- Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation: the success criteria quoted above.
- axe-core README: the “on average 57% of WCAG issues” figure and what the engine checks.
- How the Lighthouse accessibility score is calculated: weighted pass or fail audits and the manual checks outside the score.
- European Commission, “The EU becomes more accessible for all”, 27 June 2025: the European Accessibility Act entering into application on 28 June 2025.
- LoadFocus page speed monitoring: scheduled Lighthouse audits and the accessibility category over time.
Published with PostNext
