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; the owner isn't sure how to push back. Here's how to have the conversation with enough specificity to get a real answer.
The conversation goes a predictable way. The business owner raises a concern about accessibility, maybe they received a demand letter, maybe a client mentioned they had difficulty using the site, maybe they read something about ADA requirements. The developer says the site is fine. The owner, who doesn’t have a technical frame of reference, either accepts the answer or ends up in a circular exchange that resolves nothing.
This happens not because developers are being evasive. It happens because “is the site accessible” is too broad a question to produce a useful answer. A more specific question, with specific follow-up questions, produces a much clearer picture.
Start with the Standard, Not the Question
Instead of asking “is our site accessible,” ask “has our site been evaluated against WCAG 2.2 Level AA?”
WCAG 2.2 AA is the specific standard referenced by the ADA’s Office of Civil Rights guidelines for digital accessibility and by the European Accessibility Act. It has sixty-six success criteria. It is measurable, documented, and defensible. “Yes it’s accessible” is not.
A developer who has actually done this work can answer the specific question. They can tell you which criteria were evaluated, how they were tested, and what the outcome was. A developer who hasn’t done this work will typically shift to a different answer, something like “we follow best practices” or “we used accessible design principles”, which is a meaningful signal.
Ask About the Evaluation Method
Follow the initial question with one about method: “Was the evaluation manual, automated, or both?”
Automated scanning tools catch roughly 30 to 40 percent of WCAG issues. The rest require human review. If the developer’s accessibility evaluation consisted of running an automated scan and finding no critical errors, the site has been evaluated against less than half the standard.
If the developer says the evaluation was manual, ask which criteria were covered and whether keyboard navigation was tested. A developer who has done manual keyboard testing can describe it specifically: they went through every interactive element on the site using only the keyboard, verified the focus order was logical, tested all modals and dropdowns for keyboard operability, and checked that the focus indicator was always visible.
If they can’t describe the testing process with that kind of specificity, the manual testing probably didn’t happen at the level of rigor the term implies.
The Three Questions Worth Asking Directly
Three specific questions tend to produce accurate answers quickly.
Can you navigate the entire site by keyboard alone? This means using Tab, Shift+Tab, Enter, Space, and arrow keys to access every link, button, form, and interactive element, without ever touching the mouse. Many sites fail this test in ways that are immediately obvious to someone who tries it. Focus getting trapped in a dropdown, links skipped in the tab order, a modal that cannot be dismissed without a mouse click, these are common failures that automated tools do not catch.
Have you tested with a screen reader? Screen readers like NVDA, JAWS (Windows), and VoiceOver (Mac/iOS) interpret the site’s HTML structure and announce content to users who cannot see the screen. A site that looks visually acceptable may announce form fields without labels, images without descriptions, or navigation landmarks in confusing sequences. Real screen reader testing takes hours, not minutes, and produces findings that no visual inspection reveals.
Do our forms have meaningful error messages? When a form field has an error (wrong format, missing required information) what does the error message say, and where does it appear? “An error occurred” is not accessible. “Please enter a valid email address in the format name@domain.com” is. Screen reader users also need error messages to be programmatically associated with the field they describe, not just visually adjacent to it. Asking this question reveals whether form accessibility has been thought through or assumed.
What to Do with the Answers
If the developer can answer these questions specifically (describing the testing process, identifying what was found, confirming what was fixed) that is a meaningful sign that accessibility has been addressed with real rigor. It doesn’t guarantee the site is fully compliant, but it indicates the work was done at a level above the automated-scan minimum.
If the answers are vague, the honest conclusion is that the site’s accessibility status is unknown. That’s not a criticism of the developer, accessibility is a specialized discipline, and many talented developers haven’t worked in this area with depth. It means the site needs a proper evaluation before the business owner can have any confidence in its compliance status.
The goal of the conversation is not to put the developer on the defensive. It’s to establish what is actually known. A developer who hasn’t done manual accessibility testing will almost certainly say so when the questions are specific, and a developer who has will welcome the chance to describe the work.
Getting an Independent Assessment
If the answers to those questions reveal that the site hasn’t been evaluated thoroughly, an independent accessibility audit (conducted by someone whose job is accessibility, not general web development) is the clearest path to an accurate picture of where things stand.
That audit should produce a documented inventory of findings, mapped to specific WCAG 2.2 AA criteria, with severity ratings and remediation guidance. Not a list of suggestions, a structured deliverable that the developer can use to make specific, verifiable changes.
The developer relationship doesn’t have to be adversarial for this to happen. Bringing in an outside evaluator is standard practice in accessibility-serious organizations, for the same reason a structural engineer reviews what a general contractor built: the specialized eye catches what the generalist, however skilled, doesn’t have the frame of reference to find. The COREaccess™ Accessibility Leadership System covers the full framework — audit, remediate, train, and monitor — for organizations that need documented, standards-based conformance.
The Small Business Owner’s Guide to Website Accessibility covers what accessibility compliance requires for a small service business website, from legal obligations to technical standards. If you’re not confident in your current accessibility status and want a starting point, a 15-minute conversation with COREaccess™ is a practical first step.