What HTML attributes and elements make a banner accessible to screen readers?

This tests semantic HTML for decorative and informative images. A strong answer names img alt, heading levels, and a landmark region such as aside with aria-label. A red flag is relying on CSS or divs without text alternatives.
What's really being asked
This question evaluates whether you understand how non-interactive promotional content is exposed to assistive technology. Screen readers rely on programmatic labels, semantic elements, and heading hierarchies to announce purpose and structure. The interviewer wants to see that you do not treat accessibility as an afterthought applied only to interactive controls.
The full answer
A good answer hits four things in order. First, the image must have an alt attribute. If the image conveys the promotional message, the alt should be a concise description of that message. If the image is purely decorative, use an empty alt so the screen reader ignores it. Second, the text should live in a proper heading element such as h2 rather than a styled div, because headings provide navigable structure. Third, the banner should be wrapped in a landmark region such as aside or section with an aria-label or aria-labelledby attribute pointing to the heading, which allows screen reader users to jump to the region via landmark shortcuts. Fourth, if the banner acts as a link, the anchor or button should have an accessible name that combines the image alt and the heading text or uses aria-labelledby to reference both.
The mistakes people make
A common wrong answer is using generic div and span elements with CSS alone and claiming the visible text is enough. Another red flag is omitting the alt attribute entirely or writing unhelpful alt text such as image or banner. Some candidates suggest title attributes as the primary label, which is unreliable because many screen readers ignore them or expose them inconsistently. A third wrong pattern is wrapping the entire banner in a link but providing no text alternative, leaving the screen reader to announce only the URL.
What usually comes next
An interviewer might ask how you would handle a banner that auto-rotates, which introduces motion and focus management concerns. They might also ask whether you would use role equals banner or treat the promotional block as a complementary landmark. Another follow-up is how you would test your markup with a screen reader or automated tool.
A concrete example
Imagine a summer sale banner with a photo of sunglasses and a headline reading Summer Sale Up to 50 Percent Off. The markup would be an aside element with aria-labelledby pointing to an h2 id equals promo-heading. Inside, an img src equals sunglasses.jpg alt equals Summer sale up to 50 percent off on sunglasses. The h2 contains the visible headline. This gives screen reader users a landmark region labeled by the heading, an image with a meaningful alternative, and a navigable heading level.
Interview question
A promotional banner has a headline and an image conveying the sale message. Which markup pattern best ensures screen reader users can navigate to and understand it?
- a.Wrap the banner in an aside with aria-labelledby pointing to an h2 heading, and give the image a concise descriptive alt attributeCorrect
- b.Wrap the banner in a div with CSS styling, add a title attribute to the image, and mark the headline with a styled span
- c.Wrap the entire banner in a link with no text content, relying on CSS background images and colors to display the message
- d.Place the banner in a section with role="banner", use a paragraph with class="heading" for the text, and set alt="banner" on the image
Why? this is the answer
The aside creates a complementary landmark navigable by screen readers, the h2 provides a programmatic heading structure, and descriptive alt conveys the image's message. The most tempting distractor uses a title attribute and styled span, but title is inconsistently exposed to screen readers and spans lack the navigable semantics of real headings.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
- #accessibility
- #html
- #screen-readers
- #semantic-html
- #aria
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