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.

The World Wide Web Consortium’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. 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.

The World Wide Web Consortium’s the ARIA twenty-two technique demonstrates a status region with the status role. Its default announcement priority is polite, and it does not require moving keyboard focus. 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.

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. the World Wide Web Consortium’s alert pattern also cautions against frequent interruptions and says ordinary alerts should not take keyboard focus. A dialog that must interrupt work requires a different interaction pattern.

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.

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.