Accessibility on WordPress: Beyond the Overlay Widget

Search for “WordPress accessibility plugin” and you will find a handful of overlay widgets promising instant compliance: a floating icon that adds font size controls, a contrast toggle, and a legal badge. They feel like a shortcut. They are not. Overlays sit on top of your markup without fixing what is underneath, and they cannot repair a broken heading structure, a form with no label, or a carousel that traps keyboard focus. Real accessibility work happens in your theme, your content, and your testing habits. None of it is exotic, and most of it pays off in usability and SEO too.

Why overlay widgets fall short

Accessibility overlays work by injecting JavaScript that tries to adjust the page after it loads. That approach has structural limits. They cannot infer meaning that was never coded in the first place, so a button that is really a styled div stays unusable to screen reader users no matter what the widget does. They can also interfere with assistive technology that visitors already have configured the way they like, overriding a screen reader user’s own settings with the site’s guesses. Legal exposure has followed this pattern too: sites have faced complaints and lawsuits despite running an overlay, because the underlying barriers were still there. An overlay can be a helpful convenience feature for some visitors, but it is not a substitute for accessible markup, and it should never be sold to you as one.

Start with the theme

Your theme sets the ceiling for how accessible your site can be, so check the fundamentals before anything else.

• Semantic HTML. Headings should nest in order (one h1, then h2, then h3, without skipping levels), navigation should live in a nav element, and buttons should be real button elements rather than styled links or divs with click handlers.
• Keyboard navigation. Every interactive element, menus, modals, sliders, accordions, should be reachable and operable using only the Tab, Enter, and arrow keys. Try navigating your own site with the mouse unplugged. If you get stuck or lose track of where focus is, so will your visitors.
• Visible focus states. Many themes strip the default focus outline for aesthetics and never replace it. Without a visible focus indicator, keyboard users cannot tell where they are on the page. This is one of the most common and most fixable failures in WordPress themes.
• Color contrast. Body text needs enough contrast against its background to be readable for people with low vision or color blindness. Check your theme’s default text, link, and button colors, not just your customized brand palette, since defaults often slip through unnoticed.
• Skip links. A “skip to content” link that appears on keyboard focus lets users bypass repetitive header navigation, which matters a great deal to anyone browsing by keyboard alone.

If your current theme is thin on these basics and you are not comfortable patching templates, moving to a theme that was built with accessibility in mind from the start is usually less work than retrofitting one that was not.

Content habits that matter more than any plugin

A lot of accessibility is editorial, not technical, and it is entirely under your control regardless of theme or plugin.

• Alt text on images. Every meaningful image needs a concise description of what it conveys. Purely decorative images should have empty alt attributes (alt="") so screen readers skip over them instead of reading a distracting filename.
• Descriptive link text. “Click here” and “read more” tell a screen reader user nothing when they are scanning a page’s links out of context. “Read our hosting guide” does.
• Logical heading order. Use headings to outline your content, not to make text look bigger. Skipping from an h2 to an h4 because it “looks right” breaks the outline that screen reader users rely on to navigate.
• Labeled forms. Every input needs an associated label, not just placeholder text that vanishes once someone starts typing.
• Captions and transcripts. Video needs captions and audio needs transcripts for users who are deaf, hard of hearing, or simply browsing without sound.
• Plain, direct writing. Short sentences and clear structure help readers with cognitive disabilities, non-native speakers, and honestly everyone skimming on a phone.

These habits do not require a developer. They require a checklist and a bit of editorial discipline every time you publish.

Tools worth actually using

A handful of free tools will catch the majority of common issues before your visitors do:

• Browser extensions like axe DevTools or WAVE scan a rendered page and flag missing alt text, contrast failures, and structural problems directly in your browser.
• Lighthouse, built into Chrome’s DevTools, includes an accessibility audit alongside its performance scoring, so you can check both in the same pass.
• Manual keyboard testing. Automated tools catch maybe a third of real accessibility issues. Actually tabbing through your key pages, checking out your menus, forms, and modals, catches problems no scanner will find.
• Screen reader spot checks. You do not need to become an expert user, but running your homepage and a blog post through VoiceOver (Mac) or NVDA (Windows) for a few minutes will teach you more about your site’s real accessibility than any audit report.

Run these checks periodically, not just once. Themes update, plugins add new blocks, and new content goes up constantly, any of which can quietly reintroduce a problem you already fixed.

Where WordPress core and plugins help

The block editor generates reasonably clean, semantic markup by default, which is a real advantage over hand-rolled page builder output that piles nested divs on top of each other. Choose blocks and page builder patterns that respect that structure rather than overriding it with custom HTML embeds whenever possible. A handful of accessibility-focused plugins can genuinely help, adding ARIA landmarks, checking color contrast in the editor, or flagging missing alt text at publish time. The distinction that matters is whether a tool helps you fix your markup and content, or whether it just papers over problems with a script layered on top. The first approach compounds over time as your site improves. The second one does not.

The takeaway

Accessibility is not a widget you install and forget. It is semantic markup in your theme, visible focus states, real alt text and link text, and a habit of testing with a keyboard and a screen reader now and then. None of it is glamorous, and none of it requires a specialist budget. It does require treating accessibility as part of how you build and publish, not as a compliance checkbox to tick after the fact. Sites that take this approach tend to end up faster and clearer for every visitor, not just the ones using assistive technology, which is exactly the kind of side effect worth aiming for.