Accessibility Interview Questions

What is the cheapest accessibility check you can run on your own work, and what does it catch?

Put the mouse away and complete the task with the keyboard alone. In about thirty seconds it catches the majority of real problems: controls you cannot reach at all, a focus indicator that was styled away, a focus order that jumps around because of CSS reordering, a modal you can tab out of, a custom widget that ignores Enter and arrow keys, and focus that disappears entirely after an action. None of those are found by automated tooling, and all of them make the product unusable for keyboard and screen-reader users. It costs nothing, requires no tools, and can be done before every pull request.

What makes this the highest-yield habit is that it needs no tooling, no training and about thirty seconds, and it catches the failures automated checks structurally cannot: reachability, focus order, focus visibility and whether a custom widget responds to the keys its role implies. It does not cover names, contrast or structure, so it complements an automated pass rather than replacing it.

Implement a skip link and explain what makes most implementations fail

The two implementations that fail are worth naming: hiding the link with display: none or visibility: hidden removes it from the tab order entirely, so it can never be reached; and moving scroll without moving focus means the next Tab continues from the top of the document, dropping the user back where they started. Use a visually-hidden pattern that becomes visible on focus, and target an element that can actually receive focus.

Review this custom dropdown for accessibility

<div className="select" onClick={toggle}>
  {value}
  {open && (
    <div className="options">
      {options.map((o) => <div key={o.id} onClick={() => pick(o)}>{o.label}</div>)}
    </div>
  )}
</div>

It is mouse-only. Nothing is focusable, so keyboard users cannot reach or operate it; nothing announces what it is, so a screen reader reads two anonymous groups of text; and there is no indication of expanded state or which option is selected. To fix with ARIA you need a focusable trigger with `role="combobox"`, `aria-expanded` and `aria-controls`; a `role="listbox"` container with `role="option"` children carrying `aria-selected`; arrow-key navigation with `aria-activedescendant` or roving tabindex; Enter/Space to select and Escape to close; and focus returned to the trigger on close. The honest recommendation is to question the requirement first — a native `<select>` gives all of this for free, and if the design cannot use one, an audited headless library is safer than hand-rolling it.

The strongest answers end by challenging whether a custom control was needed, because this is the pattern most often rebuilt badly.

How is an element's accessible name computed, and why can `aria-label` silently make a control worse for some users?

The accessible name is resolved in priority order, roughly: `aria-labelledby` (following the referenced ids), then `aria-label`, then the native mechanism — a `<label>` for a form control, the content of a `<button>`, `alt` on an image — then attributes such as `title` as a last resort. The trap is that `aria-label` OVERRIDES visible text while leaving it on screen. Two consequences. Voice-control users say what they SEE: if a button reads "Save" but is labelled "Submit form", saying "click Save" does nothing. And a translated page may translate the visible text while the hardcoded `aria-label` stays in the original language. So the guidance is to prefer visible text as the name, use `aria-labelledby` to point AT that text when you need to compose it, and reserve `aria-label` for controls that genuinely have no visible text, such as an icon-only button.

The companion question is the first rule of ARIA — do not use it when HTML suffices. This one covers the attribute people reach for most and the specific way it backfires, which is much less widely known than the rule itself.

A form uses placeholders instead of labels. List what that actually breaks

<input type="email" placeholder="Email address" />

Several things at once. The placeholder disappears as soon as the user types, so anyone who is interrupted loses the only indication of what the field is — which is worst for the people least able to recover. Placeholder text is typically low-contrast and often fails the contrast requirement. Support for placeholder as an accessible name is inconsistent across assistive technology, so the field may be announced as just "edit text". There is no click target to focus the field. And autofill heuristics work less reliably without a label. Add a real `<label>` associated by `for`/`id`; if the design demands no visible label, a visually-hidden one still fixes the naming, though the disappearing-context problem remains.

The persuasive argument is not the specification but the interruption case: the placeholder vanishes on the first keystroke, so anyone who looks away and returns has lost the only label the field ever had. That hurts most the people least able to recover it — which is why this is an accessibility failure rather than a styling preference. A visible label also gives a larger click target, since clicking it focuses the field.

You fixed the contrast failures. How would you stop them coming back?

Fix it at the token layer rather than per component. Compute and check contrast for every semantic foreground/background pairing the design system allows, and fail the build when a pair drops below its required ratio — 4.5:1 for body text, 3:1 for large text and non-text UI. Expose only approved pairings as tokens so a designer or engineer cannot silently combine two that fail. Add contrast assertions to the visual-regression or unit suite, and run the automated accessibility checker in CI so a regression in a component is caught on the PR that introduces it rather than in the next audit.

Probes whether a fix was treated as a one-off or as a systems problem; contrast is the clearest case where enforcement can be fully automated.

What does an accessible modal need beyond appearing on screen?

Without focus management a keyboard user tabs into the page behind the dialog and cannot tell where they are. The full contract is: move focus in, keep it inside, return it to the trigger on close, hide the rest from assistive tech, and support Escape.

What name does a screen reader announce for this button?

<button aria-label="Close" aria-labelledby="t">
  Dismiss
</button>
<span id="t">Cancel</span>

"Cancel". `aria-labelledby` wins — it is highest in the accessible-name computation, above `aria-label`, which is itself above the element’s own text content.

The visible text ("Dismiss") loses to both ARIA attributes, which is exactly the hazard: the announced name has nothing to do with what the user sees, so voice control fails and a translated page can announce a stale string. The rule is to prefer the visible text as the name and reach for ARIA only when there is none.