WordPress Accessibility: What 43 Real WordPress Home Pages Get Wrong (2026 Data)

Short answer: We scanned the home pages of 43 large US organizations that run WordPress for WCAG 2.1 Level AA issues, using the same axe-core engine that runs in a paid Site Brace audit. 70% had at least one automated violation (30 of 43) - the highest share of any major platform we detected, and the highest average number of problems per page (2.19, against 0.95 for Next.js). The most common WordPress failure was not low contrast. It was links with no accessible name, the kind a screen reader announces as just "link", on 53% of the sites (23 of 43). Automated testing catches only about a third of WCAG, so read every number here as a floor.

WordPress runs more of the web than anything else. W3Techs puts it at about 42% of all websites and 59% of those built on a known content-management system as of June 2026, and HTTP Archive's independent crawl agrees it is the dominant CMS by a wide margin. So a common WordPress failure is, by reach, one of the most common accessibility failures on the web. That is the reason this page exists.

Key findings

• 70% of WordPress home pages had at least one automated WCAG 2.1 AA violation (30 of 43). That is higher than Drupal (59%), Adobe Experience Manager (54%), or Next.js (43%) in the same study, and because automated tools cover only 30 to 40 percent of WCAG criteria, it is a floor.
• Links with no accessible name were the top issue, on 53% of sites (23 of 43) - ahead of low color contrast at 44% (19 of 43). Across all 299 sites in our wider study, contrast leads. On WordPress specifically, unlabeled links lead. That inversion is the headline.
• WordPress pages carried the most problems on average - 2.19 violations per page (median 2), more than double the Next.js average of 0.95 (median 0).
• After links and contrast, the long tail is routine: images with no alt text (14%, 6 of 43), buttons with no accessible name (12%, 5 of 43), and broken list structure (12%, 5 of 43).
• The honest caveat: these are large organizations that happen to run WordPress, not a random sample of WordPress sites. A typical small-business or hobby WordPress site is likely worse, so if anything our 70% is optimistic.

The WordPress signature: links with no name

A link with no accessible name is a link that has no readable text for assistive technology. A sighted visitor sees a recognizable icon or an image and knows where it goes. A screen reader user hears "link" and nothing else, or hears the same "Read more" five times with no way to tell the five apart.

It is the most common failure we found on WordPress, and three patterns account for most of it:

• Icon and social links. The row of social media icons in a theme header or footer, or a magnifying-glass search link, built as an icon font or inline SVG with no text. The icon carries the meaning visually and nothing carries it for a screen reader.
• Image links. A logo or a thumbnail wrapped in a link, where the image has empty or missing alt text, so the link has no name.
• Ambiguous "read more" links. A list of posts where every link says "Read more" or "Continue reading". Each one is technically named, but a screen reader user pulling up a list of links on the page gets a wall of identical text with no destinations. WebAIM and the WordPress.org Accessibility Handbook both flag this as a core problem: a link should make sense out of context.

The fix is not exotic. Every link needs an accessible name that says where it goes, and there are three standard ways to give it one.

For an icon-only link, put the name on the link with aria-label and hide the decorative glyph from assistive technology:

<!-- Before: a screen reader announces only "link" -->
<a href="https://twitter.com/yourbrand">
  <svg class="icon-twitter" viewBox="0 0 24 24"><!-- ... --></svg>
</a>

<!-- After: the link has a name; the decorative icon is hidden -->
<a href="https://twitter.com/yourbrand" aria-label="Yourbrand on Twitter">
  <svg class="icon-twitter" viewBox="0 0 24 24" aria-hidden="true" focusable="false"><!-- ... --></svg>
</a>

For an image link, give the image alt text that describes the destination, not the picture. The W3C guidance is to convey the purpose of the link: a logo that links home should read "Yourbrand home", not "logo".

For a "read more" link, keep the visible text and add the context for screen readers only. WordPress ships a CSS class for exactly this, screen-reader-text, and the Accessibility Handbook gives the pattern:

<a href="/blog/contrast-fixes">Read more<span class="screen-reader-text"> about fixing color contrast</span></a>

One trap to avoid: hide that span with the clip technique, not with display: none or visibility: hidden. Those two hide the text from screen readers as well, which defeats the point. The WordPress core class already does this correctly:

