← All topics

Accessibility Interview Questions and Answers

Semantic HTML, keyboard and focus, ARIA roles and states, accessible names, forms and errors, contrast and motion, widget patterns, screen readers, WCAG 2.2, testing and the European Accessibility Act.

225 questions for Accessibility interviews with answers and explanations - Junior, Middle and Senior levels. Sample questions, online quizzes and coding tasks.

Questions by level

Sample questions

A few questions from each level with the correct answer and an explanation.

Accessibility · Junior

  1. What does web accessibility (a11y) mean?
    Show the answer

    Correct answer: People can use a site whatever their abilities or devices

    Accessibility means people with visual, hearing, motor or cognitive disabilities can perceive, understand and operate the site. "a11y" is a shorthand: a, 11 letters, y.

  2. Who benefits from accessible interfaces?
    Show the answer

    Correct answer: Everyone, including people with temporary limits

    A broken arm, bright sunlight or a noisy train create the same barriers as permanent disabilities. Captions, contrast and keyboard support help all of those people.

  3. What is WCAG?
    Show the answer

    Correct answer: The W3C guidelines for making web content accessible

    The Web Content Accessibility Guidelines define testable success criteria. Version 2.2 is the current W3C Recommendation, and laws and contracts often refer to it or to 2.1.

  4. What are the four WCAG principles?
    Show the answer

    Correct answer: Perceivable, Operable, Understandable, Robust

    Known as POUR. Users must be able to perceive content, operate the interface, understand it, and rely on it working with assistive technologies.

All 75 questions with answers →

Accessibility · Middle

  1. What is the accessibility tree?
    Show the answer

    Correct answer: A browser structure of roles, names and states built from the DOM

    Assistive technologies read this tree through platform APIs, not the DOM directly. Chrome and Firefox DevTools let you inspect it for any element.

  2. Which source usually wins when computing an element's accessible name?
    Show the answer

    Correct answer: aria-labelledby, then aria-label, then native labelling and content

    The computation has a defined order. aria-labelledby overrides everything, so a stale reference can silently replace a good visible label.

  3. What is the difference between aria-labelledby and aria-describedby?
    Show the answer

    Correct answer: The first sets the name; the second adds a supplementary description

    The name says what a control is and is always announced. The description adds details such as format hints, and users can configure whether they hear it.

  4. Why prefer aria-labelledby pointing at visible text over aria-label?
    Show the answer

    Correct answer: Visible text stays in sync and is translated with the page

    aria-label is easy to forget during updates and browser translation tools may skip it. Reusing visible text keeps one source of truth.

All 75 questions with answers →

Accessibility · Senior

  1. How does information get from the DOM to a screen reader?
    Show the answer

    Correct answer: The browser exposes the accessibility tree via platform APIs

    Browsers map roles and states to APIs such as UI Automation on Windows or the AX API on macOS. That's why results differ across browser and reader pairs.

  2. Which of these roles gets its name from its content?
    Show the answer

    Correct answer: button, while textbox needs a label from elsewhere

    Roles such as button and link allow name from content. A textbox can't, because its content is the user's value.

  3. Can aria-describedby point to an element with the hidden attribute?
    Show the answer

    Correct answer: Yes, referenced hidden content still contributes

    Name and description computation includes hidden nodes when directly referenced. It's handy for a description that shouldn't appear on screen.

  4. A modal sets aria-hidden="true" on #app, but focus is still inside #app. What happens?
    Show the answer

    Correct answer: Focus lands in hidden content; Chrome may even block the attribute

    Move focus first. Chrome warns and ignores aria-hidden when a descendant holds focus. Prefer inert, which removes focus as well.

All 75 questions with answers →

Combined quizzes with this topic

Questions from several topics at once - just like an interview for a specific role.

Coding tasks

Write your solution right in the browser, and tests check it instantly. JavaScript interview classics (debounce, deepClone, Promise.all, an LRU cache), TypeScript tasks on generics, narrowing and utility types checked by the real compiler, Node.js backend logic (middleware, rate limiters, job queues), SQL queries in real PostgreSQL, and React components and hooks like a todo list, tabs, useDebounce and useInterval.

Open tasks →