Q383: Accessibility Fix Drill Keyboard Focus and Screen Reader Feedback
What Interviewers Want To Evaluate
This drill tests whether you can fix accessibility issues as product behavior, not decoration.
Senior frontend engineers should be able to inspect a UI, find keyboard traps, missing labels, weak semantics, poor focus management, and unclear dynamic updates.
The interviewer wants to see whether your fixes improve real workflows.
Short Interview Answer
I start accessibility fixes by walking the workflow with keyboard only, then checking semantic structure, labels, focus order, focus visibility, error messages, and screen reader feedback for dynamic updates. I prefer native elements before ARIA, keep focus movement predictable, and verify the final flow manually as well as with automated checks.
Workflow First
Pick a real task:
open page
search item
filter result
open modal
submit form
recover from error
close modal
continue reading
Accessibility should be tested through workflows.
A page can pass automated checks and still be hard to use.
Keyboard Pass
Check:
can every control be reached
is the order logical
is focus visible
does focus enter and leave modals correctly
can dropdowns be opened and closed
can escape close temporary UI
can actions be triggered without a mouse
Keyboard access is one of the fastest ways to reveal real UI quality.
Semantic Fixes
Prefer:
button for actions
anchor for navigation
label for inputs
heading levels for structure
list for lists
table for tabular data
fieldset for grouped form controls
Use ARIA when native HTML cannot express the interaction.
Do not add ARIA to repair the wrong element if a native element would solve it.
Focus Management
Focus should move when:
modal opens
modal closes
route changes after form submit
validation summary appears
destructive confirmation appears
Focus should not jump when:
results refresh
minor content changes
loading indicator appears
background data refetches
Unexpected focus movement can be as harmful as missing focus movement.
Screen Reader Feedback
Dynamic updates may need announcements:
search results count changed
form submit failed
save succeeded
long-running operation completed
cart item added
Use polite announcements for normal updates.
Use assertive announcements only for urgent problems.
Too many announcements create noise.
Error UX
Form errors should:
identify the field
explain the problem
suggest the fix
be programmatically connected to input
not rely only on color
be reachable after submit
Good error accessibility is good product UX.
It helps everyone recover faster.
Visual Contrast
Check:
text contrast
button contrast
disabled contrast
focus ring contrast
code block contrast
status pill contrast
dark theme contrast
Theme support increases the number of contrast states.
Every new theme needs a quick accessibility pass.
Example Fix
Weak code:
<div onClick={save}>Save</div>
Better:
<button type="button" onClick={save}>
Save
</button>
This adds keyboard behavior and semantics without extra JavaScript.
Testing Strategy
Use:
automated accessibility scan
keyboard-only walkthrough
screen reader smoke test
component test for focus behavior
E2E test for critical workflow
manual contrast check
Automated scans catch many structural issues.
Manual checks catch workflow issues.
Interview Answer Structure
Use:
workflow
keyboard
semantics
labels
focus
announcements
contrast
tests
severity
Severity matters.
A missing focus trap in checkout is more urgent than a slightly verbose label in a low-traffic admin view.
Common Mistakes
- Treating accessibility as a final checklist.
- Adding ARIA before using native HTML.
- Forgetting focus return after modal close.
- Removing visible focus styles.
- Announcing every small update.
- Testing only with a mouse.
- Ignoring dark theme contrast.
- Not connecting errors to fields.
Final Mental Model
Accessibility fixes are:
semantic structure
keyboard path
visible focus
clear feedback
recoverable errors
tested workflows
Inclusive UI is stronger UI.