Uncertainty and confidence

AI systems produce answers that can be wrong while sounding completely sure of themselves. A sighted user often picks up doubt from subtle cues, such as a hedging phrase or a grayed-out note. A screen reader user gets none of that unless it is in the text and in the accessibility tree. Communicating uncertainty is therefore an accessibility problem, not only a design nicety.

Key points

AI can be confidently wrong, and visual hedging like faint text does not reach screen reader users, so communicating uncertainty is an accessibility problem.
Confident wrongness is structural, not a rare glitch, so plan for the wrong answer.
Put any confidence cue or warning in real text and the accessibility tree, tied to the answer it describes.
Show provenance, such as sources and whether content was generated or retrieved, as perceivable text.
Calibrate the signal so it informs rather than nags, and remember the organization owns what the model says.

Confident wrongness is structural

This is not an occasional glitch you can engineer away. A widely-cited paper argues that large language model falsehoods are best understood as output produced with indifference to truth, rather than as rare errors. Other research has shown model reasoning breaking down as problems get harder. Plan for the wrong answer, and assume some users cannot see whatever visual hedging you add.

Put uncertainty in the text and the accessibility tree

If an answer might be unreliable, say so in words. A faint color, a lighter font, or an icon on its own will not reach a screen reader user. Where you show a confidence level or a warning, make it real text that is announced, and associate it with the answer it describes, for example with aria-describedby, so it is not separated from the content it qualifies. See WCAG Understandable.

Show where the answer came from

Provenance helps everyone judge an answer. Citations, sources, and a note about whether the answer came from the model or from a retrieved document give users something to check. Make that provenance perceivable in the accessibility tree, not implied by styling, and connect it to the rendering rules in Generated content.

Calibrate, do not nag

Uncertainty signaling can itself become noise. A warning on every answer, announced in full to a screen reader user on every turn, is exhausting and quickly ignored. Signal uncertainty where it matters, keep the wording short, and avoid repeating the same caution endlessly. The goal is a cue the user can act on, not a disclaimer.

Someone owns the answer

Uncertainty does not move responsibility onto the user. When a chatbot gives a wrong answer, the organization behind it is accountable. A tribunal held Air Canada responsible for a wrong answer its chatbot gave a customer, rejecting the idea that the bot was a separate party. Treat the model’s output as your product’s output.

Audience: Product Manager

Turn uncertainty into an explicit requirement. For any answer that could be wrong in a way that matters to the user, decide what confidence or verification cue you will show, require it to be real text that reaches screen reader users, and require a path to check or contest the answer. The Air Canada ruling is a useful reminder for stakeholders that the organization owns what the model says, so the cost of hiding uncertainty is real.

Audience: Accessibility Specialist

There is no WCAG success criterion for communicating uncertainty, so anchor findings elsewhere. Frame them against the intent of Understandable, against the transparency duties in the EU AI Act, and against the NIST explainability principles. In testing, confirm that any confidence indicator, citation, or warning is present in the accessibility tree and tied to the relevant answer, rather than being a color a screen reader cannot convey.

Audience: Self-advocate

Trusting an answer you cannot independently check is hard for anyone, and harder when the only sign that it is shaky is a pale gray label or a tone you cannot pick up. The output that earns trust is the kind that states plainly when it is unsure, shows where it got its information, and does so in words a screen reader reads aloud, so you can decide for yourself whether to rely on it.

Audience: Engineer

Expose uncertainty in the accessibility tree, not only in CSS. If you render a confidence score or a warning, make it text, give it an accessible name, and associate it with the answer using aria-describedby so it is announced together with what it qualifies. Keep citation links as real links. Avoid announcing a long disclaimer on every streamed token, and announce the cue once, with the settled response.

Tie the caveat to the answer with aria-describedby so the two are announced together, and render provenance as a real link.

<section aria-describedby="confidence-note">
  <p>Your refund should arrive in 5 to 7 days.</p>
  <p>Based on the <a href="/policy/refunds">refund policy</a>.</p>
</section>

<!-- Real text, announced with the answer, not a color-only badge -->
<p id="confidence-note">Low confidence. This may be out of date, so check your account.</p>