Articles

Accessibility Interview Questions for Frontend Engineers: Semantics, Keyboard, and ARIA

Prepare for frontend accessibility interviews with semantic HTML, keyboard navigation, focus management, ARIA patterns, testing, and practice questions.

Your component looks polished, the data loads correctly, and every mouse click works. Then the interviewer puts the mouse aside, presses Tab, and asks, "How would someone operate this with a keyboard or screen reader?" A surprising number of otherwise strong frontend solutions unravel at that moment.

Accessibility interview questions for frontend engineers are rarely about memorizing every WCAG criterion. They test whether you can choose meaningful HTML, define an interaction contract, manage focus, keep ARIA state synchronized, and prove the result works.

This guide gives you an interview-ready framework for semantics, keyboard behavior, focus management, ARIA, and testing. You will also see concrete questions, strong-answer patterns, common traps, and a seven-day practice plan.

Quick answer: accessibility is a behavior contract

A strong answer starts with the user task, not an ARIA attribute. Explain what the control means, how a keyboard user reaches and operates it, where focus moves, what state assistive technology receives, and how you will verify that contract.

The most reusable interview framework is semantics, interaction, state, feedback, verification. It keeps your answer grounded in observable behavior and prevents a long list of disconnected accessibility tips.

Dimension	Question to answer	Strong evidence
Semantics	What is this element or relationship?	Native element, accessible name, label, heading, or landmark
Interaction	How does a non-pointer user operate it?	Expected Tab, arrow, Enter, Space, and Escape behavior
State	What changes, and who can perceive it?	Visible state plus synchronized HTML or ARIA state
Feedback	How are errors and async results communicated?	Focus placement, associated text, or appropriate live announcement
Verification	How do you know the contract works?	Keyboard walkthrough, accessibility tree, semantic tests, and targeted assistive-tech checks

Semantic HTML interview questions

Why is a native button better than a div with role="button"?

A native <button> already exposes button semantics, enters the tab order, responds to expected keyboard activation, participates in forms, and supports disabled behavior. A <div role="button"> only changes what assistive technology is told; you still own focusability, Enter and Space behavior, disabled handling, and visual focus.

The WAI-ARIA Authoring Practices calls a role a promise. If you claim an element is a button, your implementation must deliver the expected button behavior. In an interview, prefer the native element unless a real constraint makes it impossible.

When should you use a link instead of a button?

Use a link when activation navigates to a resource or location. Use a button when activation performs an action in the current context, such as opening a dialog, submitting a form, or toggling a panel. Styling does not change that distinction.

A senior answer also mentions browser capabilities. Links support address inspection, opening in a new tab, copying the destination, and visited-state behavior; replacing them with buttons removes those expectations.

How is an accessible name computed?

An accessible name is the label assistive technology uses to identify a control. It may come from visible text, a connected <label>, aria-labelledby, aria-label, or an element-specific source such as image alt text.

Do not reach for aria-label first. Visible labels help more users, and aria-labelledby can reuse visible content. Also remember that an ARIA label may override useful descendant text, so inspect the resulting accessibility tree rather than assuming the name is additive.

Keyboard accessibility and focus questions

Should every item be reachable with Tab?

No. Tab and Shift+Tab normally move between components. Inside composite widgets such as tablists, menus, listboxes, grids, and tree views, arrow keys typically move among items while the composite contributes one stop to the page tab sequence.

This distinction prevents a page from creating dozens of unnecessary tab stops. State which established widget pattern you are implementing, then follow its keyboard convention instead of inventing key bindings from scratch.

How would you manage focus in a modal dialog?

When the dialog opens, move focus to a meaningful element inside it, based on the content and risk of the default action. Keep keyboard navigation within the active modal, support Escape when dismissal is allowed, and return focus to the control that opened it when the dialog closes.

Then discuss failure cases: the opener may have been removed, async content may delay the intended target, and a sticky layer must not visually obscure the focus indicator. Focus management is lifecycle state, not one call to focus().

Why is positive tabindex usually a warning sign?

Values greater than zero create a custom tab order that can diverge from the visual and DOM order. That order becomes difficult to maintain as components are inserted, hidden, or reused. Prefer logical source order, native focusability, tabindex="0" for a custom focusable control, and tabindex="-1" for programmatic focus targets.

ARIA interview questions that reveal judgment

What does "no ARIA is better than bad ARIA" mean?

Incorrect ARIA can confidently expose the wrong role, name, state, or relationship. That may make a working native experience less understandable to assistive technology. Start with native HTML and add ARIA only when it supplies semantics that HTML cannot express for the chosen interaction.

ARIA does not create behavior. Adding role="menu" does not implement arrow-key navigation, focus management, or item activation. The role and the interaction model must agree.

How do aria-expanded, aria-selected, and aria-pressed differ?

aria-expanded describes whether a controlled region is expanded. aria-selected marks selection in widgets that support selected items, such as tabs or listboxes. aria-pressed describes the state of a toggle button.

Do not choose an attribute because its name sounds close to the visual design. Choose it from the component's role and expected state model, update it in the same state transition as the visual UI, and test both true and false states.

When should you use an aria-live region?

Use a live region for important dynamic information that changes without moving focus, such as an async search status or a saved confirmation. Keep announcements concise and avoid making frequently changing content overly verbose.

