WordPress Accessibility Services: Theme, Plugins and Content

Most WordPress sites we look at were not built badly on purpose. Someone picked a theme that looked good in the demo, added a slider plugin, a cookie notice, a form builder and a chat bubble, and then three different people wrote pages in the editor over five years. Each piece is fine on its own until you try to use the site with a keyboard or a screen reader. Then the problems stack up: the menu will not open without a mouse, the form fields have no names, half the images say “IMG_4471”. Our WordPress accessibility services are built around that reality. We work layer by layer, theme first, then plugins, then the content your team adds, and we test on a staging copy so your live site keeps running while we do it.

What our WordPress accessibility services cover

This page is about WordPress specifically. For audits, the US legal background and the rest of the service menu, see our website accessibility services overview. Here we stay inside the WordPress dashboard and the files behind it.

We aim for Level AA of WCAG 2.2, the yardstick American auditors and plaintiffs’ letters usually cite. In practice that means we look at the parts of WordPress that produce the HTML a visitor actually receives:

• The theme, classic or block, including header, footer, archive and single templates.
• The child theme, where we put our code changes so they are not lost when the parent theme updates.
• Plugins that print markup on the front end: sliders, galleries, popups, forms, cookie banners, chat, reviews, social feeds.
• Content in the block editor: headings, lists, buttons, tables, columns, embeds and color choices.
• Navigation menus, desktop and mobile, including dropdowns.
• Forms built with whichever plugin you use.
• The media library, where alt text is stored and where years of uploads usually need sorting out.

We do not hand you a scan printout and leave. We change the code and content, retest, and write down what changed.

The theme: where site-wide barriers usually start

A barrier in the theme repeats on every page, so it is the first place we look. One missing focus style in the theme stylesheet means a keyboard user cannot see where they are anywhere on the site. One header template that wraps the logo in a link with no text means every page announces an unnamed link before anything else.

Typical theme findings include:

• A CSS rule that removes the focus outline (“outline: none” on links and buttons) with nothing put back in its place, which fails 2.4.7 Focus Visible.
• A sticky header that slides over the focused link as you tab down the page. WCAG 2.2 added a criterion for exactly this, 2.4.11 Focus Not Obscured (Minimum).
• A skip link that is missing, or present but aimed at a target the template never outputs.
• Heading levels chosen for size rather than structure, such as widget titles marked up as H2 in the sidebar of every post.
• Body text or placeholder text in a light gray that falls below the 4.5:1 contrast ratio.
• No language attribute on the page, or the wrong one, so screen readers guess the pronunciation.

The “Accessibility Ready” tag in the WordPress theme directory is a useful signal when you are choosing a theme, because those themes pass a review of things like keyboard navigation, skip links and contrast. It is not a promise that your site meets WCAG once you have customized it, added plugins and written content. We explain what the tag does and does not check in our guide to choosing an accessible WordPress theme.

Block themes behave a little differently from classic themes. WordPress core adds a skip link for block themes, and much of the layout is edited in the Site Editor through templates and template parts rather than PHP files. That changes where a fix goes, but not what we test.

Child theme fixes that survive the next theme update

If you edit a parent theme directly, the next update overwrites your work. That is how many sites lose accessibility fixes someone paid for a year earlier. So on a classic theme we create or reuse a WordPress child theme and put our changes there: extra CSS for focus styles and contrast, template overrides for the header or search form, and small PHP filters where a theme function needs to output better markup.

On a block theme, many changes are saved in the database through the Site Editor, and some are better placed in a small site-specific plugin we write for you. Either way, the rule is the same: nothing we fix should live in a file that an update can replace without warning.

We also keep a short changelog of each override. If your developer later swaps the theme, they can see exactly which accessibility fixes they need to carry across.

Plugins that quietly add barriers

A plugin can be well rated and still print markup that blocks people. The plugins we most often find causing trouble on business sites are:

• Sliders and carousels that autoplay with no pause control and trap keyboard focus inside the slide track.
• Popup and newsletter plugins that open a dialog but leave focus behind it on the page, so a screen reader user never learns it appeared.
• Cookie consent banners that cannot be reached by keyboard or sit on top of the content until dismissed.
• Chat buttons fixed to a corner that cover links and form fields on small screens.
• Review and social feed widgets that inject dozens of unlabeled links and icons.
• Gallery and lightbox plugins where the close button is an icon with no accessible name.

