How to Fix WordPress Accessibility Issues Without a Plugin

To fix WordPress accessibility, you audit your site with free tools like WAVE or axe DevTools, then patch the actual code — missing alt text, broken focus styles, bad heading order, unlabeled forms, and more — directly in your theme files and functions.php. No overlay widget. No accessibility “AI” band-aid. Real fixes, real code, real compliance. This guide shows you exactly how to fix WordPress accessibility issues the right way, one broken thing at a time.

Why Accessibility Overlays Are a Lie (And What to Do Instead)

Before we get into how to fix WordPress accessibility properly, let’s kill the myth that’s been bleeding money out of site owners for years: accessibility overlays do not work. Learning to fix WordPress accessibility issues yourself saves money and actually works.

Overlays are those little toolbar widgets — AccessiBe, UserWay, AudioEye — that promise to make your site WCAG compliant with one line of JavaScript. They cost $500–$1500/year. They are being sued in federal court. They fail audits. And disabled users hate them because they interfere with the assistive technology those users already have.

The WebAIM Million Report 2024 found that pages using accessibility overlays had more detectable errors on average than pages without them. Let that sink in. You’re paying for something that makes your site worse.

We’ll cover overlay scams in full detail in our next article. For now, just understand this: the only way to genuinely fix WordPress accessibility is to open the code and fix the actual problems. That’s what this guide is for. Every time you fix WordPress accessibility problems, real users benefit immediately.

How to Run a Free Accessibility Audit Before You Fix WordPress Accessibility Issues

You can’t fix what you haven’t found. Run these three tools before you touch a single line of code. They’re free, fast, and brutal in the best way.

WAVE Web Accessibility Evaluation Tool

Go to wave.webaim.org, paste your URL, and get a visual overlay of every error on your page. Red icons = errors. Yellow = alerts. WAVE is the fastest way to see how broken things are. It also shows you structural issues like heading order and missing labels directly on the page. The fastest way to fix WordPress accessibility issues is addressing them in your theme code.

axe DevTools (Browser Extension)

Install the axe DevTools browser extension from Deque. Open your site, hit F12, go to the axe tab, and run the scan. It categorizes issues by WCAG criterion, tells you exactly which element is failing, and gives you the code reference. This is the tool professional auditors use.

Google Lighthouse

Already in Chrome DevTools. Hit F12, go to Lighthouse, check “Accessibility,” and run the audit. You’ll get a score from 0–100 and a categorized list of failures with links to documentation. A score of 100 does not mean fully accessible — automated tools only catch about 30–40% of issues — but it’s a solid baseline.

Run all three. Compare results. Export them. That’s your fix list. When you fix WordPress accessibility violations, screen reader users can finally navigate your site.

Fix WordPress Accessibility: The 10 Most Common Problems (With Code)

These are the problems you’ll find on almost every WordPress site. Each fix below goes directly into your theme files — either in a child theme’s functions.php, a template file, or your style.css. If you’re not using a child theme, stop and set up proper debugging first so you can catch errors before they break things. Sites that fix WordPress accessibility issues consistently see lower bounce rates.

Fix 1: Missing Alt Text on Images

Missing alt text is the second most common WCAG failure, showing up on 54% of pages. Every image needs descriptive alt text unless it’s purely decorative — in which case it needs an empty alt="" attribute (not a missing one).

In WordPress, the alt text field lives in the Media Library on each image’s attachment detail screen. But the deeper fix is enforcement: check your media library management workflow to make sure alt text is being added at upload time, not as an afterthought.

For decorative images in theme templates, always add alt="" explicitly. Never output an image tag without the alt attribute at all — that’s what triggers the accessibility failure: You can fix WordPress accessibility problems without buying expensive overlay subscriptions.

<!-- Wrong -->
<img src="banner.jpg">

<!-- Decorative - correct -->
<img src="banner.jpg" alt="">

<!-- Meaningful - correct -->
<img src="team-photo.jpg" alt="The AI Or Die Now crew at their battle stations">

Fix 2: Color Contrast Failures

WCAG 2.2 requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18pt+ or 14pt bold+). To check your current contrast: open Chrome DevTools, click any text element, go to the Styles panel, click the color swatch, and Chrome will show you the contrast ratio right there with a pass/fail indicator.

Once you find the failing colors, fix them in your child theme’s style.css:

/* Before — grey text on white: contrast ratio ~3.0:1 — FAIL */
.entry-meta {
  color: #999999;
}

/* After — darker grey: contrast ratio ~7.0:1 — PASS */
.entry-meta {
  color: #595959;
}

Use the WebAIM contrast checker to validate before you commit. Light grey text on white backgrounds is the single most common failure across the web and it’s a two-minute CSS fix. The tools to fix WordPress accessibility errors are free — WAVE, axe DevTools, Lighthouse.

Fix 3: Missing Skip Navigation Link

