Sample questions
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 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.
AccessibilityDifficulty 2
What does the guideline 'No ARIA is better than bad ARIA' mean in practice?
- aYou should avoid ARIA completely, because native HTML can already express every possible widget
- bIncorrect ARIA can override native semantics and mislead users, so wrong ARIA is worse than none✓
- cARIA attributes slow the page down, so removing all of them always improves performance
- dOnly senior developers should be allowed to add ARIA attributes to a production codebase
Explanation:Wrong ARIA (a misused role, a stale state) overrides an element's real semantics and actively lies to assistive tech, which is worse than leaving correct native semantics alone. It does not mean ARIA is never needed (a) — it means use it correctly, and prefer native HTML first.
AccessibilityDifficulty 2
A developer turns a <div> into a clickable card by adding an onclick handler and some CSS. Mouse users can click it, but keyboard users cannot reach or activate it. Which set of additions makes it keyboard-accessible?
- aAdd
tabindex="0", an appropriate role, and a keydown handler for Enter/Space✓ - bAdd
tabindex="-1" so the card enters the normal Tab order the way a link does - cAdd
cursor: pointer in CSS so the browser starts treating the element as interactive - dAdd an
aria-label so screen readers are able to find and then activate the card
Explanation:A generic <div> needs three things to behave like a control: focusability (tabindex="0"), a role so it is announced correctly, and key handling for Enter/Space. tabindex="-1" (b) makes it focusable only via script, not Tab; cursor: pointer (c) is purely visual; aria-label (d) names it but does not make it focusable or operable.
AccessibilityDifficulty 2
:focus {
outline: none;
}
A stylesheet contains this global rule to get rid of the 'ugly' focus ring. Why is this an accessibility problem?
- aIt disables mouse hover styles as a side effect on every interactive element on the page
- bIt applies only to links, so buttons and inputs are left with an inconsistent focus style
- c
outline cannot be styled, so this rule is silently ignored by every modern browser anyway - dKeyboard users lose the visible indicator that shows which element is currently focused✓
Explanation:The focus outline is how keyboard users see where they are on the page; removing it globally leaves them navigating blind. If the default ring looks bad, replace it with a visible custom style (outline or box-shadow) rather than removing it — it is fully styleable, so (c) is false.