Most people reach this page after something specific happened. A patient who uses a screen reader called to say the appointment form would not submit. A vendor emailed about ADA website lawsuits and offered a widget that “fixes everything” for a monthly fee. A lawyer’s letter arrived. Sometimes nothing happened at all, and you just want your WordPress site to work for every visitor without knowing where to start.
Before you spend money on website accessibility services, it helps to know what the work is. Below we cover that, the US legal picture in plain terms, how an audit, fix and monitor cycle runs, where WordPress sites usually go wrong, and how to judge any provider, including us. It is written for owners and office managers, not developers, and it treats ADA website accessibility as a practical job rather than a sales pitch.
What website accessibility services actually involve
An accessible website is one that people with disabilities can perceive, understand, navigate and use. That includes people who are blind and use a screen reader, people with low vision who zoom to 200 or 400 percent, people who cannot use a mouse and move through a page with the keyboard or a switch device, people who are Deaf or hard of hearing and need captions, and people with cognitive or learning disabilities who need clear wording and predictable layouts.
Accessibility work is the practical job of finding the places where your site blocks those visitors and removing the barriers. On a typical business site that means things like:
- Menus and buttons that cannot be reached or opened with the Tab and Enter keys.
- Meaningful pictures with no text alternative, leaving a blind visitor with a file name like “IMG_2041” read aloud.
- Text that is too pale against its background to read comfortably.
- Forms with no real labels, error messages that only turn a border red, and CAPTCHAs that some people simply cannot pass.
- Videos without captions and PDFs that are a scanned picture of a page.
- Popups that trap focus or appear without any way to close them from the keyboard.
None of that is exotic. Most of it comes from ordinary decisions in themes, plugins and page builders, made by people who never tested with a keyboard. On most sites the bulk of it can be repaired without a rebuild.
So the work needs three skills: testing that finds barriers software cannot see, development that fixes them without breaking anything else, and maintenance that stops them returning after the next update.
The US legal context in brief (not legal advice)
We are web developers, not lawyers, so treat this as background and talk to an attorney about your own situation.
ADA Title III: businesses open to the public
The ADA’s Title III reaches “places of public accommodation”, which in everyday terms means businesses open to the public: shops, restaurants, clinics, hotels, law and accounting offices, gyms and many more. The statute is older than the web, and judges in different courts have read it differently when a website is involved, most of all where a company has no physical location. The Justice Department’s view, repeated for years, is that the law does reach the online side of these businesses; its March 2022 guidance on web accessibility put that view in writing.
No Title III rule spells out a technical standard yet. So in day-to-day practice the yardstick comes from elsewhere: demand letters, settlement terms and professional audits nearly always point to the Web Content Accessibility Guidelines, version 2.1 or 2.2, Level AA. For a fuller comparison of the three laws, see our plain-English guide to ADA compliance for websites.
ADA Title II: state and local governments
Title II covers state and local government: cities, counties, public school districts, public libraries, transit agencies and similar bodies. In April 2024 the DOJ published a final rule that adopts WCAG 2.1 Level AA as the technical standard for their web content and mobile apps. Compliance dates depend on the size of the population served and could change, so check the current dates on the official ADA website at ada.gov rather than relying on any vendor’s summary, ours included.
Section 508: federal agencies and the people they fund
Section 508 of the Rehabilitation Act covers information and communication technology used by federal agencies. Its 2017 refresh incorporates WCAG 2.0 Level AA. Private companies usually meet it through contract terms when they sell to or receive funding from federal agencies, and they are often asked for an Accessibility Conformance Report, which is written using a template called a VPAT.
If a demand letter or complaint has reached you, the order matters: a lawyer handles the legal response, and a technical team like ours handles the audit, the fixes and the record of what changed. We do not negotiate, advise on settlements or tell anyone what a court will do.
Why WCAG 2.2 Level AA is the practical target
The guidelines come from the Web Accessibility Initiative, part of the W3C. If you have never looked at it, our short piece on what WCAG is and how it is organized is a gentle starting point. They hang on four principles, remembered by the acronym POUR: content has to be perceivable, operable and understandable, and its code has to hold up across browsers and assistive technology. Beneath them are testable success criteria graded A, AA or AAA, and nearly every audit, contract and settlement settles on the middle grade. AAA across a whole site is not expected, even by the W3C.
Version 2.2 was finalized as a W3C Recommendation in October 2023. It keeps the 2.1 criteria, removes one obsolete criterion (4.1.1 Parsing) and adds nine new ones. Several of the additions matter on almost every WordPress site: 2.4.11 Focus Not Obscured, which catches sticky headers and cookie bars covering the keyboard focus; 2.5.8 Target Size (Minimum), which sets a minimum size (24 by 24 CSS pixels) for things you click or tap, with exceptions when small targets have room around them; 3.3.8 Accessible Authentication, which touches logins and CAPTCHA puzzles; and 3.3.7 Redundant Entry, which stops forms asking for the same details twice.
We audit against WCAG 2.2 AA. Passing the newer version covers the older one’s AA criteria too, apart from the retired Parsing criterion, which is why we use the newer version even for Title II clients whose rule names 2.1. If you want to see what the criteria look like on an ordinary business site, grouped by what you would actually notice, read our walkthrough of WCAG 2.2 AA requirements for business websites. The full standard itself is at the W3C’s WCAG 2.2 specification.
How the work runs: audit, fix, monitor
Almost every honest accessibility project follows the same three-stage shape, whoever does it. Knowing it helps you spot an offer that skips a stage.
1. Audit
First you need to know what is wrong. A proper audit picks a representative sample of pages (the home page, each distinct template, key service or product pages, every form, the checkout if there is one, and a few content-heavy pages), then tests them in layers. Automated scanners such as WAVE or axe run first because they are fast at finding missing alt attributes, empty links and contrast failures. Then a person goes through every sampled page with only a keyboard, then listening with NVDA or VoiceOver, then at high zoom and narrow widths. Each issue is written up with where it is, which WCAG criterion it fails, how serious it is for a real visitor, and how to reproduce it.
2. Fix
Fixes are ordered by impact, not by how easy they are. A checkout button that keyboard users cannot reach comes before a slightly low-contrast footer link. Work happens in the theme (or a child theme), in plugin settings or carefully targeted overrides, in page-builder layouts, and in content itself. Every fix is retested the same way the issue was found, so a keyboard problem is confirmed fixed with the keyboard, not with a scanner.
3. Monitor
WordPress sites change constantly. A plugin update can replace an accessible menu with an inaccessible one. Monitoring means scanning the site on a schedule, spot-checking key journeys by hand, reviewing new content, and catching regressions before a visitor does.
| Stage | What happens | What you end up with |
|---|---|---|
| Audit | Automated scan of sampled pages, then keyboard, screen reader and zoom testing by a person | An issue list with WCAG references, severity, location and steps to reproduce |
| Fix | Theme, plugin, form and content changes in priority order, each one retested | A working site plus a log of what was changed and where |
| Retest | The original issues checked again, plus a fresh look for anything the fixes disturbed | An updated issue list showing what is resolved and what remains |
| Monitor | Scheduled scans, manual spot checks after updates, review of new pages and documents | Short periodic reports and fixes for regressions as they appear |
If someone offers you only the third row, or only a scan from the first, you are buying part of the job.
Our website accessibility services, mapped
We split our website accessibility services into seventeen pieces so you can start with the one that fits your situation instead of buying a bundle you do not need. Most sites only need two or three of them.
Finding the problems
The WCAG audit service is where most projects should begin: automated scans plus manual keyboard and screen-reader testing on a sample of your pages, written up as a prioritized report you can hand to any developer. If you already have a scan report and want a person to go through the site properly, manual keyboard and screen reader testing covers the part machines cannot judge, such as whether focus order makes sense or whether link text is meaningful out of context.
Not sure you need either yet? The free website accessibility check is a short manual look plus a scan of a few key pages, enough to show the main barriers and suggest a next step. It is not an audit and does not give a compliance verdict.
Fixing what was found
Accessibility remediation is the hands-on fixing of issues from an audit, ours or someone else’s, with retesting and a written record of each change. Many of the worst barriers sit in forms, so accessible form fixes is its own service: labels, error messages, required fields, CAPTCHAs and multi-step forms in plugins such as Contact Form 7, Gravity Forms or WPForms.
Images, video and documents form another large group. Alt text, captions and accessible PDFs covers writing alt text across a media library, getting captions and transcripts in place, and converting or repairing documents.
WordPress, WooCommerce and page builders
Our WordPress accessibility services deal with the platform itself: themes, plugins, the block editor, navigation menus and widgets. Stores get extra attention in WooCommerce store accessibility fixes, which follows the shopping journey from product page to cart, checkout and account pages, including payment plugins. Sites built with Elementor or Divi have their own patterns of trouble (headings chosen for looks, icon-only buttons, carousels, tabs and popups), handled in Elementor and Divi accessibility work.
Situations with a legal or contractual edge
Some clients come to us because of a specific obligation or event. Our ADA website compliance support explains what the ADA means for a business website and how technical work supports a legal position, without giving legal advice. If a letter has arrived, technical fixes after an ADA demand letter covers the audit, fixes and documentation your attorney will want, while your attorney handles the response.
Public bodies on WordPress can use ADA Title II website work for local governments, which focuses on the WCAG 2.1 AA rule and the documents, agendas and forms that city and county sites carry. Federal contractors and grantees can use Section 508 website compliance help, including the technical input an Accessibility Conformance Report needs.
Replacing shortcuts and rebuilding properly
If your site runs an overlay toolbar, the accessibility overlay alternative service removes it safely and fixes the underlying problems it was hiding. When a site is so old or so tangled that fixing costs more effort than starting fresh, an accessible website redesign builds accessibility in from wireframes onward.
Keeping it working and saying so honestly
Ongoing accessibility monitoring is the monthly layer: scans, manual spot checks after updates, and fixes for regressions. And an accessibility statement written in honest terms tells visitors what standard you are working toward, what is known to be imperfect, and how to reach a person if something blocks them.
How WordPress sites typically fail accessibility checks
The same handful of failures turn up on WordPress sites again and again. If you want to try finding some of them yourself, open your home page, put the mouse aside and press Tab.
The focus outline is gone
Many themes remove the browser’s focus outline because a designer found it untidy. Keyboard users then have no idea where they are on the page. Sometimes the outline is there but a sticky header slides over it, which is exactly what 2.4.11 Focus Not Obscured addresses.
Menus only open on hover
Dropdown menus that appear on mouse hover and never on keyboard focus hide half the site from keyboard users. Mobile menu toggles are often a plain icon with no accessible name, so a screen reader announces “button” and nothing more.
Headings are chosen for their size
Editors and page builders pick H2 or H4 because it looks right, not because it fits the outline. Screen-reader users who jump through a page by headings then get a jumbled structure, or no headings at all on pages styled with bold paragraphs.
Forms lean on placeholder text
A grey “Your email” inside the field disappears when typing starts and is often not exposed as a label at all. Errors appear in red with no text explanation and are not announced. The CAPTCHA asks people to pick out traffic lights.
Plugins bring their own barriers
Sliders that autoplay with no pause button, cookie banners that cannot be reached with the keyboard, chat widgets that cover the bottom of the page, and booking calendars that only work with a mouse. Each plugin may be fine on its own; together they decide whether a visitor can get from the home page to a completed booking.
Content drifts over time
Even a carefully fixed site slips. New images go up without alt text, links read “click here”, a menu PDF gets uploaded as a photo. Our guide to writing accessible web content in WordPress covers what editors control day to day, and how to make a WordPress website accessible, step by step sets out the order of work if you want to tackle the platform side yourself.
Online stores add their own layer: product variations, quantity fields, mini carts that update without telling anyone, and payment fields inside third-party frames. Our guide to an accessible online store follows that journey end to end.
Why an overlay widget is not the answer
Overlays are toolbars or scripts added to a site that claim to make it accessible, sometimes “compliant”, automatically. They are easy to install and often marketed with a sense of urgency. The trouble is that they sit on top of the page and cannot reliably repair the things that actually block people: a menu built so the keyboard cannot open it, a form without real labels, a checkout step that traps focus. Many disabled users and accessibility practitioners criticize them openly, and a public Overlay Fact Sheet signed by practitioners sets out the objections. Overlay users have still been sued and sent demand letters. In 2025 the FTC also acted against accessiBe, one overlay seller, over what the agency called misleading claims.
Not every accessibility plugin is a problem; dashboard checkers are useful. The test is simple: does the tool change the underlying code and content so the site works without it, or does it paint over the problem? If you are running a widget now, removing it is usually quick; fixing what it was covering is the real work.
What you can check yourself before hiring anyone
You do not need to be a developer to learn a lot about your site in an hour. Our small business website accessibility checklist is a good companion for this, and our step-by-step method for testing website accessibility goes much deeper.
- Keyboard only. Click into the address bar, then work down the home page with Tab. Is there a visible marker on each item? Could you get into every menu item, find your enquiry form, complete it and send it? Will Escape dismiss a popup?
- Zoom. Hold Ctrl (or Cmd) and press plus until the page is two, then four, times its normal size. Does anything overlap, vanish or force sideways scrolling just to finish a sentence?
- A free scanner. Run your home page and contact page through WAVE or the axe browser extension. Treat the result as a list of clues, not a score.
- Video and documents. Do your videos have accurate captions, not just automatic ones nobody checked? Are your key PDFs real text you can select, or pictures of text?
- Read your link text aloud. If a page has six links that say “learn more”, a screen-reader user hearing a list of links gets six identical entries.
If this turns up a few small problems, you may be able to fix them yourself or with your current developer. If it turns up problems in the menu, the forms or the checkout, or if you are dealing with a letter or a contract requirement, that is the point where a structured audit earns its keep.
The documentation you should receive
Good records show your attorney what was done and when, let a future developer pick up where the last one stopped, and speed up the next audit. From any provider, expect at least:
- A scope note. Which pages and templates were tested, on which browsers and with which assistive technology, against which version and level of WCAG.
- An issue log. Each issue with its location, the WCAG success criterion it relates to, a severity rating, steps to reproduce, and a suggested fix.
- A change record. What was fixed, where (theme file, plugin setting, page content), and the date it was retested.
- A list of what remains. Issues not yet fixed, issues in third-party services you do not control, and anything deferred, with reasons.
- A current-state summary. A plain-language paragraph a non-developer can read, which is also useful when you write an accessibility statement.
Be wary of a report that is only a scanner export with a logo on it, or a certificate that says the site “passes”. Neither tells you what a person experienced on the site. Our explainer on how to read an accessibility audit report shows what a useful one looks like.
Access, staging and information to have ready
Accessibility work goes faster and safer when a few things are in place before anyone touches code.
- Admin access to WordPress, ideally a separate administrator account for us that you can remove later, and access to hosting or a backup tool so changes can be rolled back.
- A staging copy if you have one. Fixes to themes and forms are tested there before going live. If you do not have staging, we can usually set one up on your host or work carefully with backups.
- A list of your key pages and journeys. The pages that matter most to your visitors and your business: booking, contact, donate, apply, checkout, patient forms, whatever applies.
- Details of third-party tools embedded in the site, such as booking systems, payment providers, chat widgets and form services, since some of their barriers can only be fixed by the vendor.
- Any existing reports or letters, including previous audits, customer complaints or, if your attorney agrees, the issues listed in a demand letter.
How to compare website accessibility services from different providers
Some providers do excellent manual work; others resell scans or widgets with a promise attached. These questions tend to separate them quickly, and they apply to us as much as anyone.
- How much of the testing is done by a person? Ask them to describe the keyboard and screen-reader passes. If the answer is all about the tool, the testing is incomplete.
- Which standard and version do you test against? The answer should name WCAG, a version and a level, for example WCAG 2.2 Level AA.
- Can I see a sample report? Look for issue locations, criterion references, severity and reproduction steps.
- Do you fix the issues, or only report them? Either is fine, but know which one you are buying and who will do the rest.
- What happens after the fixes? Ask how regressions are caught when plugins update or new content goes up.
- What do you promise? Anyone who promises a compliant site, protection from lawsuits or a “certified” badge is promising something nobody can deliver.
| Approach | What it does well | What it misses |
|---|---|---|
| Overlay or widget | Installs quickly and adds user-side display options such as larger text | Leaves the underlying code and content unchanged; can conflict with screen readers; sets false expectations |
| Automated scan only | Finds many machine-detectable issues across lots of pages quickly | Only part of WCAG can be checked by software; cannot judge focus order, meaning or real usability |
| Manual audit only | Finds real barriers and explains them with evidence | Someone still has to fix them, and the site can drift after the report |
| Audit, fix and monitor | Finds issues, removes them, retests and keeps checking after updates | Takes more time and needs cooperation on content and third-party tools |
If you are an agency fielding these questions from your own clients, our note on answering a client who asks about ADA compliance may help you frame the conversation.
Why accessibility belongs inside WordPress maintenance
Most accessibility regressions are side effects. A theme update changes the button markup. A new form plugin arrives with its own styling. A marketing hire adds a popup. None of these will show up in uptime monitoring or a security scan.
That is why we treat accessibility as part of looking after a site, not a one-off project. The same habits that keep a site secure and fast also keep it usable: test updates on staging first, keep a short list of critical journeys and walk through them after changes, review new content before it goes live, and keep records. Our WordPress monthly maintenance plans can include accessibility spot checks alongside updates and backups, and the monitoring service above does the same in more depth for sites that need it.
What we will never claim
- We will not tell you your site is “ADA compliant” or attach any similar absolute label to it. There is no official ADA certification for websites, and conformance is something you work toward and maintain, not a stamp.
- We will not promise that our work prevents demand letters or lawsuits. Nobody can promise that. What good work does is remove real barriers and leave a clear record of the effort.
- We will not give legal advice. If a letter or complaint has arrived, an attorney should lead; we support them with the technical work and documentation.
- We will not sell you an overlay or tell you a scanner score proves anything on its own.
- We will not claim certifications we do not hold or results we cannot show. We are a small WordPress team near Kolkata, India, working remotely with US businesses, and we would rather tell you plainly what we can and cannot do.
What we will do is test your site carefully against WCAG 2.2 Level AA, fix what we can in the theme, plugins, forms and content, tell you clearly what we cannot fix and why, document every change, and keep checking so the site stays usable after the next round of updates. If you would like a first look before deciding anything, the free check described above is a sensible place to start.
Website Accessibility Guides by Topic
Each guide explains one part of the work in plain language, so you can check a site yourself or judge the work of whoever does it for you.
ADA, the law and risk
- ADA Compliance for Websites: What US Businesses Need
- Is My Website ADA Compliant? A 30-Minute Self Check
- ADA Website Lawsuits Explained for Business Owners
- What to Do After an ADA Demand Letter About Your Site
- ADA Title III Website Accessibility: Who It Covers
- DOJ Website Accessibility Guidance in Plain Words
- Does a Small Business Website Need to Be ADA Compliant?
- Accessibility Overlays: What They Do and Cannot Fix
- ADA vs WCAG: How the Law and the Standard Connect
- Does Accessibility Help SEO? The Honest Overlap
- Website Accessibility Cost: What Drives the Effort
- Website Accessibility Myths Owners Still Believe
WCAG in practice
- WCAG 2.2 AA Requirements: A Plain Guide for Owners
- WCAG 2.2 vs 2.1: What Changed and Which to Target
- WCAG Levels A, AA and AAA: What Each One Means
- The POUR Principles of WCAG, With Everyday Examples
- WCAG Color Contrast: Ratios, Tools and Brand Fixes
- WCAG Focus Indicator: Visible Focus That Works
- WCAG Target Size: The 24 by 24 Pixel Rule in Plain Words
- Skip Link Accessibility: Test and Fix Skip to Content
- ARIA Labels Explained: When They Help and When They Hurt
- Heading Structure for Accessibility: Get the Levels Right
- Descriptive Link Text: Fixing Read More and Click Here
- WCAG Reflow and Resize Text: Testing With Browser Zoom
Fixing WordPress
- 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
Testing and audits
- How to Test Website Accessibility: A Six-Pass Method
- Free Accessibility Testing Tools, Sorted by Job
- WAVE Accessibility Checker: How to Read Your Results
- axe DevTools: A Plain Guide to the Free Extension
- Lighthouse Accessibility Score: What 100 Really Means
- Test a Website With NVDA: A Beginner’s Guide
- VoiceOver Website Testing on Mac and iPhone
- Keyboard Accessibility Testing: A Tab-by-Tab Method
- Automated vs Manual Accessibility Testing: Who Judges What
- Accessibility Audit Report: How to Read One
- Free ADA Compliance Checker Sites: What the Score Means
- Mobile Accessibility Testing: Checks to Run on a Phone
Forms, checkout and online stores
- Ecommerce Accessibility: The Whole Shopping Journey
- WooCommerce Accessibility Issues and How to Fix Them
- Accessible Checkout: A Field-by-Field Guide for Stores
- Accessible Form Design: Labels, Groups and Layout
- Accessible Error Messages on Website Forms
- CAPTCHA Accessibility and Alternatives That Work
- Accessible Product Pages: Images, Swatches, Add to Cart
- Shopify Accessibility: What Store Owners Can Fix
- Accessible Booking Forms: Dates, Time Slots, Confirmation
- WordPress Contact Form Accessibility: What to Check
- Product Filter Accessibility for Online Stores
- Chat Widget Accessibility: Live Chat That Works for All
Content and design
- Accessible Web Content: What Editors Control
- Alt Text for Decorative Images: When to Use Empty Alt
- Video Captions for Accessibility: Get Them Right
- Transcripts for Accessibility: Podcasts and Audio
- Accessible PDF Files on Your Website: What to Fix
- Accessible Fonts: Size, Spacing and Readable Type
- Color Blind Friendly Website: When Color Can’t Carry Meaning
- Plain Language Writing for Your Website: A US Guide
- Accessible Tables: Headers, Captions and Phones
- Buttons vs Links: Which to Use for Accessibility
- Animation Accessibility: Parallax, Video and Reduce Motion
- Accessible Icons: SVG, Icon Fonts and Social Links