Accessibility interview questions
Accessibility questions a UX / UI designer can be asked, from first job to senior. Open one to see the strongest answer and why it works.
When do you think about accessibility?
The strongest answer: In the first wire — labels, order, contrast, and a real control — I do not “add a11y” in week eight
Why it works: Exactly. First wire. Week-eight, legal-only, and aria-on-div are how you retrofit a mess.
- A11y from the first wire.
- Labels, order, contrast, native controls.
- Not a week-eight phase.
- Aria-on-div is not done.
What contrast ratios does WCAG AA ask for, and what counts as large text?
The strongest answer: 4.5:1 for normal text and 3:1 for large text, which is around 24px, or around 19px when bold; interface components and meaningful graphics also need 3:1
Why it works: Right — and non-text contrast is the one people forget: borders, icons and focus rings count too.
- 4.5:1 text, 3:1 large and UI.
- Large is about 24px, 19px bold.
- Measure it, do not eyeball it.
- Fix the token, not the screen.
An icon-only button “looks cleaner.” What do you still need?
The strongest answer: An accessible name and, often, a visible label — clean is not a name
Why it works: Exactly. A name. Universal-icons, late hovers, and later tutorials fail keyboard and many people.
- Every control needs an accessible name.
- Prefer a visible label.
- Icons are not universal.
- Hover-only is not a label.
Light grey text on white “feels premium.” What do you do?
The strongest answer: Raise contrast until people can read it — premium is not a licence to whisper
Why it works: Exactly. Readable first. Expensive whispers, zoom-jokes, and invented 100s fail the page.
- Meet a readable contrast.
- Premium ≠ faint text.
- Do not joke “just zoom.”
- No invented contrast score.
You designed a custom dropdown as a div forest. What did you forget?
The strongest answer: Focus, arrows, escape, and a name — or use a native control — I do not ship a mouse-only widget
Why it works: Exactly. A widget is a keyboard contract. Most-people, v2, and focus-traps fail someone today.
- Keyboard the widget, or go native.
- Mouse-only is a defect.
- Do not park it in v2.
- Do not trap focus forever.
A status column shows a red dot for failed and a green dot for passed.
What is the problem, and what do you change?
The strongest answer: Colour is the only cue, so anyone who cannot separate those two hues reads nothing — I add a word or a distinct shape and keep the colour as reinforcement
Why it works: Exactly — never let colour be the only carrier of meaning; text or shape carries it, colour reinforces.
- Colour never carries meaning alone.
- Add a word or a shape.
- Check the screen in greyscale.
- Keep colour as reinforcement.
Tab order jumps around a modal. Whose bug is that?
The strongest answer: Design’s, with engineering — we specify order and a close control, we do not say “looks fine with a mouse”
Why it works: Exactly. Order and escape. Mouse-only, forever-traps, and polish-later fail a keyboard user today.
- Specify focus order and close.
- Mouse-fine ≠ done.
- Do not trap without escape.
- Focus is not late polish.
A deck says “100% accessible.” What do you do?
The strongest answer: Take it off — say which checks we ran and what we have not — I do not keep a costume 100
Why it works: Exactly. Checks and leftovers. 99-as-humble and overlay-as-100 are still costumes.
- Remove “100% accessible.”
- Name checks and leftovers.
- Humble 99 is still fake.
- Overlays ≠ done.
What a11y bar will you put on a release?
The strongest answer: Named checks we ran and leftovers we accept — I do not stamp “WCAG done” with no list
Why it works: Exactly. Checks and leftovers. Overlays, filter-screenshots, and date-skips are costumes.
- Named checks + accepted leftovers.
- No empty “WCAG done.”
- Overlays ≠ the gate.
- Do not skip for a date.
You designed a custom filter control: a button that opens a panel and shows how many filters are applied.
What do you write in the spec so that a screen-reader user gets the same thing?
The strongest answer: Its name, its role and its state — “Filters, 3 applied”, a button, expanded or collapsed — plus what is announced when the count changes and where focus lands
Why it works: Right — name, role and state is the contract; you decide the words, engineering wires them up.
- Specify name, role and state.
- Write the words that are announced.
- Say what a change announces.
- Say where focus lands.
What does accessibility look like as a program, not a poster?
The strongest answer: Gates, training, and a backlog with owners — I do not print a 100 badge
Why it works: Exactly. Gates and owners. Videos, overlays, and invented percentiles are décor.
- Gates, training, owned backlog.
- No 100 badge as proof.
- Overlays ≠ the program.
- No invented WCAG percentile.