8 Frontend Accessibility Interview Questions and Answers

Short answer: Accessibility (a11y) means designing products so people with visual, hearing, motor, and cognitive disabilities can use them. It matters for three reasons: ethical (people), business (wider audience), and legal (WCAG, ADA, the European Accessibility Act).

In depth:

1. People — about 15% of the population lives with some disability; temporary (a broken arm) and situational (bright sun, a noisy train) limitations affect everyone.
2. Business — more users, better SEO (semantics = clear structure), fewer drop-offs.
3. Law — WCAG 2.x is the de-facto standard; the US has ADA/Section 508, the EU has the EAA; lawsuits over inaccessible sites are real.

⚠️ Common mistake: treating accessibility as a 'feature for a minority' — in reality it improves UX for everyone (the curb-cut effect).

Short answer: Semantic HTML carries role, state, and behavior out of the box (button, nav, input), while ARIA only adds semantics where no native element exists. The first rule of ARIA: if a native element will do the job, use it instead of ARIA.

In depth:

• ARIA provides three things: roles (role="dialog"), states (aria-expanded, aria-checked), and properties (aria-label, aria-controls).
• ARIA does nothing on its own — it only changes the accessibility tree; you still wire keyboard handling and focus yourself.
• A native <button> is already focusable, responds to Enter/Space, and is announced as a button — <div role="button"> makes you rebuild all of that by hand.

⚠️ Common mistake: putting a redundant ARIA role on a native element (<button role="button">) or, worse, overriding it (<h1 role="button">) — that breaks the semantics.

Short answer: Everything interactive must be reachable from the keyboard in a logical order, with a visible focus indicator. Focus order follows DOM order; tabindex="0" puts an element in the tab order, -1 makes it focusable only programmatically, and positive values must never be used.

In depth:

1. Focus order — follows the DOM; don't break it with CSS (order, flex-direction).
2. tabindex — 0 normal flow, -1 focus from JS (e.g. a dialog's heading), positive is an anti-pattern.
3. Visible focus — never remove outline: none without a replacement (:focus-visible).
4. Skip link — first in the DOM; lets users jump past navigation to the content.
5. Focus trap — only inside modals: Tab cycles within, Esc closes.

Tab →  [Skip to content] (hidden until focused)
  ↓
[Logo] → [Navigation] → [Search]
  ↓ (or Skip jumps here)
[ Main content: links, buttons, fields ]
  ↓
[ Footer ]

⚠️ Common mistake: using tabindex="5" to force the 'right' order — a positive tabindex breaks the natural flow for everyone; fix the order in the DOM instead.

Short answer: WCAG is built on four POUR principles: Perceivable, Operable, Understandable, Robust. Success criteria are graded A, AA (the working minimum), and AAA. Normal text contrast must be at least 4.5:1, and large text and UI components at least 3:1.

In depth:

• Perceivable — alt text, captions, contrast.
• Operable — keyboard, no traps, enough time for actions.
• Understandable — plain language, predictability, form help.
• Robust — valid markup, works with assistive tech.

⚠️ Common mistake: judging contrast 'by eye.' Contrast is computed from relative luminance; light-gray text on white almost always fails 4.5:1.

Short answer: A screen reader voices not the DOM but the accessibility tree — a simplified model where each element has a role, an accessible name, and a state. Alt text forms an image's name: informative images are described, decorative ones get an empty alt="".

In depth:

1. Accessibility tree — the browser builds it from HTML+ARIA; the screen reader walks it.
2. Accessible name — derived from content, alt, <label>, aria-label/aria-labelledby.
3. Alt decision: informative → a short description of the point; decorative → alt="" (hide it); functional (icon link) → describe the action, not the picture.

<!-- Informative: what matters in the image -->
<img src="chart.png" alt="Sales rose 30% in Q2">

<!-- Decorative: empty alt so the screen reader skips it -->
<img src="divider.svg" alt="">

<!-- Functional: describe the action -->
<a href="/cart"><img src="cart.svg" alt="Cart"></a>

⚠️ Common mistake: alt like 'image' or 'img_1234.jpg', or no alt on a decorative image — the screen reader will read out the file name.

Short answer: For each widget the APG specifies the required roles, states, and focus management. A modal: role="dialog" aria-modal="true" plus aria-labelledby, move focus inside, trap focus, and Esc closes and returns focus to the trigger.

In depth:

• Dialog — role="dialog", aria-modal="true", aria-labelledby on the heading; on open move focus inside, on close return it to the trigger button.
• Tabs — role="tablist" → role="tab" with aria-selected and aria-controls; content is role="tabpanel"; arrow keys switch.
• Accordion — a header button with aria-expanded and aria-controls pointing at the content section.

<div role="dialog" aria-modal="true" aria-labelledby="title">
  <h2 id="title">Delete account?</h2>
  <button>Cancel</button>
  <button>Delete</button>
</div>
<!-- Focus: inside on open, Tab cycles within,
     Esc closes, focus returns to the trigger -->

⚠️ Common mistake: a 'modal' that leaves focus on the background and lets the content behind it stay reachable by the screen reader and Tab — you need focus management plus aria-modal/inert on the background.

Short answer: Every field needs an associated <label> (via for/id or wrapping), related fields are grouped with <fieldset>+<legend>, and errors are tied to the field with aria-describedby and flagged with aria-invalid="true".

In depth:

1. Label — <label for> explicitly associated with the field; a placeholder is not a label.
2. Grouping — radio buttons and related fields go in a <fieldset> with a <legend>.
3. Errors — the error text gets an id, the field references it with aria-describedby; aria-invalid signals invalidity; use aria-live for dynamic messages.

<label for="email">Email</label>
<input id="email" type="email"
       aria-describedby="email-err"
       aria-invalid="true" required>
<p id="email-err">Enter a valid address.</p>

⚠️ Common mistake: using a placeholder instead of a label — it disappears on input, has weak contrast, and isn't reliably read by screen readers.

Short answer: Automated tools (axe, Lighthouse, WAVE) catch roughly 30–40% of issues — missing alt, low contrast, duplicate ids, unlabeled fields. The rest needs manual keyboard testing and a real screen reader.

In depth:

1. Automation — axe-core in CI/e2e, Lighthouse for audits; fast, but 'green' never means 'accessible'.
2. Keyboard — walk the whole flow with only Tab/Shift+Tab/Enter/Esc/arrows: is everything reachable, is focus visible, are there traps?
3. Screen reader — VoiceOver (macOS/iOS), NVDA (Windows): are names meaningful, are states and errors announced?

⚠️ Common mistake: treating '0 errors in Lighthouse' as proof of accessibility — the tool doesn't judge meaning, context, or the real screen-reader experience.