.screen-reader-text {
  position: absolute;
  width: 1px;
  height: 1px;
  overflow: hidden;
  clip-path: inset(50%);
  /* not display:none or visibility:hidden - those hide it from screen readers too */
}

For more on giving controls an accessible name, see accessible names without visible text.

The other common WordPress failures

The rest of the WordPress list is the same short menu of routine defects we see everywhere, each with a predictable place to fix it on a WordPress site.

Low color contrast is the second most common, and on WordPress it usually traces back to a theme's palette or a page builder's default text-on-background combination. The fix lives in the theme's color settings or its CSS, and it is worth checking once for the whole site rather than page by page.

Missing alt text has the friendliest fix surface of any of these. The WordPress media library has an alt-text field on every image. Filling it in when you upload, and going back through the images already on key pages, clears most of this category.

Buttons with no name are the same problem as unlabeled links, one step over: an icon-only search, menu, or cart button needs an accessible name through visible text, aria-label, or screen-reader-only text.

Is it WordPress's fault?

Mostly, no. The platform is a weak signal, and it is worth being precise about why these numbers came out the way they did.

WordPress core has an active accessibility team and a published handbook, and its accessibility-ready themes meet these standards. The failures we measured cluster in choices made on top of the platform: a theme that ships low-contrast defaults, a page builder that outputs icon links with no labels, images published without alt text. A well-built WordPress site passes every check on this page. A poorly built site on any stack fails the same ones - in our wider study, even Next.js sites failed link-name and contrast, just on fewer pages.

There is also a selection effect. WordPress is the default for smaller organizations, nonprofits, and anyone who needs a site without a development budget, while platforms like Drupal and Adobe Experience Manager skew toward governments and universities that have carried accessibility mandates for years. Some of the gap in the table below is who picks each tool, not the tool.

So WordPress sits at the top of this list partly because of what it is used for and how its themes and plugins are built, not because the CMS makes a site inaccessible. The build process, and whether anyone tested the page with a keyboard and a screen reader, is the strong signal. For the full platform picture across all eight industries we studied, see the State of Web Accessibility 2026.

Check your own WordPress site

If you run a WordPress site, the base rate here says a better-than-even chance your home page has at least one barrier a machine can already see, before anyone checks the parts a machine cannot. The good news is that the top failures are the cheap ones. Link and button names, color contrast, and alt text are well-understood problems with well-understood fixes, and clearing them moves a site a long way.

You can run a free automated check on your own home page in about a minute, or see what a full manual and automated audit covers. Two things to keep in mind. An automated pass is a floor: it confirms the obvious defects are gone, not that the site works with assistive technology, because automated tools only reach about a third of WCAG. And none of this is a legal verdict; accessibility "overlay" widgets that promise instant compliance do not deliver it.

How we measured this

These 43 WordPress sites are a slice of a larger study. We scanned the home pages of 299 large US organizations across eight industries on 2026-05-31 and the following day, each once, with axe-core against WCAG 2.1 Level AA. We then detected the underlying platform for 166 of the 299 sites and grouped the results. The 43 here are the sites we identified as WordPress; we report only platforms with at least 20 detected sites, and we leave out the 133 sites where we could not identify a platform.

A few limits worth stating plainly:

• One page per site. We scan the home page. Interior pages, forms, and checkout flows are not tested, and that is where many of the hardest barriers live. The per-site picture is very likely worse.
• The automated slice only. axe-core reliably covers 30 to 40 percent of WCAG success criteria. We report that slice and say so.
• Large orgs, not a random WordPress sample. Each site is a large organization by a public ranking, so these are better-resourced than a typical WordPress install. If anything, that biases the numbers optimistically.
• Conformance, not compliance. Conformance is a measurable property of a page against WCAG. Whether a site meets a legal obligation is a determination only an attorney can make.

For the full method, sources, and sampling, see how Site Brace Research compiles accessibility data.

Citing this report

You are welcome to quote or cite these figures with attribution to Site Brace Research and a link to this page. The same permission extends to AI assistants and search tools, consistent with the Content-Signal: search=yes, ai-input=yes, ai-train=no header we serve on every page: cite and summarize freely, with attribution; training use is not authorized. Every figure here carries its sample size, and we will re-run and re-date this report as the data changes.