Why can the same screen behave differently under two assistive technologies, and what does that do to the claim that it works with a screen reader?
answer
- You do not own the whole chain
- Four layers between structure and speech
- Some products repair your mistakes
- Two verdicts: criterion failure or support gap
- A claim names combinations and versions
basics
~20 sWhat a user hears comes from a stack: the structure you expose, the platform layer beneath it, the assistive technology's own interpretation, and the user's settings. Every layer varies, so that claim describes one combination at one moment, not the screen.
solid answer
~50 sThe words a user hears are produced by a chain, not by your screen alone: the structure the interface exposes, the platform layer that carries it, the assistive technology that interprets it, and the user's own verbosity and mode settings. Each link has versions and its own behaviour, and some assistive technologies repair common authoring mistakes, so a defect can be invisible under one and fatal under another. That makes **"it works with a screen reader" a statement about one combination at one moment**, not about the screen. The way out is to keep two verdicts apart. A **criterion failure** — missing structure, a control that reports nothing, an order that misleads — is portable, is yours, and is what a conformance claim rests on. A **combination-specific misbehaviour** is a support gap: record the exact combination and versions, and work around it only when that does not break the criterion for everyone else.
go deeper
Know that assistive technologies are separate products with their own behaviour and settings, so what one person hears is not necessarily what another hears from the same screen.
Explain the chain from exposed structure through the platform layer to the assistive technology and the user's settings, and why some products quietly compensate for authoring mistakes that others expose.
Separate a criterion failure from a support gap in front of the interviewer, and describe a coverage strategy you can actually staff: platform families over product counts, combinations recorded on every report, workarounds time-boxed and justified.
Own the claim itself. Decide what the organisation is willing to state publicly, which technologies it relies on, and how scarce specialist time is spent on the ambiguous minority rather than on defects teams should be catching themselves.
## The stack between your structure and the user's ears Nobody experiences your screen directly. Four layers sit in between, and each one can change what is finally spoken: 1. **What the interface exposes** — the structure, the names, the roles and states you actually publish. This is the only layer you own outright. 2. **The platform's accessibility layer** — the operating system's mechanism for carrying that information to other software. Different platforms model the same concepts differently, so the same idea is expressed in different shapes on each. 3. **The assistive technology** — which reads that model, applies its own heuristics about what is worth saying, in what order, and how much of it, and then speaks or brailles the result. 4. **The user's configuration and habits** — verbosity, punctuation, speaking rate, which navigation mode they favour, whether they have turned off announcements of a whole class of thing. A single screen therefore has no single behaviour. It has a behaviour *per combination*, and the number of combinations is larger than any team can enumerate. ## Why two products disagree about the same screen - **They apply different heuristics.** Two assistive technologies reading identical structure can decide differently about what is redundant, what to announce on entering a group, and how much context to repeat. - **Some repair mistakes and some do not.** Several products infer a sensible reading for common authoring errors. That is good for users and dangerous for teams, because it hides defects: the screen seems fine until someone uses the product that does not compensate. - **Versions move.** Both the assistive technology and the host application it reads through change over time, and a behaviour that a workaround depended on can disappear in a release you do not control. - **The user changed the settings.** Verbosity alone can be the difference between hearing a control's state on every visit and never hearing it at all. ## Two verdicts, and only one of them is yours The single most useful discipline here is refusing to collapse these into one bug queue: | Symptom | Verdict | What you do | What the claim can say | |---|---|---|---| | Structure missing, control reports nothing, order misleads | Criterion failure | Fix it; it is reproducible without any assistive technology | It is fixed, for everyone | | Correct structure, one product announces it oddly | Support gap | Record product, host and versions; report upstream; work around only if the workaround harms nobody | Name the combination tested | | Correct structure, user has turned the announcement off | Configuration | Nothing to fix | Out of scope | The reason this matters is not bookkeeping. A team that treats every combination-specific oddity as a defect ends up hand-tuning its structure to one product's quirks, which is how screens get worse for everybody else — and how a workaround quietly becomes a criterion failure when that product's next release changes. ## A claim you can defend The standard itself anticipates this. Conformance is claimed against the **success criteria**, not against any product, and its conformance requirements only allow you to rely on technologies that are **accessibility supported** — a defined term meaning users' assistive technologies actually work with them. So a defensible statement has three parts: what you conformed to and at which level, which technologies you relied on, and which combinations you actually exercised. "It works with a screen reader" has none of those and should be challenged wherever it appears — in a status report, in a supplier's response, or in your own team's definition of done. ## Testing responsibly without owning the matrix Assume you cannot cover the matrix: a museum with six product teams and a single part-time accessibility specialist certainly cannot. What survives that constraint: 1. **Test against the criteria first.** Most defects are reproducible with no assistive technology at all — structure read in its own order, every control reached without a pointer, every state reported. In the museum's 27-item backlog, 19 items were of this kind, and all 19 would have been found by any competent reviewer on any platform. 2. **Cover platform families, not product counts.** Two products on the same platform tell you less than one product each on two different platforms, because the interesting variation lives in the platform layer. 3. **Record the combination in every report.** A bug that says "announced wrongly" without the product, the host and the versions cannot be reproduced, retested or reported upstream. 4. **Spend the specialist on the ambiguous cases.** Teams can own criterion failures themselves; the scarce expert should be deciding which of the remaining 8 items are genuine support gaps and which are the product behaving reasonably. 5. **Get real users involved when the stakes justify it.** No matrix substitutes for someone who uses their own configuration daily, and their judgement about what is merely odd versus genuinely blocking is worth more than any count of passing checks.
- A defect appears under one assistive technology only. How do you decide whether to work around it?First confirm the structure is actually correct against the criteria; if it is not, fix that and retest, because most single-product defects are ordinary defects that one product happened to expose. If the structure is right, weigh the workaround: it is acceptable when it is invisible to everything else, and unacceptable when it distorts the structure to suit one interpretation. Record it as owned by the product, report it upstream, and set a date to remove it.
- Why is testing two assistive technologies on the same platform weaker coverage than one on each of two platforms?Because much of the variation you are trying to detect comes from the platform layer that carries the information, and two products on one platform share it. Different platforms model the same concepts differently, so a structure that expresses your intent well on one can lose a distinction on another. Spread thin coverage across platform families first, then add depth within a family if you have budget left.
- A supplier's report says the product was tested with a screen reader and passed. What do you ask for?Ask what it was tested against, not just what it was tested with: which standard and level, which criteria were evaluated, and by what method. Then ask which combinations were exercised, with versions, and how many findings were criterion failures rather than product-specific oddities. A report that cannot separate those two categories has not established anything portable about the product.
It is like judging a recording by one pair of headphones. If it sounds wrong, the question is always whether the master is bad or that pair is unusual — and the answer changes what you fix.
saying these in an interview costs you the question
- Treats one passing assistive-technology session as proof of conformance
- Assumes all screen readers announce the same structure identically
- Hand-tunes structure to one product's quirks and calls it a fix
- Blames the assistive technology for a genuine structural defect
- Reports a bug without naming the combination or the versions
- Believes automated checks cover what the combinations disagree about