Introduction

Here is the short answer. WordPress core does a great deal of accessibility work for you. It still cannot hand you a WCAG compliant website on day one. No platform can do that.

This is not a criticism of WordPress. It is simply how the rules work. WCAG judges a finished web page. It does not grade the software behind it. Your theme, your plugins, your images and your own words all change the result.

This guide explains what WordPress core gets right in 2026. It shows where the gaps almost always appear. It also covers which laws now apply to you, and how to test your own site this week.

What WCAG Actually Measures

WCAG stands for Web Content Accessibility Guidelines. It is written by the W3C, the group that sets web standards. The guidelines tell you how to build pages that people with disabilities can use. That includes people who are blind, have low vision, are deaf, or cannot use a mouse.

WCAG has three levels. Level A is the floor. Level AA is the level almost every law points to. Level AAA is the strictest, and few sites meet all of it.

The current version is WCAG 2.2. It was published in late 2023 and added nine new success criteria. Most of them help keyboard users and people on phones. Many laws still name WCAG 2.1 Level AA, so meeting 2.2 covers you either way.

Every rule sits under one of four ideas. Content must be perceivable, operable, understandable and robust. In plain terms: people must be able to see or hear it, use it, follow it, and open it in any tool they choose.

The key point is this. WCAG is tested against a live page. A page is made of theme code, plugin output, your images, your headings and your link text. Software alone cannot pass or fail that test for you.

What WordPress Core Gets Right Out of the Box

WordPress core takes accessibility seriously, and it has done so for years. The project has a dedicated accessibility team. It also has written coding standards that every core change must follow.

Those standards now aim at WCAG 2.2 at Level AA. That applies to WordPress core, to the WordPress.org sites, and to the official plugins the project ships. New screens are also expected to follow the Authoring Tool Accessibility Guidelines. Those guidelines push the editor to help you make accessible content, not just be accessible itself.

In day to day use, that work shows up in several places. The admin dashboard can be driven by keyboard alone. Skip links let a keyboard user jump straight to the main content. Form fields in the admin carry real labels, not just placeholder text.

The block editor has improved a lot as well. It warns you when an image has no alternative text. It flags heading levels that jump out of order, such as an H2 followed by an H4. If you are still learning the editor, our guide on how to use the WordPress block editor walks through those tools.

The default themes that ship with WordPress are also built to a high standard. They pass keyboard testing, use sensible heading order, and keep colour contrast within range. So a brand new WordPress site with a default theme and no plugins starts in a strong position. The trouble starts after that.

Where the Gaps Show Up in Real Sites

Almost every accessibility failure on a WordPress site comes from three places. The theme, the plugins, or the content. All three are under your control, not the platform’s.

Themes are the biggest single risk. A theme decides your colours, your fonts, your menus and your buttons. A theme with pale grey text on white will fail contrast rules on every page. A custom drop down menu that only opens on hover will lock out keyboard users.

Plugins add their own markup. Sliders, pop ups, booking forms and cookie banners all inject code you did not write. Many of them ship buttons with no accessible name. Many trap keyboard focus inside a pop up with no way out.

Content is where most errors live. Images with no alternative text. Links that say “click here” or “read more” with no context. Headings used to make text big instead of to give the page a structure. PDF files uploaded with no tagged text inside them.

The scale of this is well documented. An annual survey of the top one million home pages, published in 2026, found that low contrast text appeared on about 84 percent of pages. Missing alternative text appeared on more than half. Unlabelled form fields turned up on roughly half as well. Six error types account for about 96 percent of everything found.

Those six problems are all fixable, and none of them need a developer. They just need someone to look. Our post on how to add accessibility features in WordPress covers the practical side of that work.

The Accessibility Ready Theme Tag Changed in 2026

The WordPress theme directory has a tag called “accessibility-ready”. A theme only earns it after a human review against a set list of checks. Those checks cover keyboard use, skip links, contrast, form labels and heading order.

That tag was updated in May 2026, and the change matters. The old list mixed hard requirements with soft recommendations. The new list drops the soft items. Some recommendations became requirements instead. The result is a shorter list that is far harder to fake.

