Questions to Ask About Accessibility
Questions for the team, vendor, or consultant responsible for accessibility on a digital product, covering which standard applies, keyboard and screen reader support, testing, and who owns the work.
The questions
Open any question for the note
Which accessibility standard are we holding ourselves to, and at what conformance level?
Why ask it
A usable answer names a version and a level, such as WCAG 2.2 AA, and says which platforms it covers. "We follow best practices" means no target exists, so no piece of work can be called finished or failed.
Who owns accessibility here, and at what point in a project do they get involved?
Why ask it
Ownership that appears only at the end of a project produces retrofits and reopened tickets. Answers that place a checkpoint inside design review and code review mean accessibility is part of ordinary work rather than a cleanup phase.
What do we already know is broken, and how long has it been on the list?
Why ask it
This separates teams that keep a running list of known barriers from teams that only learn about them when someone complains. The age of the oldest ticket tells you how the list is actually prioritized.
Which disabilities have we designed for so far, and which have we not?
Why ask it
Screen reader support is what most teams reach for first because it is the most discussed. What gets left out, motor, cognitive, low vision, or hearing, is where the untested risk sits.
Have disabled users tested this product, and what did they tell us?
Why ask it
Automated tools cannot judge whether a label makes sense, so they miss a large share of real barriers. If nobody can describe a session with an actual screen reader or switch user, confidence in the product is guesswork.
Can you get through the main task flow using only a keyboard?
Why ask it
A keyboard-only walkthrough surfaces traps quickly: menus that cannot be closed, dialogs that leak focus, controls built from unfocusable divs. Notice whether they try it live or promise to check later.
What happens on this page with a screen reader, read from the top down?
Why ask it
Listen for whether headings come through as structure, whether images announce anything useful, and whether the reading order matches the visual layout. A team that has never listened will describe intent instead of output.
When someone fills in a form wrong, how are they told, and can that be heard as well as seen?
Why ask it
An error state that only turns a border red is invisible to someone who cannot distinguish the color or is not looking at that field. Ask whether the message is tied to the specific input and announced the moment it appears.
Where does our text drop below readable contrast, and who signed off on it?
Why ask it
Contrast failures are usually deliberate: grey placeholder text, pale disabled states, brand colors on white. The name attached to the decision tells you whether design taste or accessibility wins arguments in this organization.
Do we caption and transcribe our video and audio, and who does that work?
Why ask it
Captions get promised and then dropped when a launch slips, because no single person owns them. Only an answer that names the person or vendor and the point in the publishing pipeline will survive a deadline.
What happens if someone zooms the browser to 200 percent or raises their default font size?
Why ask it
Fixed pixel heights and absolute positioning break here: text clips, buttons slide off screen, sticky bars cover the content underneath. This is one of the few answers you can verify on the spot in about a minute.
How do our animations and autoplaying content behave for someone who has asked their system for reduced motion?
Why ask it
Parallax and autoplaying carousels can cause nausea and headaches for people with vestibular conditions. If flipping the system setting changes nothing in the product, nobody has wired it up.
What is the smallest thing someone has to tap on mobile, and how did we pick that size?
Why ask it
Small targets punish anyone with tremor or limited dexterity, and mis-taps are the most common complaint about touch interfaces. A round number with no reasoning behind it usually came from the visual design, not from anyone trying it.
Which components did we build ourselves instead of using native HTML, and why?
Why ask it
Custom dropdowns, tabs, and date pickers are where keyboard and screen reader support usually breaks, because native elements bring that behavior for free. A good answer explains what the custom version gains that justifies rebuilding all of it.
What accessibility testing happens before a release, and how much of it is done by a person?
Why ask it
Scanners catch mechanical failures like missing labels and low contrast, and little else. If manual testing is missing from the answer, expect a product that passes an audit while remaining awkward to actually use.
What stops a fixed issue from reappearing three releases later?
Why ask it
Without a check in the build or a test case, fixes decay quietly as components get refactored. Look for something automated or written down, not an intention to stay careful.
When we bring in a third-party widget or vendor tool, what do we ask them to prove?
Why ask it
Vendor conformance reports are often years out of date or written by the vendor's own marketing team. Teams that ask for the report and then spot check one flow themselves are the ones who catch the gap.
Who writes our alt text and link text, and what guidance do they have?
Why ask it
Left to whoever is nearest the CMS, alt text becomes filenames and the word "image", and links become "click here". Ask what the guidance says about purely decorative images, because that detail shows whether real guidance exists.
Has anyone ever complained or taken legal action against us over accessibility?
Why ask it
Complaint history is a matter of record and it shifts priorities faster than any argument from principle. Reluctance to answer is itself worth noting.
If you had one engineer for a month, what would you fix first?
Why ask it
Forced to choose, people name the barrier they believe hurts users most, which is often not what ranked highest in the last audit. The answer also reveals whether a plan exists or only a wish list.
Getting Useful Answers About Accessibility
Practical guidance for the conversation itself
Before you ask
Try the product yourself first
Unplug the mouse and try to complete one important task with the keyboard alone. Zoom the browser to 200 percent. You will arrive with specific broken things to point at, which changes the conversation from opinion to evidence.
Know who you are talking to
A designer can answer for contrast, focus states, and target sizes. An engineer can answer for markup, focus management, and custom components. A product owner answers for budget and priority. Asking the wrong person produces polite guesses.
Ask for artifacts, not assurances
Requests that produce something checkable, an issue list, a test report, a recording of a user session, cannot be answered with confidence alone.
Reading the answers
- A named standard and level beats any description of intent.
- "It is accessible" with no evidence usually means an automated scan came back clean.
- Talk of a future audit and no current issue list means nothing is being tracked today.
- If every example involves screen readers, motor and cognitive access has probably not been considered.
- Someone who can describe a specific user's difficulty in detail has watched a real session.
- Willingness to name what is still broken is a better signal than a clean report.
Common pitfalls
Treating a scanner score as a result
Automated checks find missing labels, low contrast, and invalid markup. They cannot tell you whether a label is comprehensible, whether focus order matches the layout, or whether a task is possible at all. A clean scan and an unusable page coexist easily.
Asking about compliance instead of use
Compliance questions produce compliance answers, often about documents rather than the product. Ask what happens when a person tries to do something, and you learn more in one sentence than a checklist gives you.
Leaving the conversation without an owner or a date
Agreement that something matters costs nothing. Close by asking who is doing which fix and when it lands, then repeat it back so the answer is on the record.