Maybe a customer emailed to say they could not finish your contact form. Maybe a vendor sent a scary note about ADA lawsuits and offered a plugin that “fixes everything.” Either way you are now looking at your WordPress dashboard and wondering where to even begin.
This guide covers how to make a WordPress website accessible in a sensible order: the parts that affect every page first, then the parts that affect one page at a time, then the habits that stop it all sliding back. You do not need to be a developer to follow the logic, even if you hand some of the steps to one.
Why the order of work matters more than the tool
Much of the advice on how to make a WordPress website accessible starts with a plugin. It is more useful to start with the layers. A WordPress site has three of them. The theme draws the header, menus, footer and the basic styles. Plugins add forms, sliders, popups and shop pages. Then you and your staff add the content: headings, images, links, PDFs, videos. A barrier can live in any layer, and fixing them in the wrong order wastes time.
A common trap: someone spends a week rewriting alt text on two hundred blog posts, then discovers the theme’s menu cannot be opened with a keyboard and the focus outline was removed site-wide. The alt text work was worth doing, but the menu blocked every keyboard user on every page the whole time.
So the rule of thumb is simple. Fix what repeats on every page before what appears on one page. Fix what stops someone completely before what slows them down. Most US businesses measure against the W3C’s WCAG 2.2 at Level AA. The standard is organized into testable success criteria at three levels, and AA is the one most audits and settlements refer to.
Step 0: take a baseline before you change anything
Before installing or deleting anything, write down where you are. Choose a small set of pages that represent the whole site: the home page, a standard inner page, a blog post, the contact page, any page with a form, and if you sell online, a product page, the cart and checkout. On a small business site that is often around ten URLs.
On each one, run a free scanner such as WebAIM’s WAVE tool, then put the mouse aside and press Tab through the page. Note three things: can you reach every link and button, can you always see where you are, and does anything trap you. Keep the notes in a plain spreadsheet with the page, the problem and where it appears.
That sheet becomes your work list, and later it shows whether a change helped.
Step 1: the theme, because it is on every page
The theme controls the parts of the page that repeat everywhere, so a single fix there helps every URL at once. The usual theme-level problems are:
- No visible focus indicator, because the stylesheet removes the outline and puts nothing in its place.
- No skip link, or a skip link that points to an ID that no longer exists.
- Low-contrast text in the header, footer or buttons, often a light gray on white.
- The site logo is an image link with no text alternative, so a screen reader announces the file name.
- A missing or wrong page language setting, so screen readers read English text with the wrong pronunciation rules.
- Layout that breaks when the browser is zoomed to 200 or 400 percent.
Most of these can be fixed in a child theme, or in the theme’s own settings if it is a block theme, without changing themes. Sometimes the theme is so far gone that a switch is cheaper than patching. Our post on choosing and testing an accessible WordPress theme explains how to tell the difference and what the Accessibility Ready tag does and does not promise.
If your site is built with a page builder, the builder is effectively part of the theme layer. Its widgets produce the markup for most of your pages. We cover the common output problems separately for sites built with Elementor and for sites built on Divi.
Step 2: the plugins, starting with the ones visitors touch
Next, list every plugin that puts something in front of visitors: forms, sliders, galleries, popups, cookie banners, chat buttons, booking calendars, shop extensions. Plugins that only work in the dashboard (backups, security, SEO fields) rarely create front-end barriers, so they can wait.
For each visitor-facing plugin, ask the same three questions from your baseline: can a keyboard user operate it, can a screen reader user understand it, and can someone with low vision see it. Expect to find a slider that autoplays with no pause button, a newsletter popup that leaves keyboard focus stranded behind it, or a cookie banner you cannot reach with Tab. Each of those has its own post in this series, and the fixes are usually a setting change or a better-built replacement plugin.
Some plugins exist to help with accessibility itself. They fall into very different kinds, from checkers that report problems to toolbars that claim to fix them automatically. Before you install one, read our breakdown of what each kind of accessibility plugin can really do. The short version: a checker is useful, a small targeted helper can be useful, and an overlay does not replace real fixes.
When a plugin cannot be fixed
You cannot always edit a plugin’s output. If its developer ignores a support request, override the output carefully, replace the plugin with a tested, better-built one, or drop the feature.
Step 3: menus and the header
Keyboard and screen reader users start in the header on every visit. If they cannot get through it, nothing below matters.
Test the main menu with the keyboard only. Can you open a dropdown without a mouse? Does the mobile menu button announce itself as a button and say whether it is open or closed? Can you close it with Escape? Hover-only dropdowns and hamburger icons built from a plain link are the two problems we find most often. The details are in our guide to building a navigation menu that works by keyboard.
Also look at what sits on top of the page. A sticky header can cover the element that has keyboard focus, which WCAG 2.2 now addresses directly in 2.4.11 Focus Not Obscured. Chat buttons and cookie bars can do the same at the bottom of the screen.
Step 4: content your team controls
Once the frame of the site works, turn to the content. This part does not need a developer, but everyone who edits the site needs a few habits:
- Use real headings in order. One main heading per page, then H2s for sections, H3s inside them. Do not pick a heading level because of its size.
- Write alt text that says what an image communicates, and leave it empty for purely decorative images. Our walkthrough on adding alt text in WordPress shows where the field is.
- Make link text make sense on its own. “Download the 2026 menu (PDF)” works; a page of “Read more” links does not.
- Check text color against its background, especially on colored sections and text placed over photos.
- Use real lists and real tables instead of lines typed with dashes or columns faked with spaces.
If your team writes in the block editor, much of this is built in once you know where to look. Our post on writing accessible pages in the block editor goes through it block by block.
Step 5: forms, where people actually get stuck
Forms are where a barrier costs you a real enquiry, booking or sale. Every field needs a visible label that stays visible while typing, not only placeholder text that disappears. Required fields should be marked in text, not only with a red asterisk. Errors should say what went wrong and how to fix it, and a screen reader should hear them.
Then try the CAPTCHA. Image puzzles and distorted text lock out many people, and on login screens WCAG 2.2 now speaks to this directly in 3.3.8 Accessible Authentication. On a contact form, a honeypot field or an invisible spam check usually does the job without the puzzle.
Fill in each form with the keyboard only, submit it with a mistake on purpose, and listen to what happens with a screen reader. For the fix side, our accessible form fixes service page lists what we check on contact, booking and quote forms.
Step 6: images, video and documents
Media problems are usually volume problems. A site might have a few hundred images, a dozen videos and a folder of PDFs, and each needs its own decision.
- Images: sort them into decorative, informative and functional (an image that is a link or button). Functional images need alt text that describes the action, such as “Search” or “Go to home page.”
- Video: prerecorded videos with speech need captions. Automatic captions from a video host are a starting point, but they need editing for names, numbers and terms.
- PDFs: a menu, price list or form as a scanned PDF is often unreadable to a screen reader. Ask whether it should simply be a web page.
Start with media on your busiest pages and anything a customer must act on.
Step 7: test like a person using the site
A scanner sees code, not meaning, so it finds only part of what goes wrong. It will flag a photo with a missing alt attribute, yet happily accept alt text that reads “IMG_4471.” It can spot low contrast, but it cannot tell you the checkout loses keyboard focus after you change the quantity.
So after each round of fixes, repeat the baseline and add a human pass:
- Run the same scanner on the same sample pages and compare against your sheet.
- Tab through each page. Watch where the outline goes and whether it ever disappears.
- Zoom the browser to 200 percent, then 400 percent, and look for cut-off text or sideways scrolling.
- Turn on a screen reader (NVDA on Windows is free, VoiceOver is built into Macs and iPhones) and listen to the headings list, the links list and one form.
- Write down what you fixed and what is still open, with dates.
Keep that record. If anyone later asks what you have done about accessibility, a dated list of tests and fixes is something you can actually show. An in-dashboard tool helps between these passes; our guide to reading a WordPress accessibility checker’s warnings explains how to tell a real issue from noise.
Step 8: keep it accessible after the next update
A site that passes in March can fail in May. A theme update restores a removed outline rule, a new plugin adds an unlabeled field, an editor pastes a table as an image. Accessibility drifts the same way speed and security do.
What prevents that is a light routine rather than another big project: test updates on a staging copy of the site first, re-run your sample pages monthly, and check any new template or plugin before it goes live. We wrote up a fuller routine in keeping WordPress accessible after updates.
How to make a WordPress website accessible: the whole order on one page
For a typical small business site, the full sequence fits in one table:
| Order | Layer | Who usually does it | Why now |
|---|---|---|---|
| 1 | Baseline sample and notes | Owner or developer | You need something to measure against |
| 2 | Theme or page builder output | Developer | One fix reaches every page |
| 3 | Visitor-facing plugins | Developer | Forms, popups and sliders block whole tasks |
| 4 | Menus and header | Developer | Every visit starts there |
| 5 | Content habits and fixes | Editors | Cheap to do once people know how |
| 6 | Media and documents | Editors, sometimes a specialist | Volume work, best done by priority |
| 7 | Manual testing and records | Developer or tester | Confirms what tools cannot judge |
| 8 | Monthly routine | Whoever maintains the site | Stops the work from undoing itself |
None of this makes a site “compliant” in a legal sense, and we are not lawyers; a letter from an attorney goes to your own attorney, not to your web developer. What this order does is remove real barriers, in a way you can document, while working toward WCAG 2.2 AA conformance. For how audits, repairs and ongoing checks fit together, our overview of website accessibility services lays it out.
Frequently asked questions
Can I make a WordPress site accessible without changing my theme?
Often, yes. Many theme problems such as missing focus styles, low-contrast colors, a broken skip link or an unlabeled logo can be fixed in a child theme or the theme settings. A switch makes sense when the theme’s menus, layout and markup need so much work that patching costs more than rebuilding on a better base.
Should I fix old blog posts or only new content?
Start with new content and the old pages people still visit. Your analytics will show which older posts get traffic; fix those first, along with anything customers must act on, such as service pages, forms and PDFs. Very old posts nobody reads can wait, or be updated when someone next edits them.
How many pages do I need to test?
Test one example of every distinct template and every important task rather than every URL. For most small sites that means the home page, a standard page, a post, the contact or booking page, any page with a form, and the product, cart and checkout pages if you sell online. Then spot-check new content as it is added.
Do my editors need training?
A short session helps a lot. Most content problems come from a handful of habits: picking headings by size, skipping alt text, writing “click here” links, pasting text as images and using low-contrast colors. Once editors know those, new pages stay in much better shape and the developer’s time goes to the harder fixes.
Which version of WCAG should a WordPress site aim for?
Most US businesses aim for WCAG 2.2 Level AA, the current W3C recommendation. Government bodies under the 2024 ADA Title II rule are held to WCAG 2.1 AA, and work toward 2.2 AA generally covers that as well. A lawyer can advise on any specific legal obligation that applies to your organization.
If you would rather have someone else work through this list on your site, our WordPress accessibility services follow the same order: audit the theme, plugins and content, fix them, retest and write down what changed.
All guides in this section
- WordPress Accessibility Plugin Types: What Each Can Do
- Accessibility Ready WordPress Themes: What the Tag Means
- Elementor Accessibility: Fixing What Your Pages Output
- Divi Accessibility: Common Problems and How to Fix Them
- Block Editor Accessibility: A Block-by-Block Guide
- Accessible Navigation Menu: Dropdowns, Mobile, ARIA
- WordPress Accessibility Checker: Reading the Results
- Accessible Carousel: Making Sliders Usable for All
- Modal Popup Accessibility: Focus, Escape, Return
- Cookie Banner Accessibility: Keyboard, Focus, Wording
- How to Keep WordPress Accessible After Updates
Next in this series: WordPress Accessibility Plugin Types: What Each Can Do