For each one we work through the options in order: change a setting the plugin already offers, patch its output with a small filter or script, replace it with a plugin that behaves better, or remove it if nobody really needs it. Replacing or removing is always your call; we tell you the tradeoff and the effort before touching anything.

One thing we will not do is add an overlay toolbar to cover the problems. If you already have one installed, we can take it out as part of this work and fix what it was hiding.

WordPress layer	A common barrier	Where the fix lives	What keeps it fixed
Theme	Focus outline removed site-wide	Child theme stylesheet or theme.json styles	Child theme survives parent updates
Plugin	Slider autoplays with no pause button	Plugin setting, small filter, or a replacement plugin	Checking after each plugin update
Menu	Dropdown opens on hover only	Theme navigation script and markup	Retesting when the menu structure changes
Form plugin	Placeholder used instead of a label	Form field settings and plugin markup	Editor habits when new forms are built
Content	Bold text used as fake headings	The post itself, in the block editor	Editor guidance and monthly review
Media library	File names read out as alt text	Attachment details and the blocks that use the image	An upload routine for new images

Block editor content your team writes every week

Code fixes are only half the job. The rest lives in the pages your staff publish. The block editor gives editors good tools, but it does not stop anyone from skipping from H2 to H5 because the smaller size looked nicer, or from typing a list as separate paragraphs with hyphens.

When we review content we look for:

• Headings that follow a logical order and are real heading blocks, not bold paragraphs.
• Lists built with the List block so screen readers announce how many items there are.
• Button blocks with text that says where they go, rather than “Learn more” four times in a row.
• Tables used for data, with a header row turned on, and not used to lay out columns of text.
• Text and background colors picked in the editor that still pass contrast.
• Embedded videos that have captions, and links to PDFs that say they are PDFs.

We fix the pages that matter most first, usually the home page, service pages, contact page and anything linked from the main menu. Then we give your editors a short, plain checklist so new pages start out right. If you want the editor side in more depth, read our walkthrough on writing accessible content in the block editor.

Menus and forms: the two places visitors get stuck

Navigation menus

Press Tab on the home page and watch what happens when focus reaches a menu item with a dropdown. On many themes, nothing does. The submenu only opens on mouse hover, so keyboard users cannot reach those pages at all. On others the submenu opens but the mobile toggle is a plain div element that a screen reader calls “clickable” with no name.

We rework the menu so a parent item can open its submenu from the keyboard, the toggle is a real button that says “Menu” and reports whether it is expanded, and Escape closes what was opened. Our article on building an accessible dropdown menu covers the patterns in more detail.

Forms

Contact, quote and booking forms are where accessibility problems cost a business directly, because a person who cannot submit the form simply leaves. Whatever plugin you use, whether that is Contact Form 7, Gravity Forms, WPForms or something else, we check that every field has a visible label tied to it, required fields are marked in text and not only by color, errors are announced and explain how to fix them, and the success message is read out after sending. CAPTCHA choices get a look too, since some puzzles block people outright. For sites with many forms or complex multi-step ones, our dedicated form accessibility fixes go further.

Alt text across the media library, at scale

A site that has been running for a few years can have thousands of images in the media library. Many have no alt text, some have the file name, and some have keyword-stuffed text an old SEO plugin suggested. Writing alt text one image at a time is slow, so we sort first.

1. We export a list of images and where each one is used, so you can see which images sit on important pages.
2. We mark images as decorative (empty alt is right), informative (needs a short description) or functional (a linked logo or icon, where the alt text should say what the link does).
3. We write or correct alt text for the informative and functional images on key pages first.
4. We fix the blocks themselves, because in the block editor the alt text is stored with each Image block. Changing it in the media library later does not update images already placed in posts.

That last point surprises a lot of site owners, and it is why bulk tools that only update the media library can leave the live pages unchanged. If you are adding alt text yourself, our short tutorial on adding image alt text in WordPress walks through the editor and the media library.

How the work runs: staging, fix, retest

