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's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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.
A 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.
Interview question
Which markup pattern correctly gives a screen reader name to a button that contains only a decorative icon?
- a.Put aria-label on the button and aria-hidden="true" on the decorative iconCorrect
- b.Apply aria-label to the SVG icon and omit it from the button
- c.Add an alt attribute to the SVG icon describing the button's action
- d.Use a title attribute on the button to provide its accessible name
Why? this is the answer
The interactive button—not the decorative icon—must expose the accessible name, so aria-label belongs on the button while aria-hidden prevents the icon from being announced separately. Alt text on SVG is unreliable for naming, and title is inconsistently announced and often inaccessible to keyboard users.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
- #accessibility
- #aria
- #screen-readers
- #html
- #ux-research
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on accessibility — each one lists the topics its interview covers.
See open roles