Think of a website like a building. Accessibility means people can enter, move around, and understand what’s inside whether they use the main door, a ramp, an elevator, or a sign in braille.
If a door is painted a color that blends into the wall, someone may not notice it. If the elevator buttons are too high, some people can’t reach them. In software, the same idea applies: some people use a mouse, some use a keyboard, and some rely on a screen reader. Good design makes the experience work for all of them, not just the “default” user.
What accessibility is and why it matters
Accessibility (a11y) is the practice of designing interfaces that people can perceive, operate, understand, and reliably use. It matters because users may have low vision, blindness, motor limitations, color vision differences, or temporary constraints like a broken mouse.
In interviews, strong answers show you know accessibility is not an add-on. It affects core UI choices: using semantic HTML first, ensuring keyboard navigation, preserving a logical focus order, and maintaining sufficient color contrast. ARIA helps fill gaps when native HTML cannot express the needed behavior, but it is not a replacement for native elements.
A senior-level answer usually connects the user need to the implementation choice and the verification method: keyboard testing, screen reader basics, and automated checks like Lighthouse or axe.
Start with native elements before ARIA
The first rule is: prefer native HTML elements whenever possible. A <button> already exposes the right role, keyboard behavior, and focus handling; a div does not.
Use ARIA roles and attributes only when native semantics are missing or insufficient. Examples include aria-label, aria-expanded, and role="dialog" for custom widgets. But if you can solve it with <button>, <nav>, <label>, or <input>, that is usually better because browsers and assistive technologies already understand them.
This matters because ARIA can be misused. A wrong role can confuse screen readers more than having no ARIA at all, so the interview-safe principle is: “native first, ARIA second.”
Make every action reachable from the keyboard
A keyboard user must be able to move through the page using Tab, Shift+Tab, arrow keys, and Enter/Space where appropriate. That means interactive controls must be focusable, and the tab order should match the visual and logical reading order.
Pay attention to focus management when UI changes. If a modal opens, focus should move into it; when it closes, focus should return to the triggering control. A focus trap keeps keyboard users inside the modal while it is open, so they do not tab to hidden background content.
Also mention skip links in interviews: they let keyboard and screen reader users jump past repeated navigation to the main content. That’s a small feature with high leverage.
Help screen readers by exposing meaning, not just visuals
A screen reader reads the accessibility tree, not the pixels. So the DOM needs to communicate purpose: headings in order, form fields with labels, buttons with clear names, and expanded/collapsed state where relevant.
ARIA attributes can expose state and relationships, such as aria-describedby for helper text or aria-expanded for toggles. But they only work well when the underlying element still behaves correctly. For example, a custom button should still respond to keyboard activation and have a programmatic name.
If you want to explain this in an interview, say that the screen reader experience is shaped by semantic structure plus state. Good accessibility is not “adding text for screen readers”; it is making the UI understandable through multiple modalities.
Treat color as one signal, not the only signal
Color contrast ensures text and critical UI elements are readable for people with low vision or color vision differences. Low contrast is a common bug in design systems and one of the easiest accessibility misses to catch early.
Also avoid using color alone to convey meaning. If red means error, add text, an icon, or both. If a chart uses color categories, combine it with labels, patterns, or direct annotations.
In practice, interviewers want to hear that you check contrast during design and implementation, and that you do not rely on color as the only indicator of state or action.
A modal dialog done in an accessible way
Imagine a delete confirmation modal. The accessible version uses a real dialog container, a close button, and focus management.
The trigger is a native button.
The modal gets role="dialog" and aria-modal="true" if you are not using the native <dialog> element.
The title is connected with aria-labelledby.
Focus moves to the modal when it opens and returns to the trigger when it closes.
The rest of the page is not reachable while the modal is open, so the user does not tab into hidden controls.
This example often appears in interviews because it combines semantics, keyboard support, and screen reader behavior in one place.
A practical testing story is more convincing than a definition. Start with automated checks, then do a quick manual pass.
Run Lighthouse to catch common issues like missing labels, contrast warnings, and poor semantic structure.
Use axe to surface likely violations in the DOM.
Try the page with only the keyboard: can you reach every control, see where focus is, and exit modals?
Do a basic screen reader pass: can you hear headings, labels, button names, and state changes?
The key interview point is that automation helps, but it does not replace human verification. You still need to test real interaction flow.
Manual checklist:
1. Tab through the page.
2. Open a modal and verify focus moves inside.
3. Close it and verify focus returns.
4. Check text contrast and non-color cues.
5. Run Lighthouse / axe.
Common accessibility traps interviewers look for
The biggest trap is assuming accessibility means “adding ARIA everywhere.” ARIA does not fix bad semantics; a broken div button is still broken if it lacks keyboard support and a proper name.
Other common mistakes:
Using color alone to show errors or required fields.
Breaking tab order with custom focus handling or tabindex misuse.
Creating a modal without a focus trap or without returning focus to the trigger.
Hiding information visually but leaving it inaccessible to screen readers, or vice versa.
Relying only on automated tools and never testing with a keyboard or screen reader.
A strong interview answer emphasizes progressive enhancement: native HTML first, ARIA only when needed, and verify with real interaction tests.