How to Make Your WordPress Site ADA Accessible Without Overlay Widgets

If you have been researching how to make your WordPress website ADA compliant, you have probably encountered accessibility overlay widgets. These are the tools that add a small icon (usually a wheelchair symbol or a person icon) to the corner of your website, promising to make your site fully accessible with a single line of code. The pitch is compelling: install one JavaScript widget and achieve ADA compliance automatically. The reality is far less rosy. Accessibility overlays have been widely criticized by disability advocates, accessibility professionals, and even the Department of Justice. They do not deliver the compliance they promise, and in many cases, they actually make websites harder to use for people with disabilities. The good news is that genuine WordPress accessibility is achievable without overlays, and this guide walks you through exactly how to do it.

Why Accessibility Overlays Are Not the Answer

Before explaining what to do instead, it is important to understand why accessibility overlays fail. This is not a fringe opinion. It is the consensus among accessibility professionals, backed by legal precedent and user experience research.

They do not fix the underlying code. Overlays add a cosmetic layer on top of your website. They might change font sizes, colors, or cursor styles for users who activate the widget. But they do not fix the structural accessibility issues in your HTML, like missing alt text, improper heading hierarchy, inaccessible forms, or keyboard navigation problems. Screen readers and other assistive technologies interact with your actual code, not the overlay layer.

They interfere with existing assistive technology. People who need accessibility features already use specialized software: screen readers like JAWS or NVDA, voice recognition tools like Dragon, switch devices, and more. Overlay widgets often conflict with these tools, overriding user preferences and creating confusion. Multiple disability advocacy organizations have published open letters asking websites to remove overlays because they make their experience worse.

Legal protection is not guaranteed. Despite vendor claims, overlays have not prevented ADA lawsuits. In fact, businesses using overlays have been sued and lost. The Department of Justice has stated that overlays alone do not satisfy ADA requirements. Courts have consistently held that websites must be fundamentally accessible, not merely augmented with a toolbar.

They create a false sense of compliance. The biggest danger of overlays is that they convince website owners they have "solved" accessibility, discouraging them from making the real improvements that actually matter. This delays genuine compliance and can increase legal exposure.

Performance and privacy concerns. Overlay scripts add JavaScript to every page load, slowing your site down. Some overlay vendors collect visitor data through their scripts, raising privacy concerns. And if the overlay vendor's servers experience downtime, the widget disappears entirely.

For a thorough understanding of accessibility requirements and best practices, our complete guide to making your website accessible covers everything from legal requirements to implementation details.

Understanding What ADA Accessibility Actually Requires

The Americans with Disabilities Act requires that businesses open to the public provide equal access to their services, and courts have increasingly interpreted this to include websites. While the ADA does not specify technical standards for websites, the widely accepted benchmark is the Web Content Accessibility Guidelines (WCAG) version 2.1, Level AA conformance.

WCAG is organized around four principles, often remembered by the acronym POUR.

Perceivable. Information and interface components must be presentable to users in ways they can perceive. This means providing text alternatives for images, captions for videos, sufficient color contrast, and content that can be presented in different ways without losing meaning.

Operable. Interface components and navigation must be operable by all users. This means full keyboard accessibility, sufficient time for users to read and interact with content, no content that could cause seizures, and clear navigation mechanisms.

Understandable. Information and interface operation must be understandable. This means readable text, predictable page behavior, and input assistance that helps users avoid and correct errors.

Robust. Content must be robust enough to be reliably interpreted by a wide variety of user agents, including assistive technologies. This means using valid, semantic HTML and ensuring compatibility with current and future tools.

Choosing an Accessible WordPress Theme

Your theme is the foundation of your site's accessibility. Starting with a well-built, accessible theme eliminates many potential issues before they ever arise.

Look for accessibility-ready designation. WordPress.org maintains a list of themes tagged as "accessibility-ready." This tag means the theme has passed a review process confirming it meets baseline accessibility standards, including proper heading structure, keyboard navigation, skip links, form labels, and sufficient color contrast.

