Q368: Accessibility Audit Simulation Keyboard Screen Reader and Semantic Quality

What Interviewers Want To Evaluate

Accessibility audit simulations test whether you can review real workflows, not only quote guidelines.

Interviewers want to know how you test keyboard paths, focus order, semantics, labels, screen reader output, contrast, forms, modals, tables, charts, and motion.

Senior frontend engineers should make accessibility operational.

Short Interview Answer

For an accessibility audit, I choose critical user flows, test keyboard navigation, verify focus management, inspect semantic structure, check labels and error messages, review contrast and motion, test screen reader output for complex widgets, and document issues by severity. I pair automated tools with manual testing because automation cannot validate the full user experience.

Simulation Prompt

Audit a project dashboard.

It contains:

navigation sidebar
search input
filter menu
data table
chart
modal
toast notifications
export action

Walk through your audit.

Scope Critical Flows

Pick flows:

open dashboard
search projects
filter results
open row details
edit settings in modal
export data
recover from error

Audit flows, not isolated components only.

Users experience sequences.

Keyboard Testing

Check:

tab order
focus visibility
skip links if needed
menu open and close
modal trap
escape behavior
arrow key behavior where expected
no keyboard traps

Keyboard testing catches many real issues quickly.

Semantic Structure

Inspect:

landmarks
headings
buttons vs links
form labels
table headers
list semantics
dialog roles
status regions

Semantic HTML is the first accessibility tool.

ARIA should support semantics, not replace missing structure casually.

Screen Reader Review

Test:

page title
landmark navigation
search input label
filter state announcement
table header reading
modal name and description
toast announcement
chart alternative text

Complex widgets need understandable announcements.

If a chart is visual only, provide the key data summary elsewhere.

Visual Accessibility

Check:

contrast
focus ring contrast
text size
touch targets
zoom to 200 percent
reflow
color-only indicators
reduced motion

Accessibility includes visual and motor needs, not only screen readers.

Issue Severity

Classify:

blocker: cannot complete core flow
high: major feature inaccessible
medium: confusing or inefficient
low: polish or edge case

Severity helps teams prioritize.

Automation

Use tools for:

missing labels
contrast
landmark issues
ARIA misuse
heading order hints

Then manually test workflows.

Automated checks are useful, but they are not the audit.

Common Mistakes

• Running one automated scan and stopping.
• Ignoring keyboard-only users.
• Testing components but not flows.
• Adding ARIA without understanding semantics.
• Forgetting error states.
• Not prioritizing issues.
• Treating accessibility as optional polish.

Final Mental Model

Accessibility audit readiness is:

critical flows
keyboard
semantics
screen reader output
visual access
motion
severity
fix plan

Senior frontend engineers make accessibility testable, repeatable, and owned.