We never test fixes on your live site first. Here is the usual order:

1. Agree the scope. You send the key pages and forms that matter to your business. We pick a sample of templates that covers the rest: home, a standard page, a post, an archive, search results, the contact page.
2. Set up or refresh staging. If you do not have a staging copy of your WordPress site, we make one with your host’s tools or a migration plugin, and make sure it is hidden from search engines.
3. Test. Automated scans with tools like WAVE and axe, then manual testing with a keyboard and screen readers such as NVDA and VoiceOver, and zoom checks. If you have not had a formal audit yet, a full WCAG audit is usually the first step.
4. Fix in layers. Theme, then plugins, then menus and forms, then content and media.
5. Retest the same pages. Each fixed issue is checked again with the method that found it.
6. Push to live and spot-check. We deploy, clear caches, and repeat key checks on the real site, because caching and minify plugins sometimes change markup.

Your documentation, and the access we ask for

When the project closes, you receive a written record, in plain language, organized by page and by WCAG success criterion. It lists what was found, what was changed, where the change lives (child theme, plugin setting, custom plugin, page content), and what is still open and why. Some items stay open for good reasons: a third-party payment iframe we cannot edit, or a plugin you chose to keep for business reasons. Those are written down honestly rather than hidden.

To start, we need:

• An administrator account on WordPress (we can tell you exactly how to create one and remove it later).
• Hosting or SFTP access, or someone at your host who can help, so we can work on theme files and staging.
• A list of your most important pages, forms and user journeys.
• Any premium plugin or theme licenses, so updates and support stay available.
• A contact person who can answer questions about content, since only you know what an image is meant to show.

Judging the result honestly

An accessible WordPress website is not proven by a green score from one browser extension. A good way to judge our work, or anyone’s, is to repeat a few checks yourself:

• Unplug the mouse and try to reach every menu item, fill in the contact form and submit it.
• Zoom the browser in until text is twice its normal size and confirm nothing overlaps or disappears.
• Run a free scanner on the home page and compare it with the report you were given.
• Pick three issues from the report and see whether they are really gone.

What we will not claim is that the site is “ADA compliant” or safe from legal action. We are developers, not lawyers. What we can say is which success criteria in WCAG 2.2 AA our tested pages now meet, which they do not, and what we did. If you have received a demand letter, your attorney handles the legal response; we handle the technical work.

Doing it in-house versus bringing in help

A capable in-house person can fix a lot. Alt text, heading order, link wording and form labels inside a form plugin are well within reach of an editor who knows what to look for, and our practical walkthrough for making a WordPress site accessible yourself is written for exactly that person.

Outside help earns its keep with the code layer: focus management in menus and dialogs, theme template overrides, plugin output you cannot change from the settings, and screen reader testing by someone who uses these tools every week. It also helps when a lawyer or a procurement team asks for documented changes.

Mistakes we see often

• Editing the parent theme, then losing every fix at the next update.
• Installing three “accessibility” plugins that conflict with each other.
• Fixing only the home page and assuming the rest follows.
• Bulk-adding alt text that just repeats the page title.

Questions to ask any WordPress accessibility provider

• Will a person test by keyboard and with NVDA or VoiceOver, or do you rely on scanners?
• Where will your code changes live, and will they survive theme and plugin updates?
• Will you work on a staging copy first?
• What will the final document show, page by page?
• What do you do about plugins you cannot change?

Keeping it accessible once the work is done

WordPress changes every month. Core updates, theme updates and plugin updates can alter markup, and every new page an editor publishes is a fresh chance for an unlabeled button or a skipped heading. A site that was in good shape in spring can drift by autumn without anyone noticing.

That is why we pair WordPress accessibility services with our monthly WordPress maintenance plan, where updates are applied carefully and checked, and with ongoing accessibility checks that retest your key pages after changes. If your site was built with Elementor or Divi, the builder adds its own patterns to watch, which we cover on our page about fixing page builder output.

For reference, the full list of criteria we test against is published by the W3C in the WCAG 2.2 specification.

Fixing WordPress: Guides

Step-by-step guides on the individual tasks behind this service:

• How to Make a WordPress Website Accessible, Step by Step
• 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