WordPress Accessibility Guide: Make Your Site Usable for All

WordPress accessibility comes down to four things: choosing a well-built theme, writing content with structure (headings, alt text, descriptive links), picking plugins that output accessible markup, and testing the result with a keyboard and an automated checker. WordPress core itself is built with accessibility in mind, but most problems on real sites come from themes, page builders, plugins and content choices made after installation.

This guide walks through each layer of a WordPress site, what usually goes wrong, and how to fix it, mapped to the WCAG checklist.

Why WordPress accessibility matters

An accessible site works for people using screen readers, keyboards, magnifiers or voice control, and for people with low vision, colour blindness or dyslexia. It also reduces legal risk under rules such as the ADA and the European Accessibility Act.

This article is general information, not legal advice.

Start with an accessibility-ready theme

The theme controls most of your HTML: the header, navigation, skip links, focus styles, colours and page layout. Fixing a badly built theme with plugins is much harder than starting with a good one.

What "Accessibility Ready" means

The WordPress.org theme directory has an Accessibility Ready tag. Themes with this tag have been reviewed against a set of accessibility requirements from the WordPress theme review team, covering things such as:

Visible keyboard focus styles
A working "skip to content" link
Keyboard-operable menus, including dropdowns
Sensible heading structure and labelled form fields

The tag is a useful filter, not a guarantee: changing colours or adding plugins can break what the theme got right.

Checking a theme before you commit

Load the theme demo and press Tab. You should see a skip link, then a clear focus outline moving through the menu and content in order. Our keyboard accessibility guide explains what to look for in more detail.

Accessible content in the block editor

Most issues on WordPress sites are content issues.

Alt text for images

In the block editor, select an Image block and look in the block settings sidebar for Alternative text. You can also set alt text in the Media Library, but note that alt text added in the library is used as a default when inserting an image, and changing it later in the library does not always update images already placed in posts.

Good alt text describes the purpose of the image in context. "Chart showing monthly signups rising from 200 to 900 between January and June" is useful. "image1.jpg" or "chart" is not. Purely decorative images can have empty alt text so screen readers skip them. See how to write alt text for examples.

Headings in order

Use the Heading block, not bold paragraphs, for section titles. Your theme normally makes the post title the H1, so content headings should start at H2, with H3 for subsections. Never pick a level for its size; screen reader users navigate by headings.

Descriptive links

Link text should make sense out of context. "Read our pricing guide" is better than "click here".

Colour contrast and typography

WCAG 2.2 Level AA asks for a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text and for user interface components such as button borders and focus indicators. Pale grey text on white, white text on light brand colours, and text placed over photos are the most common failures.

In block themes, colours are set in the Site Editor under Styles. Check every combination you actually use, including button hover states, links in footers, and placeholder text in forms. Our colour contrast guide covers how to measure and fix ratios.

Element	WCAG AA minimum	Common WordPress problem
Body text	4.5:1	Light grey paragraph text in the theme
Large text (headings)	3:1	Brand colour headings on tinted backgrounds
Buttons and inputs	3:1 for boundaries	Ghost buttons with thin pale borders
Text on images	4.5:1	Cover block text over busy photos

For text in a Cover block, increase the overlay opacity so text stays readable regardless of the image.

Accessible forms with WordPress plugins

Contact, booking and checkout forms are where many users get stuck. Every field needs a visible label tied to the input, clear error messages, and a way to submit with the keyboard.

Contact Form 7

Contact Form 7 gives you direct control over the form markup. That is flexible, but it means labels are your responsibility. Wrap each field tag in a label element or use matching for and id attributes, and do not rely on placeholder text as the only label.

<label>Your email (required)
[email* your-email autocomplete:email]</label>

WPForms and Gravity Forms

WPForms and Gravity Forms both generate labelled fields through their visual builders. With either plugin, avoid hiding labels to save space, write meaningful error messages, mark required fields in text not only with colour, and test the error state with a keyboard.

