Accessibility (a11y) Frontend Interview: Semantic HTML, ARIA, Keyboard

⏱ 6 min read

Accessibility (a11y) has gone from optional polish to a core dimension of senior frontend interviews. Companies that ship accessible products by default — Stripe, Vercel, Notion, Apple, Microsoft — explicitly grade accessibility in their machine-coding rounds. Companies that have been hit with ADA-related lawsuits (most consumer-facing tech in the US) increasingly insist on a11y literacy as a hiring signal. Candidates who treat accessibility as an afterthought lose offers; candidates who can articulate the patterns and ship accessible UI by default stand out.

This piece covers what accessibility looks like in 2026 frontend interviews, the patterns to internalize, and the testing tools to use.

The four pillars

Most a11y interview questions probe one of four areas:

Semantic HTML. Using the right element for the right job — nav, main, article, section, button, anchor. The foundation; ARIA cannot fix bad HTML.
ARIA (Accessible Rich Internet Applications). Roles, states, properties for cases where semantic HTML is insufficient. Combobox, dialog, tablist, menu — patterns built from ARIA.
Keyboard navigation. Every interactive element must be operable via keyboard alone. Standard patterns for menus, dialogs, listboxes.
Screen reader behavior. Testing with VoiceOver (macOS), NVDA (Windows), JAWS (Windows). Live regions for dynamic content.

Semantic HTML in detail

Senior interviewers test whether candidates pick the right HTML element by default. The wrong element can be patched with ARIA but it’s much more work than getting it right initially.

Use button for actions. Not div with onClick. Buttons are keyboard-accessible by default; divs are not.
Use anchor (a) for navigation. If clicking the element changes the URL, it should be an anchor.
Use form for grouped inputs. Forms enable Enter-to-submit, accessible error messaging, native validation.
Use label for input labels. Either with for/id or by wrapping the input. This makes the input accessible to screen readers.
Use heading hierarchy correctly. One h1 per page; h2 for major sections; don’t skip levels.
Use nav for navigation, main for the primary content, footer for footer content. Landmark elements help screen reader users navigate.

The rule: if there’s a semantic element for what you’re doing, use it. ARIA is the fallback when no semantic element exists.

ARIA: when and how

ARIA adds semantics that HTML cannot express. Three categories:

Roles. What is this thing? role="button", role="dialog", role="combobox".
States. What is its current state? aria-expanded="true", aria-checked="false", aria-disabled="true".
Properties. What additional info does it have? aria-label="Close", aria-describedby="error-msg".

Common patterns senior+ candidates know:

Dialog: role="dialog" + aria-modal="true" + aria-labelledby pointing at the title.
Combobox (autocomplete): role="combobox" + aria-expanded + aria-controls + aria-activedescendant.
Listbox: role="listbox" with each item role="option" + aria-selected.
Tabs: role="tablist" with role="tab" + aria-selected + aria-controls; tab panels role="tabpanel".
Menu: role="menubar" / role="menu" / role="menuitem".
Live region: aria-live="polite" for non-urgent updates, aria-live="assertive" for urgent ones (use sparingly).

The cardinal rule: bad ARIA is worse than no ARIA. role="button" on a div without keyboard handling is worse than the original div. ARIA promises semantics; the implementation must deliver on them.

Every interactive widget has expected keyboard behavior. Senior interviews probe whether candidates know the conventions:

Buttons: Enter or Space activates.
Links: Enter activates.
Checkboxes: Space toggles.
Radio buttons: Arrow keys move within the group; Tab enters the group.
Tabs: Arrow keys move between tabs; Tab leaves the tablist.
Menus: Arrow keys navigate; Enter activates; Escape closes.
Dialogs: Tab cycles within the dialog (focus trap); Escape closes.
Comboboxes: Down arrow opens; arrow keys navigate; Enter selects; Escape closes.

The W3C ARIA Authoring Practices Guide is the canonical reference. Senior candidates know the major patterns from memory.

Focus management

