Sample questions
AccessibilityDifficulty 1
Why is a native <button> element usually preferred over a clickable <div> for an interactive control?
- aBecause a plain
<div> cannot be styled to visually resemble a button without a large amount of extra CSS - bBecause
<button> elements are painted faster by the browser than generic <div> elements are - cBecause a native
<button> is keyboard-focusable and operable and exposes a button role to assistive tech✓ - dBecause the HTML specification forbids attaching a click handler to a non-interactive
<div> element
Explanation:A native <button> gives you keyboard focus, Enter/Space activation, and a screen-reader-announced button role with no extra work. A <div> gets none of that automatically; styling it (a) is possible with CSS, and attaching a click handler to a <div> is allowed (d) — it just is not accessible.
AccessibilityDifficulty 1
What is the primary purpose of the alt attribute on an <img> element?
- aTo provide a text alternative describing the image for users who cannot see it✓
- bTo display a visible caption underneath the image for every visitor to the page
- cTo improve how quickly the image file is downloaded and decoded by the browser
- dTo set the tooltip text that appears when the mouse pointer hovers over the image
Explanation:alt gives screen-reader users, and cases where the image fails to load, a text equivalent of the image's content. It is not a visible caption (b) and not the hover tooltip — that is the title attribute (d).
AccessibilityDifficulty 2
<!-- A -->
<div class="btn" onclick="save()">Save</div>
<!-- B -->
<button class="btn" onclick="save()">Save</button>
Both controls call
save() when clicked with a mouse. Which statement is correct?
- aThey are equivalent, because the
onclick handler fires the same way for both elements - bA is better, because a
<div> can be styled more flexibly than a <button> element - cBoth are inaccessible, because inline
onclick handlers are completely ignored by screen readers - dOnly B is reachable by Tab and activatable with the keyboard; A needs extra work to match it✓
Explanation:The <button> is focusable and responds to Enter/Space out of the box, so keyboard and screen-reader users can use it. The <div> responds only to mouse clicks unless you add tabindex, a role, and key handlers — inline onclick itself is not ignored (c), it just adds no keyboard support.
AccessibilityDifficulty 2
You have a text input for an email address, with the visible word 'Email' next to it in a separate <span>. A screen-reader user tabs to the field and hears only 'edit text', with no label. What is the correct fix?
- aAdd a
title attribute to the <span> so its text gets announced together with the field - bUse a
<label for="..."> whose for value matches the input's id attribute✓ - cWrap the input in a
<div role="label"> so the browser links the nearby text to it - dPut a
placeholder="Email" on the input so its purpose is announced to the user
Explanation:A <label> with for matching the input's id (or a <label> wrapping the input) creates a programmatic association, so the field is announced as 'Email'. A placeholder (d) is not a reliable label — it disappears on typing and is inconsistently announced — and there is no role="label" (c).
AccessibilityDifficulty 1
What does the aria-label attribute do?
- aIt sets a visible text label that is shown next to the element on the screen
- bIt marks the element as decorative so that assistive technology skips over it
- cIt provides an accessible name for the element that assistive tech announces✓
- dIt stores a longer help description that is shown only when the element is focused
Explanation:aria-label gives an element an accessible name that screen readers announce, without showing anything on screen — useful for icon-only buttons. It is not visible (a), and it does not hide the element (b); that is what aria-hidden does.
AccessibilityDifficulty 2
A page uses a small decorative swirl image purely for visual flourish; it carries no information. How should its <img> be marked up for accessibility?
- aGive it a descriptive
alt such as alt="decorative swirl divider between the two sections" - bLeave the
alt attribute off entirely so the browser can decide how to announce it - cAdd
role="img" plus an aria-label describing the swirl for screen-reader users - dGive it an empty
alt="" so assistive technology skips it as decorative✓
Explanation:An empty alt="" tells screen readers the image is decorative and can be ignored, avoiding noise. Describing a meaningless flourish (a) adds clutter, and omitting alt entirely (b) makes many screen readers read the file name instead of skipping it.