Lesson 19 of 30

Accessibility in Code Review

Q: Your team has good accessibility intentions but issues keep slipping into production anyway. What would you actually change?

A strong answer covers: Identifies that the gap is process, not intention or knowledge — issues get caught late or not at all because nothing structural enforces a check earlier; Proposes a concrete mechanism: a written accessibility checklist section in the PR template, not relying on institutional memory; Names specific, non-specialist-level things the checklist would cover (accessible names, icon-only buttons, keyboard patterns for custom widgets, test coverage); Connects this to the general principle that structural enforcement beats individual vigilance.

Automated tests, screen-reader testing, and manual checklists only work if something makes sure they actually happen before code ships.

11 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

A PR adds a new icon-only 'delete' button with no visible text and no `aria-label`. What would a reviewer running a basic accessibility-aware review catch here, without needing to run any tooling?

That the button has no accessible name and would announce as just 'button' to a screen readerNothing catchable in review — missing aria-labels can only be detected by running an automated scanThat the icon's SVG file is missing alt text, since SVGs require alt attributes identically to img tags

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Accessibility in Code Review

What interviewers actually ask about this, and what a strong answer has to cover.

Your team has good accessibility intentions but issues keep slipping into production anyway. What would you actually change?

A strong answer covers

Identifies that the gap is process, not intention or knowledge — issues get caught late or not at all because nothing structural enforces a check earlier
Proposes a concrete mechanism: a written accessibility checklist section in the PR template, not relying on institutional memory
Names specific, non-specialist-level things the checklist would cover (accessible names, icon-only buttons, keyboard patterns for custom widgets, test coverage)
Connects this to the general principle that structural enforcement beats individual vigilance

Likely follow-ups

How would you keep the checklist from becoming a box-ticking exercise reviewers stop actually reading?
Where does this PR-level check fit relative to automated CI tests and screen-reader testing — what does it catch that they don't?

Practice these with the AI interviewer →

The plain-language idea

Automated tests, screen-reader testing, and a manual checklist are only as effective as the point in the workflow where they actually get run. An accessibility issue caught in code review, before merge, is dramatically cheaper to fix than the same issue caught after it ships — at that point it's a design conversation and a small diff, not a live bug affecting real users, a support ticket, or a rebuild of something already in production.

Code review doesn't require the reviewer to be an accessibility specialist to catch a real, meaningful share of issues. A realistic accessibility-aware review looks for a short, concrete set of things:

Does a new interactive element have an accessible name — something a screen reader would actually announce, not just a visual label?
Is a new icon-only button missing an aria-label? (A trash-can icon with no text and no label announces as just "button.")
Does a new modal, dropdown, or other custom widget follow the keyboard interaction pattern already established elsewhere in the codebase, rather than inventing a new one?
Did an automated accessibility test get added or updated for the new UI, if the codebase has that kind of test coverage?

See it in a real thing: a PR template section

## Accessibility
- [ ] New interactive elements have an accessible name (visible text, `aria-label`, or `aria-labelledby`)
- [ ] New icon-only buttons have an `aria-label`
- [ ] New custom widgets (modal, dropdown, tabs) follow this codebase's existing keyboard pattern
- [ ] Automated a11y test added/updated for new UI, if applicable

A checklist this short takes seconds to run through and catches a real, meaningful share of the most common mistakes — before a reviewer even opens the diff in detail. The point isn't exhaustive coverage; it's making the four or five highest-value checks impossible to silently skip.

What people usually miss

Watch out

"We care about accessibility" as a stated value doesn't survive contact with a deadline unless it's built into a concrete review step. Good intentions without a checklist item reliably lose to shipping pressure.
A reviewer doesn't need deep ARIA expertise to catch most of the high-value issues. Missing accessible names and missing keyboard support on custom widgets are both spottable by reading a diff, without running anything.
Catching an issue in review is a fundamentally different cost than catching it post-ship. Pre-merge it's a comment and a small fix; post-ship it's a live accessibility bug, potentially a support ticket or complaint, and a fix that competes with new work for priority.
A PR template checklist item works because it's impossible to silently skip, not because it's exhaustive. It's a floor that catches the common cases reliably, the same relationship automated testing has to manual testing — layered, not redundant.

Why this matters in interviews

"How do you make sure accessibility doesn't get skipped under deadline pressure?" is a real organizational question, and naming a concrete mechanism — a written PR checklist, not "the team is careful" — is what shows a candidate understands that process design, not individual vigilance, is what actually holds up over time.