Blog October 29, 2026 · 14 min read

WordPress Accessibility Checklist: 12 Checks for 2026

Developer testing keyboard access on a website

A WordPress accessibility checklist should walk you through your theme, your content, your plugins and your testing routine, measured against WCAG 2.2 AA. This one does exactly that. Work through the 12 checks below in order, fix what you find in the theme, the block editor or the code, and keep a dated record of what you did. No checklist, and no automated tool, can promise that a site is fully accessible or legally compliant. Used well, though, a checklist turns a vague worry into a short list of jobs you can finish.

AccessWiser

accesswiser.com

Find and Fix WordPress Accessibility Issues

AccessWiser scans against WCAG 2.2 AA, connects findings to affected code, and provides plain-language guidance for lasting fixes.

Explore AccessWiser

TL;DR

Start with the foundation: an accessibility-ready theme, then plugins you have vetted, because both shape every page you publish.
Check the content basics on every page: headings, alt text, link text, color contrast, keyboard access, forms and captions.
Automated scanners find only part of the problems. Pair them with keyboard and screen reader checks by a person.
Overlays and widgets can add visitor controls, but they do not fix inaccessible source code. Fix the code.
Re-check on a schedule and keep dated records of scans, fixes and your accessibility statement.

Which standard should your checklist follow?
Part 1: The foundation (theme and plugins)
Part 2: The content checks on every page
Part 3: Testing and keeping it accessible
Do accessibility plugins fix these problems?
Our perspective: fix the source, document the work
Turn the checklist into a routine
FAQ
Sources

Which standard should your checklist follow?

Use WCAG, the Web Content Accessibility Guidelines, as your yardstick, and aim for version 2.2 at level AA. Almost every serious checklist is built on it, and the same criteria map onto Section 508 in the federal context and EN 301 549 in Europe.

In the United States, the Department of Justice says businesses and government entities have flexibility in how they comply with the ADA, but their online services must be accessible. Its web accessibility guidance points to WCAG and Section 508 as helpful references. The ADA does not name a single technical standard for private businesses, which is why WCAG 2.2 AA is the practical target most teams choose. If you want the legal picture in more detail, our piece on ADA vs WCAG explains how the two fit together.

Part 1: The foundation (theme and plugins)

Every page you publish inherits the markup of your theme and the behavior of your plugins. Problems here repeat on every page, so they are the best place to spend your first hour.

1. Choose an accessible theme

The WordPress theme directory has an “accessibility-ready” tag. Themes carrying it have passed a review against a set of requirements covering things like skip links, keyboard navigation, visible focus and form labels. Treat the tag as a strong starting point, not a guarantee. Themes change with updates, and your own customizations can break what the reviewers approved.

Before you commit to a theme, test its demo yourself:

Press Tab from the top of the page. Does a skip link appear first, and does it work?
Can you see where keyboard focus is at every step?
Does the main menu open and close with the keyboard, including submenus?
Does the layout hold up when you zoom the browser to 200%?
Is there one h1, with headings that follow the visual hierarchy?

If a theme fails these, no amount of careful content work will fully repair it. Page builders and heavily animated themes deserve extra scrutiny because they generate a lot of markup you do not control directly.

2. Vet every plugin that touches the front end

Sliders, pop-ups, form builders, cookie banners, mega menus and review widgets all output markup that visitors interact with. Each one can introduce barriers even when your theme is clean.

A useful vetting routine: check reviews, active installations, the date of the last update and compatibility with your current WordPress version. Then scan the site with an automated tester before and after you install, because plugins can introduce accessibility problems, as this guide to picking a plugin notes. Keep the before-and-after results. They are useful evidence later.

Plugin vetting criteria and before-and-after scans

The same discipline applies to accessibility plugins themselves. Some add real value, such as a checker that flags missing alt text in the editor. Others only layer a toolbar on top of the page. We cover how to judge those in a later section.

3. Set the document basics

Three quick settings in your theme and site configuration matter more than their size suggests:

Language: the page should declare its language so screen readers pronounce text correctly. WordPress sets this from Settings, General, Site Language.
Page titles: each page needs a unique, descriptive title.
Zoom: make sure your theme does not block pinch zoom or text resizing.

Part 2: The content checks on every page

The DOJ’s guidance lists the barriers that most often trip people up: color contrast, text alternatives, synchronized and accurate video captions, form labels and error instructions, zoom and text size, headings, and keyboard and mouse navigation. Those map neatly onto the next seven checks.

4. Use real headings in order

