An accessible description is the extra line a screen reader reads out after the name, and the word the specification uses for what it does is complements. The name says what a control is for. The description says what else somebody needs to know before they use it, and nothing in a description can touch the name. That one rule is why aria-describedby is the safe way to attach context to a button and aria-label is not. Four sources feed the description and the first one that applies wins, in the order aria-describedby, aria-description, a small set of HTML elements, then the title attribute. First match wins even where the match is empty, which is the trap in it. Point aria-describedby at an id that is not on the page and you get no description at all, and the title attribute that would have worked is never reached.
In practice
Reach for a description when a control already shows the right words and still needs something extra. A Send button that should say we reply within one business day. A password field with rules attached. A link whose destination opens in a new tab. Write the extra text into the page where everybody can read it, give that element an id, and point aria-describedby at the id. The visible label survives, so somebody driving the browser by voice can still say the words printed on the button, and a screen reader user hears the label and then the context.
Two failures here are silent, and both come from the same first-match-wins rule. A description reference that resolves to nothing produces an empty description and stops, so the title attribute that would have worked is never consulted and no error is reported anywhere. And aria-describedby runs the name computation on whatever it points at rather than the description computation, so an aria-label sitting on the referenced element wins over that element's visible text. Check what the browser actually computed rather than what the markup looks like it says.
Keep the description short and keep the important part out of it. A description is announced after the name and it is the part a reader is most likely to interrupt, so anything they cannot finish the task without belongs in the page itself. The title attribute is the last source on the list for a reason. It never appears on touch, it is unreliable for keyboard users, and it is the weakest place to put anything that matters.
Why it matters
The description is the escape from the commonest ARIA injury on the web, which is an aria-label quietly renaming a control that already had a perfectly good visible label. That renaming breaks voice control, because somebody saying click Send is naming the word they can see, and it hides the change from everybody who can read the page. A description cannot do that. It only ever adds. So the question to ask on any control that needs more words is whether you are replacing the name or adding to it, and if the answer is adding, there is exactly one attribute for the job.
The reference that resolves to nothing
A field carries aria-describedby pointing at help-text, and a later refactor renamed that element to hint-text. The description is now empty. It is not missing, which would fall through to the next source. It matched first and came back with nothing, so the browser stops there and the field is announced with no help at all. Nothing in the console says a word about it.
Where this shows up on the site
Related terms
- Accessible nameThe accessible name is what assistive technology announces an element as, the words a screen reader speaks when it lands on a button or a link.
- alertdialogAn alertdialog is a dialog that interrupts, and it is the role for a message somebody has to answer before anything else happens.
- TooltipA tooltip is a small label that appears when something takes hover or focus.
- Accessibility treeThe accessibility tree is a second structure the browser builds alongside the DOM, holding one object for every part of your page that has to be exposed to assistive technology.
Knowing the word is the easy part.
Find out where your own site stands. The free scan checks 10 pages in a real browser against all 90 supported automated rules, separates 27 best-practice checks from its WCAG findings, and names the rule behind every result.