Recommended accessible themes. Several themes have strong accessibility credentials and have earned the "accessibility-ready" tag in the WordPress theme directory.

• GeneratePress is lightweight with excellent semantic HTML, proper ARIA attributes, and fully keyboard-navigable interfaces. It is one of the most popular choices among accessibility-conscious WordPress developers.
• Astra offers an accessibility-ready version with proper heading hierarchy, keyboard navigation, and screen reader support. Its lightweight codebase keeps page speeds fast while maintaining semantic markup.
• Flavor is a free theme built with accessibility as its primary design goal, offering WCAG 2.1 AA compliance out of the box.
• Flavor passed WordPress.org's accessibility review and provides solid heading structure alongside keyboard navigation.
• Flavor is known for accessible markup with a focus on readability and assistive technology compatibility.
• Twenty Twenty-Five (and other recent default WordPress themes) are built by the core WordPress team with accessibility as a requirement, making them solid starting points for accessible sites.

What to check in any theme. Before committing to a theme, test these accessibility features yourself. Navigate the demo site using only your keyboard (Tab, Shift+Tab, Enter, Escape). Check that a visible focus indicator appears on every interactive element. Verify that headings follow a logical hierarchy (H1 followed by H2, not jumping to H4). Run the demo through an automated accessibility checker like WAVE.

Fixing Images and Media for Accessibility

Images and media are among the most common sources of accessibility issues on WordPress sites. Fixing them is straightforward once you understand the requirements.

Alt text for every meaningful image. Every image that conveys information needs descriptive alt text. In WordPress, you add alt text through the media library or directly in the block editor when inserting an image. Good alt text describes what the image shows in a concise, meaningful way. "Team photo showing five employees standing in front of the company building" is useful. "Image" or "photo.jpg" is not.

Decorative images need empty alt attributes. Images that are purely decorative (background patterns, dividers, aesthetic elements) should have empty alt text (alt="") so screen readers skip them entirely. Adding descriptive text to decorative images clutters the experience for screen reader users.

Video captions and transcripts. All video content needs accurate captions. If you embed YouTube or Vimeo videos, use their built-in captioning tools. For self-hosted videos, WordPress plugins like WP Accessible Video can help manage captions. Provide full transcripts for audio content like podcasts.

Audio descriptions for complex visual content. If a video relies heavily on visual information that is not conveyed through the dialogue or narration, audio descriptions (a separate audio track that describes the visual content) may be needed for WCAG AA compliance.

Responsive images. Ensure images resize properly on different screen sizes. WordPress handles this well by default through srcset attributes, but custom implementations or page builder modifications can sometimes break this functionality.

Making Navigation and Menus Accessible

Navigation is critical for accessibility because it is how every visitor moves through your site. Inaccessible navigation effectively locks people out of your content.

Skip navigation links. A skip link is a hidden link at the top of each page that becomes visible when a keyboard user tabs to it. It allows users to jump directly to the main content, bypassing the navigation menu. Most accessibility-ready themes include skip links. If yours does not, add one manually or use a plugin.

Keyboard-navigable menus. Every menu item must be reachable and activatable using only a keyboard. Dropdown submenus need to open with keyboard interaction (Enter or Space key), not just mouse hover. Test this thoroughly, as many WordPress themes fail on dropdown keyboard accessibility.

ARIA landmarks. Your theme should use proper ARIA landmark roles (or equivalent HTML5 semantic elements) to identify page regions: navigation (nav), main content (main), sidebar (aside), footer (footer), and header (header). Screen reader users rely on these landmarks to jump between page sections efficiently.

Descriptive link text. Avoid generic link text like "click here" or "read more." Screen reader users often navigate by tabbing through links, and hearing "click here, click here, click here" provides no useful context. Use descriptive text that makes sense out of context: "Read our shipping policy" instead of "click here."

