Use a production accessibility review workflow: semantics first, then keyboard and focus, labels and errors, contrast, manual assistive-tech checks, and automated tooling. The real mistake is treating Lighthouse or axe as the whole audit when they cannot judge focus order, alt quality, or content clarity on their own.
Interview answer drill
Use this HTML interview question to rehearse a quick answer, common mistake, follow-up, and production pitfall.
How would you make a page accessible?Frontend interview answer
Interview focus
This HTML interview question tests whether you can explain make a page accessible: production workflow and common mistakes, connect it to production trade-offs, and handle common follow-up questions.
- make a page accessible: production workflow and common mistakes explanation without falling back to memorized docs wording
- Accessibility and Semantics reasoning, edge cases, and production failure modes
- How you would answer the most likely HTML interview follow-up
Interview quick answer
Full interview answer
The Core Idea
Accessibility is not a last-minute checklist item. In production it is a review workflow: start with semantic structure, verify keyboard order and visible focus, confirm contrast and labels, then test with screen readers and automated tools. The best answers sound like a bug-prevention plan, not a loose list of nice-to-haves.
Step | What to verify | Why it matters |
|---|---|---|
| Use headings in order, landmarks ( | Gives screen readers structure and intent |
| Everything is reachable by Tab, focus stays visible, and modals do not trap or lose focus incorrectly | Required for users who don’t use a mouse |
| Pair inputs with | Improves navigation and error comprehension |
| Meet WCAG contrast ratios; don’t rely on color alone | Ensures text and UI are readable |
| Run a keyboard-only pass and a quick screen-reader spot check on landmarks, forms, and dialogs | Catches issues automated tools often miss |
| Use Lighthouse or axe after the manual pass, not instead of it | Finds repeatable attribute and structural issues quickly |
What automated tools miss
Automated checks can catch missing labels, low contrast, and broken ARIA attributes, but they cannot reliably judge whether alt text is actually useful, whether focus order feels logical, whether a modal returns focus to the right trigger, or whether link text still makes sense when read out of context.
Manual check | What to ask next |
|---|---|
Tab through the page | Does focus move in a logical order and stay visible at every step? |
Open and close a modal | Is focus trapped correctly while open and returned to the trigger when closed? |
Submit an invalid form | Are the errors announced clearly and connected to the right fields? |
Read links and buttons out of context | Would labels like “Read more” still make sense without surrounding text? |
Common mistakes
Production accessibility bugs usually come from the same places: a modal without a focus trap, a form error that uses color alone, custom controls with broken keyboard order, or ARIA pasted onto the wrong native element. Review the page in that order so you catch structural issues before polishing labels.
Summary
Use semantic HTML first, add ARIA only when necessary, ensure keyboard navigation and focus visibility, verify color contrast, and test with real tools.
Similar questions
Guides
Preparing for interviews?
Use this as one explanation rep, then continue with the HTML interview questions cluster or a guided prep path.