Keyboard users and screen reader users need a way to skip past your navigation and jump straight to the main content. Without a skip link, they have to tab through every nav item on every page. That’s brutal. Add this to your child theme’s functions.php and style.css:

// In functions.php — hook into wp_body_open
add_action( 'wp_body_open', 'aiordienow_skip_link' );
function aiordienow_skip_link() {
  echo '<a class="skip-link screen-reader-text" href="#main-content">Skip to main content</a>';
}

// Make sure your main content wrapper has id="main-content"

/* In style.css */
.skip-link {
  position: absolute;
  left: -9999px;
  top: auto;
  width: 1px;
  height: 1px;
  overflow: hidden;
}

.skip-link:focus {
  position: fixed;
  top: 0;
  left: 0;
  width: auto;
  height: auto;
  padding: 12px 24px;
  background: #000;
  color: #fff;
  font-size: 1rem;
  z-index: 99999;
  text-decoration: none;
}

Fix 4: Keyboard Navigation and Focus Styles

Every interactive element on your page — links, buttons, form fields, menus — needs a visible focus indicator when tabbed to. Most themes strip this out with outline: none or outline: 0 because some designer thought it looked messy. That’s a WCAG 2.2 failure and it’s also just cruel.

Search your theme’s CSS for outline: none and outline: 0 and replace them: After you fix WordPress accessibility failures, test with a real screen reader to verify.

/* Add to your child theme style.css */
:focus {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
}

/* If you want to hide it for mouse users only (use with caution) */
:focus:not(:focus-visible) {
  outline: none;
}

:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
}

Also audit your mobile menu. Most hamburger menus are completely inaccessible — they’re <div> elements with a click handler, no keyboard event, no ARIA. The fix is either using a <button> element or adding role="button", tabindex="0", and a keydown event handler. If you’re using a page builder for your navigation, you may have a bigger problem. Read our take on why page builders trap you in situations exactly like this.

Fix 5: Missing Form Labels

Forms without proper labels are a WCAG failure and a UX disaster for screen reader users. The placeholder attribute is not a label. It disappears when you type and screen readers don’t consistently announce it. Every input needs a <label> with a matching for/id pair:

<!-- Wrong -->
<input type="email" placeholder="Your email">

<!-- Correct -->
<label for="user-email">Email address</label>
<input type="email" id="user-email" name="email" placeholder="you@example.com">

If you need a visually hidden label for design reasons, use the screen-reader-text class (WordPress includes this in core) rather than skipping the label entirely. The EAA now requires you to fix WordPress accessibility issues or face legal consequences.

Fix 6: Heading Hierarchy Problems

Your page should have one H1 (usually the post title), then H2s for major sections, H3s for subsections, and so on. Never skip levels — don’t jump from H2 to H4. Screen reader users navigate by headings like a table of contents. A broken heading structure is like a book with the chapters in random order.

Check your theme templates in /wp-content/themes/your-theme/. Look at header.php, index.php, single.php, page.php, and widget areas. Widgets especially love to spit out wrong heading levels. Fix them in your child theme template overrides or via the block editor’s heading level controls. Don’t pay someone to fix WordPress accessibility problems you can solve with basic CSS and HTML.

Fix 7: Missing ARIA Landmarks

ARIA landmark roles tell screen readers what kind of region they’re in — navigation, main content, footer, search. Most WordPress themes have the right HTML5 elements but forget the ARIA roles that reinforce them for older assistive technology:

<header role="banner">
<nav role="navigation" aria-label="Main navigation">
<main role="main" id="main-content">
<aside role="complementary">
<footer role="contentinfo">

Add these to your child theme’s template files. If you have multiple <nav> elements (main nav, footer nav, breadcrumbs), each one needs a unique aria-label. Check the WordPress Accessibility Handbook for the full recommended landmark structure.

Fix 8: Language Attribute Not Set

Screen readers need to know the language of your page to use the right pronunciation engine. If lang is missing from your <html> tag, a French screen reader might try to pronounce English words with French phonetics. It’s a mess. Most efforts to fix WordPress accessibility issues start with running an automated audit.

WordPress sets this automatically via the language_attributes() function in your theme’s header.php. If your theme doesn’t use it, fix it:

<!-- In header.php -->
<html <?php language_attributes(); ?>>

<!-- Outputs something like: -->
<html lang="en-US">

Your site language is set in Settings → General in the WordPress dashboard. Make sure it matches your actual content language.

Fix 9: Auto-Playing Media

Auto-playing video or audio is a WCAG 2.2 failure (Success Criterion 1.4.2) and also just annoying to everyone. If you must autoplay, the video must have no audio, or you must provide a mechanism to pause or stop it within the first 3 seconds. No exceptions. Remove autoplay from video embeds or add proper controls. For custom video embeds, see our guide on how to embed videos in WordPress the right way. Once you fix WordPress accessibility contrast and alt text, you’ve solved over half of all failures.

Fix 10: Insufficient Link Text