Breadcrumb navigation. Breadcrumbs help all users understand their location within your site hierarchy. For screen reader users, breadcrumbs provide valuable orientation. Use the nav element with an aria-label of "Breadcrumb" to properly identify breadcrumb navigation.

Mobile menu accessibility. Hamburger menus (the three-line icons common on mobile) need proper ARIA attributes. The button should have an aria-label like "Toggle navigation menu" and aria-expanded set to "true" or "false" depending on whether the menu is open.

Forms and Interactive Elements

Forms are where many WordPress sites fail on accessibility. Contact forms, search boxes, checkout forms, and email signup forms all need attention.

Label every form field. Every input field must have an associated label element. The label should be visible (not hidden with CSS) and programmatically associated with its input using the "for" attribute. Placeholder text inside the input field is not a substitute for a label, because placeholder text disappears when the user starts typing and is not consistently announced by screen readers.

Error messages must be accessible. When form validation fails, error messages should appear near the relevant field, be announced to screen reader users (using aria-live regions or by moving focus to the error), and clearly explain what went wrong and how to fix it. Vague errors like "Invalid input" are unhelpful for everyone, but especially for users relying on assistive technology.

Group related fields. Use fieldset and legend elements to group related form fields (like a set of radio buttons or a billing address section). This grouping provides context that screen readers announce when the user enters the group.

Accessible CAPTCHAs. Standard image-based CAPTCHAs are often inaccessible to screen reader users and people with visual disabilities. Use alternatives like Google reCAPTCHA v3 (which is invisible), hCaptcha's accessibility mode, or honeypot techniques that do not require user interaction.

Button labels. Submit buttons and other interactive controls need clear, descriptive labels. "Submit" is acceptable, but "Send your message" or "Complete your order" is better because it tells the user exactly what the button does.

For more recommendations on WordPress plugins that support these and other accessibility needs, check out our article on the best WordPress plugins for small businesses.

Color, Contrast, and Typography

Visual design choices directly impact accessibility. Making the right choices benefits all users, not just those with disabilities.

Minimum contrast ratios. WCAG 2.1 AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold). Use a contrast checker tool like WebAIM's Contrast Checker to verify your color combinations. Common failures include light gray text on white backgrounds, colored text on colored backgrounds, and low-contrast placeholder text in form fields.

Do not rely on color alone. Information conveyed through color must also be available through other means. If a form field turns red to indicate an error, also add an error icon and text message. If a chart uses colors to distinguish data series, also use patterns or labels.

Readable font sizes. Use a minimum body text size of 16px. Ensure text can be resized up to 200 percent without breaking your layout or losing content. WordPress themes that use relative units (rem or em) for font sizes handle this better than those using fixed pixel sizes.

Line spacing and paragraph length. Adequate line spacing (at least 1.5 times the font size) and reasonable line lengths (50 to 80 characters) improve readability for everyone, including people with dyslexia and cognitive disabilities.

Avoid text in images. When text is embedded in an image, it cannot be resized, read by screen readers, or translated. Use actual HTML text instead of images of text whenever possible.

WordPress Accessibility Plugins That Actually Help

Unlike overlays that promise to fix everything automatically, these plugins address specific accessibility issues and genuinely improve the experience for users with disabilities.

WP Accessibility. Created by accessibility expert Joe Dolson, this plugin fixes common WordPress accessibility issues. It adds skip links, removes title attributes from images, forces a visible focus outline, and addresses various theme-level accessibility problems. It is free and well-maintained.

One Stop Accessibility. This plugin provides tools for adding accessibility features to your theme, including skip links, readable font toggles, high contrast mode, and keyboard navigation improvements. It focuses on genuinely useful features rather than cosmetic overlay-style changes.

Access Monitor. Also by Joe Dolson, this plugin integrates automated accessibility testing directly into your WordPress dashboard. It scans your pages for common accessibility issues and reports them, helping you identify and fix problems proactively.

WP Accessible Heading Optimizer. This plugin scans your content for heading hierarchy issues (like jumping from H2 to H4) and can automatically correct them. Proper heading hierarchy is one of the most important and commonly broken accessibility requirements.

