Web Accessibility for Senior Engineers

Senior frontend interviews increasingly test accessibility knowledge because it reveals understanding of HTML semantics, browser APIs, and user empathy.

The WCAG Framework

Web Content Accessibility Guidelines organize requirements into four principles — POUR:

Principle	Meaning	Example
Perceivable	Content can be perceived	Alt text, captions, contrast
Operable	UI can be operated	Keyboard nav, no time limits
Understandable	Content is understandable	Labels, error messages, consistency
Robust	Works across technologies	Valid HTML, ARIA when needed

Common Interview Topics

Keyboard Navigation

Every interactive element must be reachable and operable via keyboard:

Tab / Shift+Tab for focus navigation
Enter / Space for activation
Escape to close modals/popups
Arrow keys for composite widgets (tabs, menus, lists)

ARIA — When and How

Rule 1: Don't use ARIA if native HTML does the job.

<!-- Bad -->
<div role="button" tabindex="0" onclick="...">Click me</div>
 
<!-- Good -->
<button onclick="...">Click me</button>

When ARIA is needed: Custom widgets that don't have native HTML equivalents — tabs, tree views, comboboxes, live regions.

Focus Management

SPAs break natural focus flow. Seniors implement:

Focus trapping in modals
Focus restoration when dialogs close
Route change announcements for screen readers
Skip-to-content links

Color and Contrast

WCAG AA: 4.5:1 contrast ratio for normal text
WCAG AA: 3:1 for large text (18px+ bold or 24px+)
Never convey meaning through color alone

Architectural Impact

Accessibility shapes architecture:

Component API design — every interactive component needs aria props
Routing — page transitions need focus management and announcements
Error handling — form errors must be programmatically associated with inputs
Testing — accessibility tests belong in CI, not just audits

Accessibility is a senior engineering concern because it requires thinking about the full user experience, not just the visual output.