Errors often need more than a live announcement. Associate the message with the field, expose invalid state, preserve the user's input, and move focus only when that movement helps recovery rather than surprises the user.

Component scenario: an accessible autocomplete

An autocomplete combines async state, keyboard behavior, focus, and ARIA relationships, which makes it an excellent interview scenario. Begin by clarifying whether the input accepts free text, whether selection is required, and what Enter, Escape, blur, loading, empty, and error states should do.

For a combobox pattern, the input needs an accessible name and a relationship to the popup. Arrow keys move the active option, Enter commits it, and Escape dismisses the popup. If DOM focus stays on the input, aria-activedescendant can identify the active option, but the referenced ID must remain valid as async results change.

A strong answer also protects against stale requests and disappearing options. Accessibility cannot be separated from state correctness: announcing one result set while rendering another is still a broken experience.

How to test accessibility in an interview

Automated checks are useful, but they cannot prove that a workflow is understandable or that focus moves sensibly. Explain a layered test strategy and name the risk each layer catches.

Use the keyboard to complete the full task, including reverse navigation and dismissal.
Check focus visibility, order, return behavior, and whether any overlay obscures focus.
Inspect roles, names, states, and relationships in the browser accessibility tree.
Write interaction tests using semantic queries such as getByRole with an accessible name.
Use automated rules and targeted screen-reader checks for the highest-risk component patterns.

Testing Library recommends role and label queries because they resemble how users and assistive technology find controls. A test that cannot locate a button by role and name may be revealing an implementation problem, not merely a test-selector inconvenience.

A strong answer to a practical accessibility prompt

Suppose the interviewer asks, "Make this custom dropdown accessible." Do not begin by adding aria-haspopup everywhere. First clarify whether the product needs a native select, a disclosure containing links, a menu of commands, or a listbox for choosing a value. Those patterns have different semantics and keyboard contracts.

Then state your implementation order: use the closest native control, define the open and selected state, implement pointer and keyboard behavior from one state model, manage focus, expose only the missing relationships, and test the complete interaction. Finally, explain trade-offs such as portals, virtualization, mobile behavior, and whether a custom widget is worth its maintenance cost.

That answer demonstrates engineering judgment. It treats accessibility as part of component architecture rather than decoration added after the mouse path works.

A seven-day accessibility interview plan

Day and focus	What to do
Day 1: Semantics	Rewrite five div-based controls with native HTML and explain the role of each element.
Day 2: Names	Inspect labels and accessible names for forms, icon buttons, images, and grouped controls.
Day 3: Keyboard	Practice Tab versus arrow-key behavior for tabs, listboxes, menus, and tree views.
Day 4: Focus	Implement dialog opening, containment, Escape behavior, and focus restoration.
Day 5: ARIA	Explain expanded, selected, pressed, disabled, invalid, and live-region states with examples.
Day 6: Testing	Run keyboard, accessibility-tree, semantic-query, and automated checks on one component.

Pair this plan with the UI Coding Interview Guide when you want a broader timed-component workflow.

Common accessibility interview mistakes

Adding ARIA before identifying the pattern often creates the wrong role and keyboard behavior. Testing only with a mouse misses focus order, traps, and missing activation keys. Removing outlines without a replacement hides the user's current position.

Other weak answers quote WCAG without connecting it to the component, make every item tabbable, use placeholder text as the only form label, or claim an automated scan proves accessibility. Interviewers want a coherent user journey and a verification plan, not a vocabulary dump.

Frequently asked questions

Do frontend engineers need to memorize WCAG criteria?

You should know the practical principles and a few common requirements, especially keyboard access, visible focus, names and labels, text alternatives, contrast, and error identification. It is more valuable to apply them correctly than to recite criterion numbers from memory.

Should I mention screen readers in every accessibility answer?

Mention assistive technology when roles, names, relationships, or announcements matter, but do not reduce accessibility to screen readers. Keyboard-only users, people using voice input, magnification, high-contrast settings, switch devices, or reduced motion also expose important design constraints.

Is semantic HTML enough without ARIA?

Semantic HTML covers many common controls and document structures, and it should be the default. Complex custom widgets may still need ARIA roles, states, and relationships plus scripted keyboard behavior. Native semantics reduce the amount of behavior you must recreate.

What accessibility tools should I name in an interview?

Name the browser accessibility tree, keyboard testing, semantic component tests, an automated rule engine such as axe, and targeted screen-reader testing. More important, explain what each tool can and cannot prove.

What if time is running out in a UI coding interview?

Ship a complete core interaction with native semantics, keyboard operation, visible focus, and one meaningful test. State the remaining gaps precisely. A smaller component with a defensible contract is stronger than a visually elaborate mouse-only implementation.

Final takeaway

Accessibility interview questions are frontend engineering questions. The strongest candidates choose semantics deliberately, implement the expected keyboard and focus contract, use ARIA only to express missing information, and verify the experience through several complementary checks.

Repetition turns accessibility from a last-minute checklist into part of your normal component design.

Sources and Further Reading

Research note: This guide was checked on August 22, 2026. Accessibility standards and browser behavior evolve, so verify current documentation when preparing for a specific interview.