Theme-level features. Built-in accessibility features in quality themes like GeneratePress and Astra are often more effective than plugins, so check your theme's built-in capabilities before adding plugins.

Testing Your WordPress Site for Accessibility

Regular accessibility testing is essential. Use a combination of automated tools and manual testing for the most complete picture.

Automated Testing Tools

WAVE (Web Accessibility Evaluation Tool). Available as a browser extension or online tool, WAVE identifies accessibility errors, alerts, and structural issues on your pages. It provides visual indicators showing exactly where issues occur.

Axe DevTools. A browser extension that runs automated accessibility tests and provides detailed, developer-friendly reports. It catches many issues that other tools miss and is used by professional accessibility auditors.

Lighthouse. Built into Chrome DevTools, Lighthouse includes an accessibility audit that scores your pages and identifies specific issues. While not as thorough as dedicated accessibility tools, it provides a useful quick check.

Pa11y. An open-source automated testing tool that can be run from the command line or integrated into your development workflow. It is useful for ongoing monitoring.

Manual Testing Techniques

Keyboard-only navigation. Put your mouse away and navigate your entire site using only the keyboard. Can you reach every page, open every menu, fill out every form, and activate every button? Is the focus indicator always visible? Does the tab order follow the visual layout logically?

Screen reader testing. Test your site with an actual screen reader. NVDA (free for Windows) and VoiceOver (built into macOS and iOS) are the most accessible options. Navigate your site as a screen reader user would and note any points of confusion.

Zoom testing. Zoom your browser to 200 percent and verify that all content remains accessible. Text should reflow (not require horizontal scrolling), images should not overlap text, and interactive elements should remain usable.

Color blindness simulation. Use browser extensions like Colorblind Web Page Filter to see how your site appears to people with different types of color blindness. Verify that all information remains understandable.

Our WordPress complete setup guide includes additional configuration recommendations that support an accessible WordPress installation from the start.

Creating an Accessibility Statement

An accessibility statement demonstrates your commitment to inclusivity and provides important information for users with disabilities.

What to include. Your statement should cover your commitment to accessibility, the WCAG version and conformance level you are targeting, any known limitations or areas where you are still working toward compliance, the date of your most recent accessibility assessment, and contact information for users who encounter accessibility barriers.

Where to place it. Add your accessibility statement as a dedicated page linked from your website footer. Some businesses also link to it from their contact page and legal pages.

Keep it honest. Do not claim perfect compliance if your site has known issues. A statement that acknowledges specific limitations and describes your plan to address them is far better (both legally and ethically) than a blanket claim of full compliance.

Building an Ongoing Accessibility Practice

Achieving accessibility is not a one-time project. It requires ongoing attention as your content and site evolve.

Train content creators. Anyone who adds content to your WordPress site needs to understand basic accessibility practices: writing alt text, using proper headings, creating descriptive link text, and checking color contrast.

Include accessibility in your workflow. Before publishing any new page or post, run it through a quick accessibility checklist. Does it have alt text on all images? Are headings hierarchical? Do links have descriptive text? Are form fields labeled?

Schedule regular audits. Perform a thorough accessibility review at least quarterly. Use automated tools for broad scanning and manual testing for interaction quality.

Listen to user feedback. Provide a clear way for visitors to report accessibility issues. When someone reports a problem, take it seriously and address it promptly.

Stay current. Accessibility standards, assistive technologies, and legal requirements evolve. Follow accessibility news through resources like the W3C WAI mailing list, WebAIM, and The A11Y Project to stay informed about changes that affect your site.

The path to genuine accessibility requires more effort than installing an overlay widget. But the result is a website that truly works for everyone, protects your business from legal risk, and often improves the experience for all users. Semantic HTML, proper heading structures, keyboard navigation, and thoughtful design choices benefit everyone who visits your site, not just people with disabilities. That is a far better investment than a quick-fix widget that delivers neither accessibility nor compliance.