Checklist

A practical checklist drawn from the rest of this site. It is a prompt for review, not a replacement for the methodology. A satisfied line does not prove the product is usable, so pair this with manual and user testing.

Interface basics

• Every control has a clear accessible name, including send, stop, regenerate, copy, and the rating buttons.
• The whole task works with the keyboard alone, with no traps.
• Focus is never lost or thrown to the top of the page when content arrives.
• Nothing important is carried by color alone.

Generated output

• Generated text uses real headings, lists, and tables, not styled containers that only look like them.
• Generated images have a reviewed, context-aware text alternative.
• Generated links and files are real, focusable elements rather than plain text.
• Markup is validated and sanitized before it reaches the page.

Streaming output

• Streamed text is announced through one pre-existing polite live region.
• Announcements come in meaningful chunks, not one per token.
• Focus stays where the user put it while the answer streams.
• A keyboard-operable stop is available while the answer is still streaming.

Uncertainty

• When an answer may be wrong, that is stated in text, not by color or faint styling.
• A confidence cue or warning is tied to the answer in the accessibility tree.
• Sources and provenance are real, perceivable text.

Agent actions

• The agent announces its meaningful steps as it acts.
• The user can stop the agent at any point with the keyboard.
• Actions are reviewable and reversible, with a history.
• Anything the agent produces is rendered as accessible content.

Decision outputs

• The decision, its reasons, and the next steps are structured text.
• An accessible, human-operated way to question or appeal the decision exists.
• The decision has been checked for bias against disabled people, not only for interface conformance.

Process

• A sampling method and a date are recorded for the generative output, along with the model version.
• The product has been tested with automated tools, by hand, and with real assistive technology.
• The product has been tested with disabled people on real, end-to-end tasks.
• A model change or a prompt change triggers a re-test.

Audience: Accessibility Specialist

Use this as a floor, not a ceiling. Every line here can be satisfied while a real user still fails the task, which is why the process section ends with manual, assistive-technology, and user testing rather than a tool result. When you turn this into an audit, attach the sample you tested and the model version, so the next reviewer knows what the ticks actually covered.

Audience: Product Manager

This works well as a launch gate that sits beside security and privacy. Treat the process section as the part that keeps it honest over time, since it ties re-testing to model and prompt changes. A green checklist from a single run is a snapshot, so date it and re-run it when the generation behavior changes.

Further reading

• Testing methodology for how to sample and when to re-test.
• The Patterns section for the detail behind each line here.