Accessible Description
An accessible description adds helpful details that an element's accessible name does not provide. It can explain a format, limit, or consequence.
accessible name + role + referenced description -> assistive technology output<label for="email">id="receipt-hint"example outputaccessible name + role + referenced description -> assistive technology outputA11YAnother example
An Email field references a visible privacy hint with aria-describedby. Assistive technology can announce the name, role, and description.
Main parts
- 01Visible label
- 02Accessible name
- 03Visible help text
- 04Description reference
- 05Computed description
- 06Assistive output
Use it when
Use a description for helpful details that are not the element's name. Reference visible text when possible.
Do not use it when
Do not use a description instead of a label. Use aria-details when long structured content needs its own navigation.
Name used in code
accessible name + role + referenced description -> assistive technology output Before you ship
Give each field a label that code can read. Link hints and errors, and keep entered values. Check autofill, keyboard order, validation timing, submit states, failure recovery, zoom, and languages.
Outcome: Use Accessible Description to solve this user need without losing the current context. User context: An Email field references a visible privacy hint with aria-describedby. Assistive technology can announce the name, role, and description. Recommended pattern: Accessible Description. Why it fits: Use a description for helpful details that are not the element's name. Reference visible text when possible. Do not use it when: Do not use a description instead of a label. Use aria-details when long structured content needs its own navigation. Product requirements: Define the default, loading, empty, error, success, and recovery states. Keep user input. Give clear feedback after every action. Accessibility and resilience: Use semantic HTML, full keyboard access, and visible focus. Make the layout work when zoomed and support reduced motion. Follow the project’s current rules. Do not add a new UI library unless the project already uses it. Acceptance criteria: The main task works with keyboard only and at 320px width. Focus and status changes are announced. Check loading, failure, retry, cancel, and reduced-motion paths. Evidence and limits (evidence boundary): The standard covers only the listed scope. It does not choose the visual style, product decision, or Vibulary example. Unknowns to confirm: Product wording, data source, analytics events, supported devices and languages, and platform limits.
Check this request
Review the current use of Accessible Description. Definition: An accessible description adds helpful details that an element's accessible name does not provide. It can explain a format, limit, or consequence. Release checks: Give each field a label that code can read. Link hints and errors, and keep entered values. Check autofill, keyboard order, validation timing, submit states, failure recovery, zoom, and languages. Before changing code, report the evidence you found, gaps, severity, and the smallest safe fix.