“Click here.” “Read more.” “Learn more.” These link texts are meaningless out of context — and screen reader users frequently navigate by pulling up a list of all links on the page. Every link text must make sense when read alone. Fix it in your theme templates and train your content editors:

<!-- Wrong -->
<a href="/post-slug">Read more</a>

<!-- Correct -->
<a href="/post-slug">Read more about fixing WordPress accessibility issues</a>

<!-- Or use aria-label to supplement -->
<a href="/post-slug" aria-label="Read more about fixing WordPress accessibility issues">Read more</a>

How to Test Your Fixes with a Real Screen Reader

Automated tools catch maybe 30–40% of accessibility issues. The only way to know your fixes actually work is to test with real assistive technology. Here’s how to do it without spending a cent.

NVDA on Windows (Free)

Download NVDA from nvaccess.org. It’s free. Pair it with Firefox for the most realistic screen reader experience. Turn off your monitor or close your eyes and try to navigate your site using only the keyboard and audio. Tab through your nav. Fill out a form. Find a specific heading. It’ll take you about 10 minutes to understand exactly why accessibility matters. Every WordPress site owner should know how to fix WordPress accessibility violations themselves.

VoiceOver on Mac (Built-in)

Press Cmd + F5 to toggle VoiceOver on macOS. Use it with Safari. The keyboard commands are different from NVDA but the experience is equally revealing. Navigate by headings (VO + Command + H), by links (VO + Command + L), and by form controls (VO + Command + J).

When you use a screen reader and your skip link works, your form labels announce correctly, your focus styles are visible, and your headings make sense in sequence — that’s when you know you’ve actually managed to fix WordPress accessibility the right way.

Fix WordPress Accessibility to WCAG 2.2 Level AA — The Standard You Need to Hit

When you fix WordPress accessibility problems at the theme level, every page benefits at once.

The target standard for almost every legal context — ADA in the US, EAA in the EU, AODA in Canada — is WCAG 2.2 Level AA. There are three levels: A (minimum), AA (industry standard and legal baseline), and AAA (aspirational). You need AA.

WCAG 2.2 added several new success criteria compared to 2.1, including:

• 2.4.11 Focus Not Obscured (Minimum): Focused elements can’t be completely hidden by sticky headers or cookie banners
• 2.4.12 Focus Not Obscured (Enhanced): Focused elements must be fully visible
• 2.5.7 Dragging Movements: All drag interactions need a pointer alternative
• 2.5.8 Target Size (Minimum): Interactive targets must be at least 24×24 CSS pixels
• 3.2.6 Consistent Help: Help mechanisms must appear in a consistent location
• 3.3.7 Redundant Entry: Users shouldn’t have to re-enter info already submitted in the same session

For a site running custom code, always reference the spec directly. The WordPress Accessibility team also maintains guidance in the developer docs — use it alongside the WCAG spec, not instead of it. It takes about an afternoon to fix WordPress accessibility issues on a typical WordPress site.

Fix WordPress Accessibility in Your Theme Without Breaking Everything

The safest way to fix WordPress accessibility at the code level is via a child theme. Never edit a parent theme directly — updates will wipe your changes. If you’re not sure how to work with theme files safely, brush up on WordPress PHP version compatibility first since some fixes require PHP 7.4+, and make sure your server environment is solid before you start touching template files.

Your fix workflow should look like this: The return on investment when you fix WordPress accessibility issues is massive — more users, better SEO, legal protection.

1. Run WAVE + axe + Lighthouse audit. Export results.
2. Prioritize by severity: WCAG A failures first, then AA.
3. Create a child theme if you haven’t already.
4. Fix one category at a time — alt text, then contrast, then skip nav, etc.
5. After each fix, rerun the automated audit to confirm the error is gone.
6. Do manual keyboard testing and screen reader testing after all automated fixes.
7. Document what you changed and why (for future audits and legal cover).

Also worth noting: if you’re managing a lot of image uploads and the alt text situation is a mess, fixing your WordPress image optimization workflow at the same time will save you double the effort later.

Frequently Asked Questions About How to Fix WordPress Accessibility

The Bottom Line on How to Fix WordPress Accessibility

To fix WordPress accessibility, you audit first, then patch the actual broken code — one failure at a time, in a child theme, with real tools and real testing. The 10 fixes in this guide cover the vast majority of what you’ll find in any accessibility audit: missing alt text, contrast failures, broken focus styles, unlabeled forms, bad heading order, missing skip links, absent ARIA landmarks, undefined language, autoplay media, and garbage link text.

None of it requires a plugin. None of it requires a $1,200/year overlay. It requires about half a day and the willingness to treat accessibility as a technical standard rather than a checkbox. When you fix WordPress accessibility the right way, the improvements are permanent, they survive plugin updates, they work with every assistive technology, and they hold up in court.

The WebAIM Million 2024 report says 96.3% of websites fail WCAG. Be part of the 3.7%. Fix WordPress accessibility now — not with a widget, not with a prayer, with code.