Headings are how screen reader users skim a page. In the block editor, use the Heading block and pick the level for its meaning, not its size. Your page title is the h1, main sections are h2, and subsections are h3. Never pick a heading level because you like how it looks, and never bold a line of text to fake a heading.

WordPress makes this easy to review. Open the Document Overview and go to the Outline tab, which, as this block editor handbook explains, flags incorrect heading levels. If the outline reads like a sensible table of contents, you are in good shape.

5. Write useful alt text

Every meaningful image needs a text alternative that conveys its purpose. Add it in the Alt Text field of the Image block.

Informative images: describe what matters in the context of the page. “Chef plating the lunch special” beats “image1.jpg”.
Functional images (an image used as a button or link): describe the action, such as “Download the menu (PDF)”.
Decorative images: leave the alt text empty so assistive technology skips them.
Images of text: avoid them. If you must use one, repeat the text exactly in the alt field.

Missing alt text is one of the few issues a scanner reliably detects, but only a person can judge whether the text is any good.

6. Make link text mean something

Screen reader users often pull up a list of all links on the page. A list full of “click here” and “read more” is useless. Write link text that makes sense alone: “Download the 2026 price list” rather than “Click here”. If several “Read more” buttons appear on an archive page, give each a distinct accessible name or change the text. Our guide to accessible content writing covers link text, plain language and reading level in more depth.

7. Check color contrast, text and non-text

WCAG AA asks for a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. User interface parts, such as form field borders, icons that carry meaning and focus indicators, need at least 3:1 against their surroundings. Theme palettes and brand colors are the usual culprits: light gray text on white, white text on a pastel button, placeholder text that barely shows.

Use a contrast checker on your brand colors once, then lock in compliant pairs in your theme settings or theme.json so editors cannot stray. For the details of the 3:1 rule, see our walk-through of non-text contrast. Also remember that color alone must never be the only signal. A required field marked only in red fails people with color vision differences, a topic we explore in color blindness accessibility.

8. Test keyboard access

Put your mouse aside and use only Tab, Shift+Tab, Enter, Space and the arrow keys. WebAIM’s evaluation guide lists the essentials: a logical tab order, a visible focus indicator with at least 3:1 contrast, and every interactive element reachable by keyboard.

Watch for these WordPress-specific trouble spots:

Dropdown menus that open only on hover.
Pop-ups and modals that trap focus or fail to close with Escape.
Sliders and carousels with no pause control.
Custom buttons built from div elements that do not respond to Enter or Space.

If you or your developer need a step-by-step method, our keyboard accessibility guide covers seven steps for testing and fixing it.

9. Label forms and explain errors

Contact forms, checkout fields, booking forms and newsletter sign-ups are where inaccessible sites lose customers. Each field needs a visible, programmatically associated label, not just placeholder text that vanishes when someone starts typing. Required fields should be identified in text. Error messages should say which field failed and how to fix it, and they should be announced to assistive technology.

If you use a form plugin, check its accessibility settings and avoid field types that are known to cause trouble, such as some custom date pickers and star ratings. Then submit the form deliberately wrong, with the keyboard only, to see what happens.

10. Caption video and transcribe audio

Videos need accurate, synchronized captions. Audio-only content needs a transcript. Auto-generated captions are a start, but they need editing for names, product terms and punctuation. Avoid autoplay, and give visitors a visible way to pause anything that moves.

Part 3: Testing and keeping it accessible

11. Combine automated and manual testing

Automated checkers are fast and worth running on every release. They are not enough on their own. The DOJ’s guidance says a clean report does not mean everything is accessible, and a report with errors does not necessarily mean barriers exist, so it recommends pairing manual checks with automation. The DOJ’s own regulatory impact analysis states that automated checkers are not sufficient to find all errors. Its manual review used source inspection, visual inspection, keyboard tabbing and the NVDA screen reader.

The numbers back this up:

A peer-reviewed study published in September 2025 found that most automated tools covered only about one-sixth of WCAG success criteria. It looked at Swedish public-sector websites, so treat it as a signal rather than a U.S. benchmark. Read the study on tool coverage.
The University of Arizona’s testing toolkit reports that in a 2017 UK Government Digital Service test, individual tools found only 17% to 41% of 143 known barriers.

A realistic routine looks like this:

Run an automated scan on your key templates: home page, a blog post, a product or service page, the contact form, checkout.
Tab through each template with the keyboard.
Zoom to 200% and check for overlapping or cut-off content.
Listen to one important flow with a screen reader such as NVDA (free on Windows) or VoiceOver on a Mac.
Fix, then re-test the same pages.

Our accessibility testing guide for developers turns this into a workflow you can run on each release.

12. Maintain it: schedule, document, invite feedback

