Which ARIA attribute fixes an icon-only button missing its screen reader name?

Tests knowledge of accessible names for interactive elements lacking visible text. Answer: aria-label on the button describing its function, plus aria-hidden on the decorative icon. Red flag: suggesting alt text on the SVG or title attributes as the fix.
WHAT THIS TESTS: This question tests your understanding of accessible naming for interactive elements, specifically the pattern of providing a programmatic name for icon-only controls. Screen readers announce the accessible name of a button to users. When a button contains only a visual icon and no text node, it lacks a default accessible name, rendering it silent or unidentifiable to assistive technology. The interviewer wants to see that you know the specific ARIA attribute used to inject a name when visible text is unavailable, and that you understand the surrounding markup hygiene needed to avoid double-speak or focus bugs.
A GOOD ANSWER COVERS: First, name the attribute explicitly: aria-label. Second, place it directly on the button element, not on the icon inside it, because the button is the interactive control that must expose its name in the accessibility tree. Third, give the attribute a concise, action-oriented string that describes what the button does, such as Close dialog or Add to cart, rather than a vague label like button or icon. Fourth, hide the decorative icon from assistive technology by adding aria-hidden true and focusable false to the SVG or image element so the screen reader does not attempt to announce the icon separately or treat it as a tab stop.
COMMON WRONG ANSWERS: A red flag is suggesting alt text on an SVG. SVG images do not reliably expose alt attributes as accessible names in all browser and screen reader pairings, and the attribute belongs on the interactive button anyway. Another mistake is proposing the title attribute, which is not consistently announced by screen readers and is inaccessible to many keyboard-only users. Some candidates suggest aria-labelledby but cannot describe a visible label to reference; since the bug states there is no visible text, aria-label is the pragmatic choice here. Finally, omitting aria-hidden on the icon can cause the screen reader to announce the button name plus the icon file name or title, creating a confusing experience.
LIKELY FOLLOW-UPS: An interviewer might ask when to prefer aria-labelledby over aria-label. The correct distinction is that aria-labelledby references visible text in the DOM and is the preferred priority, while aria-label is reserved for situations where no visible label exists. They might also ask about the difference between aria-label and aria-describedby, which provides supplementary descriptive text rather than the primary accessible name. You could also be asked how to test this, in which case you should mention using a screen reader like NVDA or VoiceOver, or inspecting the browser accessibility tree.
ONE CONCRETE EXAMPLE: A modal dialog contains an X icon button to dismiss it. The markup should be a button element with aria-label equals Close, containing an SVG with aria-hidden true and focusable false. The SVG renders the visual X, but the screen reader announces Close button, giving the user a clear, actionable name. The JavaScript click handler then calls dialog dot close.
Source: developer.mozilla.org
Read the original → developer.mozilla.org
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.