Operations · Guide
Your AI finished. Did the screen-reader user hear it?
Check whether screen reader users receive AI waiting, completion and failure messages while preserving focus and recovery paths.
Your AI finished. Did the screen-reader user hear it?
Original AAHouse explanatory video. AI-assisted conceptual visuals and neural narration; original music.
English transcript · Simplified Chinese Mandarin transcript · Taiwan Mandarin transcript · Hong Kong Cantonese transcript · Macao Cantonese transcript
The page moves, but the user gets no update
Imagine an inquiry assistant for a U.S. equipment-rental business. A customer selects “Generate list,” sees a spinner, and eventually sees “Done.” This is a fictional design review, not a customer incident. A person using a screen reader may receive no equivalent update. The question is whether waiting, completion, and failure are perceivable, not whether the model sounds intelligent.
Explanatory diagram redrawn from the approved article.
Revision one: separate status from results
W3C’s explanation of status messages covers action results, waiting, progress, and errors, while a complete list of search results is not itself a status message.[1] Our recommendation is to keep the list and provide a short update such as “List generated: three items, awaiting your review.” Do not say “Reserved” when only a draft exists. The wording must match the business stage.
Explanatory diagram redrawn from the approved article.
Revision two: make the short update available
W3C’s ARIA22 technique demonstrates a status region with the status role. Its default announcement priority is polite, and it does not require moving keyboard focus.[2] Establish the container before updating its contents. Where the complete short message should be announced, explicitly setting aria-atomic to true can help. Markup does not replace testing in supported environments.
Explanatory diagram redrawn from the approved article.
Revision three: do not interrupt for every token
Streaming AI output may change one token at a time. Our recommendation is to announce meaningful stages instead of treating every change in a long answer as urgent. Let the user choose when to read the answer. W3C’s alert pattern also cautions against frequent interruptions and says ordinary alerts should not take keyboard focus.[3] A dialog that must interrupt work requires a different interaction pattern.
Explanatory diagram redrawn from the approved article.
Revision four: leave a recovery route
If generation fails, a short message could say, “We could not generate the list. Your entries are preserved,” alongside a discoverable retry or human-help option. This is product advice, not a verified claim about an existing application. A disappearing spinner or unexplained “Error” is not a useful recovery plan. Retry behavior must still follow existing duplicate-prevention and approval rules.
Explanatory diagram redrawn from the approved article.
Acceptance: hear the update and finish the journey
Have testers use the supported browser and screen reader through starting, waiting, completion, and failure, then locate results and recovery controls with the keyboard. Record actual spoken text, sequence, and focus location rather than merely checking for attributes. This article proposes a review method. It does not report a customer-system test or establish whole-site accessibility conformance.
Explanatory diagram redrawn from the approved article.