How to Talk to Your Web Developer About Accessibility (Without Getting Stonewalled)
Accessibility conversations with developers often stall before they start. The developer says the site is fine, and the owner is unsure how to push back. Specific questions produce a usable answer.
Updated with additional research.
The conversation goes a predictable way. A business owner raises a concern about accessibility. Maybe a demand letter arrived, maybe a client had difficulty using the site, maybe the owner read something about ADA requirements. The developer says the site is fine. The owner, without a technical frame of reference, either accepts the answer or ends up in a circular exchange that resolves nothing.
This happens because “is the site accessible” is too broad a question to produce a useful answer, not because developers are evasive. A more specific question, with specific follow-ups, produces a much clearer picture.
Start with the Standard
Instead of asking “is our site accessible,” an owner can ask whether the site has been evaluated against WCAG 2.2 Level AA.
WCAG 2.2 is the version W3C encourages everyone to use, and conformance to it also meets 2.1. That matters because the rules that cite a version currently cite 2.1. The Justice Department’s April 2024 rule for state and local governments names WCAG 2.1 AA. For private businesses, the Department says it has set no detailed web standard and treats WCAG as guidance. Level AA is met by satisfying 55 success criteria at Levels A and AA, a count taken from the specification.
A specific standard makes the answer measurable and documented. “Yes, it’s accessible” provides no such record.
A developer who has done this work can say which criteria were evaluated, how they were tested, and what the outcome was. A developer who has not done the work often shifts to a different answer, such as “we follow best practices” or “we used accessible design principles.” The shift suggests the evaluation has not happened.
Ask About the Evaluation Method
The next question is about method: was the evaluation manual, automated, or both?
Automated tools cover a large share of issues but not all of them. Deque, an accessibility software vendor, analyzed first-time audits covering more than 13,000 page states and about 295,000 issues. Its automated testing found 57% of the issues by volume, but it could check only 16 of the 50 WCAG 2.1 AA criteria. W3C states that tools cannot check every aspect automatically and that human judgement is required.
If the developer’s evaluation was an automated scan with no critical errors found, the site has not been evaluated against the whole standard.
If the developer says the evaluation was manual, the follow-up is which criteria were covered and whether keyboard navigation was tested. A developer who did keyboard testing can describe it specifically. They went through every interactive element using only the keyboard, checked that the focus order was logical, tested modals and dropdowns, and confirmed the focus indicator was always visible.
A vague description of the testing usually means the manual work did not happen at the rigor the term implies.
Three Questions Worth Asking Directly
Three specific questions tend to produce accurate answers quickly.
Can the Whole Site Be Used by Keyboard Alone?
This means using Tab, Shift+Tab, Enter, Space, and the arrow keys to reach every link, button, form, and interactive element without a mouse. Keyboard failures such as focus trapped in a dropdown, links skipped in the tab order, or a modal that cannot be dismissed are common. Automated scans rarely catch them. W3C says that some checks cannot be automated.
Has the Site Been Tested with a Screen Reader?
Screen readers interpret a site’s HTML and announce it to users who cannot see the screen. In WebAIM’s 2026 survey of 1,780 screen reader users (a self-selected sample), JAWS, NVDA, and VoiceOver were the most used desktop tools.
A site can look acceptable and still announce form fields without labels or images without descriptions. WebAIM’s 2026 scan of one million home pages used an automated checker and found missing form input labels on 51% and missing alt text on 53.1%. Screen reader testing takes hours, not minutes, and produces findings that visual inspection never reveals.
Do the Forms Have Meaningful Error Messages?
When a field has an error, what does the message say, and where does it appear? “An error occurred” fails WCAG 3.3.1 Error Identification, which requires the error to be described in text. “Please enter a valid email address in the format [email protected]” meets it, and 3.3.3 Error Suggestion asks for a correction hint where one is known. The error text also needs to be programmatically tied to its field so assistive technology announces it. The answer shows whether form accessibility was designed or assumed.
Reading the Answers
When a developer can describe the testing process, identify what was found, and confirm what was fixed, accessibility has been addressed with rigor. That does not guarantee full conformance, but it indicates work above the automated-scan minimum.
When the answers are vague, the honest conclusion is that the site’s accessibility status is unknown. None of this faults the developer. Accessibility is a specialized discipline, and many talented developers have not worked in it in depth. It does mean the site needs a proper evaluation before anyone can state its status with confidence.
The goal of the conversation is to establish what is known. A developer who has not done manual testing will say so when the questions are specific, and one who has can describe the work.
Getting an Independent Assessment
When the answers show the site has not been thoroughly evaluated, an independent audit by someone whose job is accessibility is the clearest path to an accurate picture. The W3C evaluation methodology notes that evaluation draws on expertise in assistive technologies, which a general web developer may not have. The relationship with the developer does not have to turn adversarial. A structural engineer reviews what a general contractor built for much the same reason: a specialist finds what a generalist may lack the frame of reference to see.
A good audit produces a documented inventory of findings mapped to WCAG 2.2 AA criteria, with remediation guidance. W3C’s report template asks for links to each success criterion and a recommendation for each item that fails. A structured deliverable like that gives the developer specific, verifiable changes to make. The Small Business Owner’s Guide to Website Accessibility covers the wider picture for a small service business, from legal obligations to technical standards.
For a business unsure of its current status, the COREaccess™ Accessibility Leadership System covers evaluation, remediation, training, and monitoring, and a 15-minute conversation is a practical first step.