Updated 28 September 2026. We re-measured all 88 homepages after finding and fixing errors in our own checker: it had counted some best-practice issues as WCAG failures, and it misread the colours of certain buttons — including two of the examples in the first version of this article. Every figure below is the re-measurement, and we cross-checked it against axe-core. The original figures are listed at the end so you can see what changed.
Web agencies build and look after a large share of the web. So we asked a simple question: how accessible are the websites of the agencies themselves?
We ran an automated WCAG 2.1 AA check on the homepages of 88 WordPress web agencies in the UK, US, Canada, Australia, the Netherlands and Ireland. 80 of them could be scanned. Here is what we found — and what it means if you build or maintain client sites.
Key findings
- 82% of agency homepages (66 of 80) had at least one clear WCAG 2.1 Level A/AA failure — low text contrast, invisible keyboard focus, controls with no accessible name, missing alt text and similar. axe-core, the open-source engine many accessibility tools are built on, found at least one WCAG 2.1 A/AA failure on 88% of the same pages.
- 68% had text that fails the contrast minimum (WCAG 1.4.3) — axe-core: 70%. The median failing site had 3 separate contrast findings.
- 45% had interactive elements with no visible keyboard focus indicator (WCAG 2.4.7).
- 40% had links, buttons or ARIA widgets that a screen reader cannot name properly (WCAG 4.1.2) — axe-core, which runs more of these checks, found 55%.
- 31% failed three or more different WCAG criteria.
- The median automated score was 88/100. 32 of 80 sites scored 90 or higher.
The results in detail
Share of scanned agency homepages (n = 80) with at least one finding for each WCAG 2.1 success criterion:
| WCAG criterion | What it means | Sites affected |
|---|---|---|
| 1.4.3 Contrast (Minimum) — AA | Text colour too close to its background | 54 (68%) |
| 2.4.7 Focus Visible — AA | No visible outline when you Tab to an element | 36 (45%) |
| 4.1.2 Name, Role, Value — A | Buttons/links with no accessible name, focusable content hidden from screen readers, invalid ARIA | 32 (40%) |
| 1.1.1 Non-text Content — A | Meaningful images without alt text, or a file name as alt text | 14 (18%) |
| 1.4.11 Non-text Contrast — AA | Form field borders too faint to see where the field is | 8 (10%) |
| 1.4.4 Resize Text — AA | Viewport settings that block pinch-zoom on mobile | 6 (8%) |
By country, Dutch agencies had the highest median score (92, n = 15), followed by Ireland (91, n = 8), Australia (84), the UK (83), the US (82) and Canada (70, n = 5). The per-country samples are small, so treat this as a hint, not a ranking — but it is interesting given that the European Accessibility Act has applied in the EU since 28 June 2025.
What the failures actually look like
None of these are exotic. They are the everyday patterns that come from page builders, theme defaults and brand palettes that were never contrast-checked:
- Calls to action in the brand colour. One agency's "Client Login", "View our services" and "Get in touch" buttons are white text on a mid-green at 2.63:1. AA requires 4.5:1 for text that size.
- Mid-grey text on a light background. Section labels in #888888 on #f8f8f8 come out at 3.34:1 — close enough to look fine to the designer, not enough to pass.
- Links and buttons with no name (29 sites) — typically a logo link or an icon button. A screen reader announces just "link" or "button", so users can't tell where it goes.
- Hidden but focusable (3 sites). Menus and sliders wrapped in
aria-hidden="true"that still contain focusable links — keyboard users land on elements screen readers can't see. outline: nonewith no replacement (36 sites). Keyboard users lose track of where they are on the page.
Why this matters for agencies
If an agency's own flagship site — usually the one it invests the most care in — has these issues, the same patterns are very likely on client sites built with the same themes, builders and habits. That is increasingly a commercial risk, not just a best-practice gap:
- EU: the European Accessibility Act covers many e-commerce and online services since 28 June 2025, with EN 301 549 referencing WCAG 2.1 AA.
- UK: the Equality Act 2010 requires reasonable adjustments for disabled users, and public sector sites must meet WCAG 2.2 AA.
- US: web accessibility lawsuits under the ADA continue to target businesses of every size.
The good news: most of the failures above are quick fixes — a colour token, an aria-label, a :focus-visible style, an alt attribute. The hard part is noticing them across dozens of client sites, and noticing again when a plugin update or a new landing page brings them back.
Methodology
- Sample: 88 agencies taken from Google search results for "WordPress web design agency" plus a city (London, Manchester, New York, Chicago, Los Angeles, Austin, Toronto, Sydney, Melbourne, Amsterdam, Utrecht/Rotterdam, Dublin), plus a small set of UK and Dutch WordPress care-plan agencies. Directories and ranking sites were excluded. We are not naming agencies — the point is the pattern, not any one company.
- Scanned: 80 homepages on 28 September 2026. 8 could not be scanned because bot protection blocked automated browsers.
- How: each homepage was loaded in headless Chrome at a 1440×900 desktop viewport and checked with the same deterministic rules that power the QA Proof free accessibility checker (no AI involved in the findings). The same pages were also run through axe-core 4.13 as an independent cross-check.
- What counts as a "clear failure": findings mapped to WCAG 2.1 A/AA criteria 1.1.1, 1.4.3, 1.4.4, 1.4.11, 2.4.2, 2.4.7, 3.1.1 and 4.1.2. We deliberately excluded from the headline numbers everything that is advice rather than a WCAG failure: WCAG 2.2 target size, content outside landmark regions, heading order, duplicate IDs, and text whose background could not be determined reliably.
- Limits: homepage only; automated checks catch only part of WCAG, and no automated tool is free of false positives or misses — the two engines above disagree in places. A passing automated scan does not mean a site is accessible — manual testing with a keyboard and a screen reader is still needed.
- What changed on 28 September: the first version (17 September, 73 sites scanned) reported 90% with at least one clear failure, 74% contrast, 64% unnamed controls, 42% invisible focus and a median score of 76. Part of that difference is our checker's errors, which we fixed — it counted some best-practice issues and some invisible elements as failures, and read the colour of a button instead of the colour of its text — and part is simply that sites changed in eleven days.
Check your own site (or a client's)
You can run the same check on any public page in about a minute, with no signup: qaproof.io/free-accessibility-checker. It shows your score, the severity breakdown and the top issues with the exact element and code snippet.
For agencies looking after many sites, the full QA Proof accessibility audit adds every finding, fix guidance and PDF reports you can share with clients — and visual monitoring catches layout breaks after plugin and theme updates.