# WCAG Perceivable Perceivable is the first WCAG principle. It means users can take in the content with whatever sense or assistive technology they rely on. If information is available only one way, such as on screen by sight, then people who cannot use that way are shut out. AI raises this in a sharp form, because the content is generated at runtime and is often visual, spoken, or constantly changing. ## Key points - Perceivable means every user can take in the content, whatever sense or assistive technology they use. - Generated images need text alternatives, but model-written alt text is a draft to review, because good alt text depends on context. - Generated speech, audio, and video need captions and transcripts, and automatic captions need review before you rely on them. - Generated text must use real headings, lists, and tables, not styling that only looks structured. - Streaming responses are status messages that should reach assistive technology through a live region without moving focus. ## Text alternatives for generated images If your product generates images, each one still needs a text alternative under criterion 1.1.1. The hard part is that a stored or model-written description is not automatically a good alt text. Alt text depends on context. The accessibility writer Eric Bailey [makes the point](https://ericwbailey.website/published/thoughts-on-embedding-alternative-text-metadata-into-images/) that the same image needs different descriptions depending on why it is on the page, and a model cannot know the surrounding conversation. So treat AI-written alt text as a draft that a person reviews, not as a finished answer. Equal Entry [found](https://equalentry.com/alt-text-accessibility-ai/) that AI alt text tends to be generic and formulaic and to miss the purpose of the image. AI is useful here as a way to scale a first pass inside a human-checked workflow. See [Generated content](https://artificia11y.ds.house/patterns/generated-content/). ## Captions and transcripts for generated media AI that produces speech, audio, or video needs captions and a transcript, under the 1.2 criteria. Automatic captions are a reasonable starting point, but they are often wrong, so they need review before you rely on them. The same holds for AI-generated audio descriptions of video. A draft that a person corrects is fine. An unchecked machine output presented as the final version is not. ## Structure of generated text Generated text has to use real structure, under criterion 1.3.1, Info and Relationships. That means actual headings, lists, and tables, not text that only looks like them through styling. A screen reader user moves through a page by its structure, jumping between headings and lists. A wall of text with visual-only formatting cannot be navigated this way. This is one of the most common failures in AI output, and it is measurable. A Microsoft [evaluation](https://microsoft.github.io/a11y-llm-eval-report/) found that unguided model HTML passed automated accessibility checks only 12 percent of the time, climbing to 86 percent only when the model was told to produce accessible markup. Structure does not appear on its own. You have to ask for it and check it. ## Contrast and visual presentation The interface around the model has to meet contrast and related requirements, under the 1.4 criteria, including 1.4.3 for text contrast. Pay extra attention to generated content that sets its own colors, such as charts, highlighted text, or syntax coloring, because the model may pick combinations that fail. ## Status messages for streaming output When a response streams onto the page, each update is a status message under criterion 4.1.3. It should reach assistive technology without moving the user's focus. This is the job of a live region. Live regions also sit under the Robust principle, so the details live in [WCAG Robust](https://artificia11y.ds.house/guidelines/wcag-robust/) and in the [streaming pattern](https://artificia11y.ds.house/patterns/dynamic-streaming-output/). > [!ENGINEER] > > Three habits cover most of Perceivable for AI. > > - Give generated content real semantics, so headings are headings and lists are lists, because the model will hand you a flat blob if you let it. > - Run AI-written alt text and captions through a review step rather than shipping them raw. > - Announce streamed text through a pre-existing, polite live region, and read [Scott O'Hara on live regions](https://www.scottohara.me/blog/2022/02/05/are-we-live.html) before you build it. The native [output element](https://www.scottohara.me/blog/2019/07/10/the-output-element.html) is often enough. > [!ACCESSIBILITY-SPECIALIST] > > Remember that 1.1.1 only checks that a text alternative is present and exposed. It cannot tell you the description is accurate or right for the context, and for generated images that is exactly where the risk sits. Build alt text quality into your sampling. Pull a set of real generated images and judge whether the descriptions would actually help, rather than confirming that the alt attribute is non-empty. > [!SELF-ADVOCATE] > > If you use a screen reader, the difference between structured and unstructured AI output is the difference between a page you can skim and a page you have to sit through word by word. Generic alt text such as "image" or "screenshot" is the same kind of problem. It technically passes, but it tells you nothing. These are worth reporting in specific terms, naming the tool, the assistive technology, and what you expected to hear. ## Further reading - Scott O'Hara on [live regions](https://www.scottohara.me/blog/2022/02/05/are-we-live.html) and the [output element](https://www.scottohara.me/blog/2019/07/10/the-output-element.html). - Eric Bailey on [why alt text is context dependent](https://ericwbailey.website/published/thoughts-on-embedding-alternative-text-metadata-into-images/). - The Microsoft [accessibility LLM evaluation report](https://microsoft.github.io/a11y-llm-eval-report/) on how often generated markup is accessible.