WordPress sites change constantly. A new plugin, a theme update or an editor adding a page can quietly undo your earlier work. Build in three habits:

Re-check on a schedule. Monthly for active sites, and after every theme, plugin or major content change.
Keep dated records. Save scan reports, notes on what you fixed and when, and publish an accessibility statement. The W3C’s WCAG-EM reporting tool is a recommended way to document an evaluation, as noted in this WCAG testing reference.
Offer a way to report problems. The DOJ guidance says websites should give the public a way to report accessibility problems so owners can fix them. Put a contact link or short form in your footer and answer messages promptly.

Train whoever publishes content, too. The ADA’s guidance for state and local government websites stresses training staff and contractors who develop content as a primary part of long-term maintenance. The same logic holds for a small business with one part-time editor.

Do accessibility plugins fix these problems?

This is the most common question WordPress owners ask, so here is a direct answer: some plugins help, none of them finish the job.

It helps to separate three kinds of tools:

Type	What it does	What it cannot do
Editor-side checkers	Flag issues like missing alt text or skipped headings while you write	Judge quality, or catch problems in theme or plugin code
Scanners	Test rendered pages against WCAG criteria and report issues	Confirm that everything works for real people
Visitor-facing overlays and widgets	Let visitors adjust contrast, font size, text-to-speech or magnification	Repair the underlying source code

The Colorado Virtual Library’s explainer on overlays describes the limit well. Overlays can provide contrast, font-size, text-to-voice and magnification adjustments. They do not fix structural problems or issues like missing alternative text and video captions. Changing the presentation layer may give temporary controls, but it does not correct inaccessible source content.

So the sensible order is: fix the code and content first, then consider optional visitor controls as a courtesy on top. If you are weighing a widget, our five vendor checks are a good filter before you install anything.

Our perspective: fix the source, document the work

We built AccessWiser around a simple belief: permanent fixes beat patches. A runtime patch can make a report look better for a day, but the barrier stays in your code, and the next visitor who relies on a keyboard or screen reader meets it again. That is why every finding we report is tied to a specific element and a specific WCAG criterion, with plain-language guidance for fixing it in your own theme, template or content.

Our perspective: fix the source, document the work — overview diagram

We are also candid about automation. Scanners detect a substantial subset of barriers, not all of them, and we would rather say so than overpromise. The most reliable programs we see combine regular scans, hands-on keyboard and screen reader checks, and a habit of writing things down. Dated records of scans, fixes and your accessibility statement will not make anyone’s site perfect, but they show a genuine, continuing effort, and that is a sound footing for any compliance program.

For WordPress specifically, most problems come from a handful of sources: theme templates, page builder output, form plugins and uploaded media. Fix those at the root and the same errors stop reappearing on every new page. Our guide to fixing WordPress accessibility errors at the code level shows how.

— The AccessWiser Team

Turn the checklist into a routine

A checklist is easiest to keep when something runs it for you. AccessWiser scans your WordPress site against WCAG 2.2 AA, with Section 508 and EN 301 549 mappings, and shows each issue with the element and criterion it affects. It then re-checks on a schedule to catch regressions and keeps dated records of scans and fixes, plus an accessibility statement you can publish. Plans start at $24 per month (Starter), with Basic at $49 per month and Pro at $119 per month, and every plan begins with a 7-day free trial. Extra specific page scans cost $12 one-off and extra full site scans $19 one-off. See the details on the pricing page, or look at how we handle our own accessibility statement.

Want a wider framework to plan the work? Our WCAG 2.2 checklist for web teams lays out an audit-first, 90-day remediation plan.

FAQ

Is WordPress accessible out of the box?

WordPress core aims for accessibility, and the block editor has improved over the years. Your live site, however, depends mostly on your theme, plugins and content. A site built on an accessibility-ready theme can still fail if editors skip alt text or a plugin outputs inaccessible markup, so test your own pages rather than assuming.

Can a plugin make my WordPress site ADA compliant?

No single plugin can promise compliance. The DOJ says automated tools can help find or fix problems but should be paired with manual checking, and overlays do not correct inaccessible source content. Use plugins as helpers, fix your code and content, and keep records of your work.

How often should I run through this checklist?

Run the full list when you launch or redesign, then re-check key pages after any theme, plugin or major content change. For an active site, a monthly scheduled scan plus a quick keyboard test is a sensible rhythm. Review the whole list at least once a year.

What is the first thing to fix if I have limited time?

Start with the issues that block people from completing tasks: keyboard access, form labels and error messages, color contrast, and missing alt text on key images. Fix them on your highest-traffic pages and checkout or contact flows first, then work outward.