Every existing theme with the tag now has to be reviewed again. Theme authors were first given until the end of June 2026 to start that process. The deadline was later extended to the end of September 2026 because of the volume of themes. From October 2026, any theme still carrying the tag without a re-review request is removed from the directory.

For site owners, this is useful news. The tag is about to mean more than it used to. If you are choosing a theme this year, filter by that tag first. It will not guarantee a passing site, but it removes a large share of the risk before you start. Our explainer on what a WordPress theme is and how it works explains how much of your front end the theme really controls.

Do You Actually Have to Comply in 2026?

For a growing number of sites, yes. The legal picture has moved quickly, and it is worth knowing where you stand.

In the United States. The Department of Justice set web rules for state and local government bodies under Title II of the Americans with Disabilities Act. The standard named in those rules is WCAG 2.1 Level AA. An interim rule issued in April 2026 pushed the dates back by a year. Larger bodies, serving 50,000 people or more, now have until 26 April 2027. Smaller bodies and special districts have until 26 April 2028.

Private US businesses. There is still no single federal web rule for private sites. That has not stopped the lawsuits. Courts have repeatedly treated websites as places of public accommodation, and WCAG 2.1 AA is the yardstick they reach for.

In the European Union. The European Accessibility Act is already in force. It covers a wide range of consumer services sold online, including e-commerce, banking, ticketing and e-books. If you sell to EU consumers, it applies to you regardless of where your server sits.

Public sector bodies elsewhere. Many countries have their own rules, and most of them point back at WCAG 2.1 or 2.2 at Level AA. The standard is now close to universal, even when the law is not.

How to Check Your Own Site This Week

You do not need a budget or an audit firm to find the biggest problems. You need an hour and a short checklist. Start here.

Unplug your mouse. Press Tab through your home page from top to bottom. You should always see where you are. You should reach every link, button and form field. You should be able to close any pop up with the Escape key. If focus vanishes or gets stuck, you have found a real Level A failure.

Check your contrast. Open your browser developer tools and inspect your body text, your buttons and your link colours. Normal text needs a contrast ratio of at least 4.5 to 1. Large text needs 3 to 1. Pale grey body text is the single most common failure on the web.

Audit your images. Go to Media then Library in your dashboard and switch to list view. Look for images with an empty Alt Text field. Fill in anything that carries meaning. Leave it blank only for images that are purely decorative.

Read your link text out loud. Screen reader users often pull up a list of every link on a page. A list of twelve links that all say “read more” is useless. Write link text that makes sense on its own.

Check your heading order. Each page should have one H1. Levels should step down in order without skipping. This is easy to get wrong when you pick headings for their size rather than their meaning.

Watch out for overlay widgets. Plugins that promise instant compliance with one line of script do not deliver it. They have repeatedly failed in court, and many screen reader users switch them off. Fix the underlying page instead.

Before you change themes, edit theme files or remove a plugin to test a fix, take a full backup or work on a staging copy of your site. Accessibility fixes are usually safe, but theme and plugin changes on a live site never are. The Site Health screen is a good place to confirm the site is stable before and after you work.

So What Is the Honest Verdict?

WordPress core is built to a high accessibility standard and is getting stricter, not looser. The coding standards target WCAG 2.2 Level AA. The admin, the editor and the default themes all reflect that work.

But core is only one layer of your page. The moment you add a theme, a page builder, a form, a pop up or a few hundred images, the result is yours to own. Out of the box, WordPress gives you a compliant starting point. It does not give you a compliant website.

The good news is that most failures are ordinary and cheap to fix. Contrast, alternative text, form labels, link text and heading order cover the vast majority of what any tool will flag. Work through those five and you will be ahead of most sites on the web.

If you want help turning that list into a finished, tested site, our team does this every day. Read more about how accessibility services help businesses reach more users, or see our practical guide on how to improve WordPress accessibility. When you are ready for a hands-on audit and fix, talk to 24×7 WP Support and we will take it from there.

Brian

Brian is a WordPress support specialist and content contributor at 24×7 WP Support. He writes practical, easy-to-follow guides on WordPress troubleshooting, WooCommerce issues, plugin and theme errors, website security, migrations, performance optimization, and integrations. With a focus on solving real website problems, Brian helps business owners, bloggers, and online store managers keep their WordPress sites running smoothly.