Accessibility Basics: Semantic HTML, ARIA, and Keyboard Navigation

Accessibility (a11y) is no longer optional. It’s also a strong interview signal because it shows real-world engineering maturity.

30‑second interview answer

Accessibility means building UIs usable with keyboards and assistive tech. Start with semantic HTML (buttons/links/labels), ensure keyboard navigation and visible focus, and use ARIA only to fill semantic gaps. Most a11y bugs come from custom controls that don’t implement proper roles, states, and keyboard behavior.

Key points

• Native elements first.
• Everything must be keyboard reachable.
• Focus visible + managed (especially for modals).
• ARIA is not a replacement for semantics.

1) The golden rule: use semantic HTML first

Before ARIA, use the right elements:

• <button> for actions
• <a> for navigation
• <label> for inputs
• headings in order (h1 → h2 → h3)

Semantic HTML gives you:

• keyboard behavior
• screen reader meaning
• better SEO

2) Keyboard navigation basics

Users should be able to:

• Tab through interactive elements
• activate controls with Enter/Space
• see a visible focus indicator

Common mistake:

• clickable <div> without keyboard handlers.

Fix:

• use <button> or add tabIndex=0 + key handlers (but prefer button).

3) Focus management (modals and menus)

Modals should:

• move focus into modal on open
• trap focus inside
• restore focus on close

If focus is lost, screen-reader and keyboard users struggle.

4) ARIA: what it is and what it is not

ARIA adds semantic meaning, but:

• no ARIA is better than bad ARIA

Rules of thumb:

• don’t add roles if native elements already have them
• use ARIA for custom components

Examples:

• aria-label for icon-only buttons
• aria-expanded for accordions
• aria-controls to link button → panel

5) Forms: labels matter

Bad:

<input placeholder="Email" />

Good:

<label for="email">Email</label>
<input id="email" />

Or visually hidden label.

6) Common a11y bugs

• removing focus outline without replacement
• incorrect heading hierarchy
• missing alt text on meaningful images
• low color contrast
• using role="button" instead of <button>

7) How to test quickly

• keyboard-only test
• Lighthouse accessibility audit
• screen reader basics (VoiceOver/NVDA)

8) Interview Q&A

Q: When do you use ARIA?

• when native semantics don’t exist (custom widgets) or to provide extra labeling.

Q: What’s the best first step for accessibility?

• semantic HTML + keyboard support.

Summary checklist

• I can explain semantic HTML benefits.
• I ensure keyboard navigation and visible focus.
• I know common ARIA states and when to use them.
• I can describe modal focus management.

Summary

• semantic HTML first.
• keyboard support is mandatory.
• ARIA is powerful but easy to misuse.
• focus management is critical for modals/menus.