Avoid visual-puzzle CAPTCHAs. More detail is in our accessible forms guide.

Page builder pitfalls

Page builders such as Elementor, Divi and others make design easy, but they can produce problems that are hard to see visually:

Headings chosen by look, so a page jumps from H1 to H5 or has several H1s
Buttons built from div elements that cannot be reached with the keyboard
Icon-only buttons and social links without accessible names
Tabs, accordions and toggles that do not announce their state

When using a builder, set the HTML tag of each heading widget deliberately, add accessible labels to icon links where the builder allows, and review the page with the keyboard after each major layout change.

Sliders, popups and menus

Sliders and carousels

Auto-rotating sliders move content before it can be read. WCAG requires a way to pause, stop or hide moving content that lasts longer than five seconds. If you keep a slider, turn off autoplay or provide a visible pause button, and make the arrows and dots keyboard-operable with clear labels.

Popups and modals

Newsletter and cookie popups should move keyboard focus into the dialog when opened, keep focus inside while open, close with the Escape key, and return focus to where the user was. A popup that appears on page load and cannot be closed with a keyboard can make the whole site unusable.

Navigation menus

Menus should be reachable and operable with Tab, Enter and Escape. Dropdown submenus should open on keyboard focus or via a toggle button, not only on mouse hover. Mobile hamburger buttons need an accessible name such as "Menu" and should indicate whether the menu is expanded.

Testing your WordPress site

Combine automated and manual testing:

Run an automated scan with a free accessibility checker on your home page, a post, a product or service page, and your contact form.
Navigate each of those pages using only the keyboard.
Zoom the browser to 200% and check that content reflows without overlapping.
Try a screen reader such as NVDA on Windows or VoiceOver on macOS. Our screen reader testing guide explains the basics.
Retest after theme updates, plugin updates and redesigns.

Publish an accessibility statement

An accessibility statement is a page that explains your commitment, the standard you aim for (usually WCAG 2.1 or 2.2 Level AA), known limitations, and how users can contact you if they hit a barrier. Link it from the footer. Be honest about what you have tested rather than claiming unverified compliance.

Using the Openwise WordPress plugin

Openwise offers a free WordPress plugin that adds its accessibility widget to your site without editing theme files. After you add your website in the Openwise dashboard, you can download the plugin from the install code section for that website, then upload and activate it in WordPress under Plugins. The widget gives visitors tools such as larger text, contrast and dark modes, a dyslexia-friendly font, a reading guide, read aloud and pausing animations.

To be clear: a widget helps visitors adjust the page to their needs, but it does not fix missing alt text, broken heading structure, unlabeled forms or keyboard traps. Those must be fixed in your theme, plugins and content. We explain this in more depth in the truth about accessibility widgets.

Frequently asked questions

Is WordPress accessible out of the box?

WordPress core and its default themes are developed with accessibility in mind, and the admin area is designed to work with keyboards and screen readers. However, the accessibility of your public site depends heavily on your theme, plugins, page builder and content, so a fresh install can quickly become inaccessible if those are not chosen and used carefully.

Does an Accessibility Ready theme make my site compliant?

No. The Accessibility Ready tag means the theme passed a review of specific requirements at the time it was tagged. Your colour changes, content, plugins and customisations can all introduce new barriers, so you still need to test the finished site against WCAG.

Which WordPress form plugin is most accessible?

Contact Form 7, WPForms and Gravity Forms can all produce accessible forms when configured carefully. What matters most is that every field has a visible, programmatically associated label, errors are announced clearly, and the form can be completed with a keyboard. Test your actual form rather than relying on a plugin's reputation.

Conclusion

WordPress accessibility is achievable for any site: start with a solid theme, structure your content properly, choose and configure plugins carefully, avoid heavy page builder and slider patterns, and test with a keyboard and an automated tool. Small fixes made consistently add up to a site that works for far more people.

Run your home page through our free accessibility checker to see your WCAG score and a list of fixes, or create a free Openwise account to install the WordPress plugin.