When the UI changes (modal opens, content updates, view changes), focus must move sensibly. Common scenarios:

Dialog opens: focus moves into the dialog (typically the first focusable element).
Dialog closes: focus returns to the element that triggered the dialog.
Page-level navigation: focus moves to the new page’s main heading.
Form validation error: focus moves to the first error.
Async content loads: focus stays where it was; live region announces the change.

The senior+ candidate proactively manages focus rather than letting the browser default behavior take over.

Good a11y candidates have actually used a screen reader. Even an hour of VoiceOver use on a Mac (built-in, Cmd+F5 to toggle) reveals UI patterns that look fine visually but are unusable for screen readers.

Common issues that screen reader testing reveals:

Decorative images announced as “image” without alt text.
Buttons announced as the visible label, but the visible label is “→” or “X” (use aria-label instead).
Hidden content (display:none vs aria-hidden) not consistent across implementations.
Live regions firing at wrong times or being too verbose.
Focus jumping unexpectedly during dynamic updates.

WCAG conformance levels

WCAG 2.1 (and 2.2) defines accessibility standards at three levels: A, AA, AAA. Most companies target WCAG 2.1 AA as the baseline. Senior candidates know:

Color contrast: 4.5:1 for normal text, 3:1 for large text (AA).
Keyboard accessible: all functionality must be available via keyboard alone (A).
Time-based media: captions for video, transcripts for audio (A and AA depending on type).
Reflow: content reflows at 320px wide without loss of functionality (AA).
Focus visible: users must be able to see what’s focused (AA).

Common interview questions

“How would you make this dropdown accessible?”

Strong answer: identify the pattern (combobox, menu, or listbox depending on what it does), apply the correct ARIA roles and properties, implement the keyboard interactions specified by the pattern, manage focus on open/close, test with a screen reader.

“What’s wrong with this code?” (showing div-with-onClick or non-semantic markup)

Strong answer: identify the missing semantics, propose the right element or ARIA pattern, articulate why it matters (keyboard accessibility, screen reader experience, regulatory risk).

“Walk me through testing accessibility on a feature”

Strong answer: keyboard-only test (unplug the mouse), screen reader test (VoiceOver/NVDA), automated tooling (axe DevTools, Lighthouse), color contrast check, focus management verification.

Tooling

axe DevTools. Browser extension; flags many accessibility issues automatically.
Lighthouse. Built into Chrome DevTools; runs an accessibility audit.
WAVE. Browser extension with visual annotations of accessibility issues.
Storybook a11y addon. Component-level accessibility checks.
Pa11y / axe-core programmatically. CI integration.

How to prepare

Spend an hour with VoiceOver on Mac or NVDA on Windows. Navigate any web app.
Read the ARIA Authoring Practices Guide for the patterns you’ll likely face (dialog, combobox, menu, tablist).
Practice building accessible versions of common components: autocomplete, modal, dropdown menu, accordion.
Run axe DevTools on a few sites you use daily; understand what it flags and why.
For senior+ roles: review the Stripe Accessibility Guide and similar published company a11y guides.

Frequently Asked Questions

Is accessibility tested at all senior frontend interviews?

Increasingly yes. Companies with explicit a11y standards (Stripe, Apple, Vercel, Microsoft) test it directly. Most modern frontend-heavy companies probe it at least implicitly.

Is ARIA required for everything?

No — semantic HTML covers most cases. ARIA fills gaps. Bad ARIA is worse than no ARIA.

How important is screen reader testing in 2026?

Important enough that senior+ candidates should have hands-on experience. Walking through a feature with a screen reader is a common interview ask.

What about React-specific a11y?

React Aria, Radix UI, React Aria Components — libraries that handle accessibility primitives correctly. Senior candidates know these exist and when to use them; they also know how to build accessible primitives by hand for the interview.

How do AI tools affect a11y interview prep?

AI tools can produce ARIA-correct code, but the candidate needs to verify it. Many AI-generated components have subtle a11y bugs (wrong roles, missing keyboard handlers). The verification skill matters.