All jobs / Frontend / web developer

Accessibility interview questions

Accessibility questions a Frontend / web developer can be asked, from first job to senior. Open one to see the strongest answer and why it works.

  1. How do you wire a text field so a screen-reader user knows what to type?

    The strongest answer: Associate a visible <label> with the input via for/id, or wrap the input in the label

    Why it works: A programmatic label is the basic contract: click the text, focus the field, and announce the name.

    • Every input needs a name in the accessibility tree.
    • Prefer a visible label tied with for/id or wrapping.
    • Placeholder is a hint, not a label.
    • aria-label only when a visible label truly cannot exist.

  2. When a field is invalid, your form turns its border red. A tester says blind and colour-blind users cannot tell what went wrong.

    What do you add?

    The strongest answer: A text message next to the field saying what to fix, linked with aria-describedby, aria-invalid on the input, focus moved to the first error on submit — never colour alone

    Why it works: Exactly — say it in text, connect it to the field programmatically, and take the user to it. Colour is decoration on top.

    • Errors in text, linked to the field.
    • Never rely on colour alone.
    • aria-describedby plus aria-invalid.
    • Move focus to the first error.

  3. A custom chip toggles on click but keyboard users cannot use it. What do you do?

    The strongest answer: Prefer a native button; if it must be custom, tabindex=0, role=button, Enter and Space, and a visible focus style

    Why it works: Buttons already do keyboard. If you fake one, you owe the full control pattern.

    • Use a button unless you cannot.
    • Native button first.
    • If custom: role, tabindex=0, Enter/Space, focus ring.
    • Never positive tabindex to rearrange the page.

  4. A Saved toast appears but screen-reader users miss it. What do you add?

    The strongest answer: An aria-live polite region (or a toast library that announces) — don't rely on a visual-only snackbar

    Why it works: Status messages need a live region. polite is the usual toast; assertive is for errors that must interrupt.

    • Announce status, don't only show it.
    • Put the toast in a live region.
    • polite for Saved; assertive for blocking errors.
    • Don't spam the live region.

  5. Design hands you #aaa on #fff for body text. How do you handle the audit?

    The strongest answer: Measure contrast against WCAG 2.2 AA, push back with a token change, and don't 'fix' it by hiding the text from AT

    Why it works: Contrast is a token problem. AA for body text is the usual bar; cheating the checker makes the page worse.

    • Fix the token, not the report.
    • Measure the pair.
    • Raise the color in the system.
    • Never hide text to silence a checker.

  6. How do you audit a checkout flow for accessibility before launch?

    The strongest answer: Keyboard-only pass, a screen reader on the critical path, and axe/Lighthouse as a gate — then fix semantics, not the tool output alone

    Why it works: Tools catch a slice. Keyboard and AT on checkout catch the rest. Fix the HTML, don't chase checkmarks.

    • Audit like a user, then like a tool.
    • Tab the whole checkout.
    • Complete it with a screen reader.
    • Use automated checks as a CI gate, not the only pass.

  7. A teammate built a custom country dropdown from divs with role=listbox copied from a blog post. Screen-reader and keyboard users report they cannot choose a country.

    What is your review feedback?

    The strongest answer: A role is a promise: a listbox dropdown implies arrow keys, a managed active option, aria-selected and aria-expanded. Prefer a native select or a tested library that follows the ARIA authoring patterns, verified with a screen reader

    Why it works: Right — ARIA changes what is announced, not what works. No ARIA is better than ARIA that promises behaviour the widget lacks.

    • A role is a contract.
    • Prefer the native element.
    • Else follow the full authoring pattern.
    • Test with keyboard and screen reader.

  8. Sales wants the website to state “fully WCAG 2.2 AA compliant” for a tender next week. Your last audit found open issues in the checkout and in PDF invoices.

    What do you do?

    The strongest answer: Refuse the blanket claim. Publish an honest statement: the target level, what was tested and when, known gaps with dates, and a contact route — then fix the checkout issues first because they block real users

    Why it works: Exactly — an accurate statement with known limitations is what buyers and regulators expect, and it is the only version you can defend.

    • Claim only what you can show.
    • State target, scope and audit date.
    • List known gaps with dates.
    • Fix blocking issues first.