Q088: Accessibility Audit and Remediation
What Interviewers Want To Evaluate
This question tests whether you can improve accessibility systematically rather than treating it as a checklist at the end. Interviewers want audit methods, prioritization, keyboard testing, screen reader behavior, semantic HTML, forms, focus management, automated tooling, manual testing, design collaboration, and remediation planning.
Senior frontend engineers should be able to lead accessibility improvements across product surfaces.
Short Interview Answer
An accessibility audit should combine automated checks, manual keyboard testing, screen reader testing, semantic review, color and motion review, and flow-based testing of critical tasks. I would prioritize issues by user impact and legal or business risk, fix shared components first when possible, add regression tests, update design-system guidance, and track remediation with owners. Automated tools help, but they cannot replace manual testing of real workflows.
Detailed Interview Answer
Accessibility is a product quality issue. It affects whether users can complete tasks. A senior answer should talk about workflows, not only isolated components.
Start by defining scope:
Which user flows are critical?
Which components are shared?
Which issues block task completion?
Which issues affect many routes?
Which fixes belong in the design system?
What can automation catch later?
Who owns remediation?
Audit Methods
Use automated tools for common issues like missing labels, contrast failures, invalid ARIA, and landmark problems. Use manual testing for keyboard paths, focus order, screen reader announcements, modal behavior, dynamic content, and error recovery.
Manual testing is essential because many accessibility issues are about interaction, not static markup.
Keyboard Testing
A critical flow should be usable with the keyboard. Check tab order, visible focus, skip links, menus, dialogs, forms, tables, tooltips, and custom controls.
If a component needs mouse precision to operate, it is likely excluding users.
Screen Reader Testing
Screen reader testing checks whether labels, roles, headings, landmarks, error messages, and dynamic updates make sense when read aloud.
Do not add ARIA as decoration. Native semantic HTML is often more reliable than custom ARIA-heavy controls.
Focus Management
Focus management matters in modals, drawers, route transitions, validation errors, menus, and async updates.
When a modal opens, focus should move into it. When it closes, focus should return logically. When validation fails, users should be guided to errors without losing context.
Prioritization
Prioritize issues that block critical tasks, affect many users, live in shared components, or create legal or compliance risk.
Fixing a shared inaccessible dropdown may improve dozens of pages. Fixing one isolated color issue may be lower priority unless it blocks readability.
Remediation Plan
A remediation plan should include issue, impact, owner, affected routes or components, proposed fix, test plan, and rollout order.
If the issue lives in the design system, coordinate design and engineering so the pattern does not return.
Common Mistakes
A common mistake is relying only on automated tools. Another is treating accessibility as a separate cleanup task after UI is already designed.
Another mistake is using ARIA to force custom elements to behave like native controls when native controls would be simpler and more robust.
Senior Trade-Offs
Some accessibility fixes are quick. Others require product and design trade-offs, especially dense dashboards or complex custom widgets.
The senior approach is to protect task completion and build accessible patterns into reusable components.
Code or Design Example
An audit item should be specific enough to fix and verify.
type AccessibilityIssue = {
flow: string;
component: string;
impact: "blocker" | "serious" | "moderate" | "minor";
affectedUsers: string[];
fixOwner: string;
regressionTest: "unit" | "integration" | "e2e" | "manual";
};
This makes remediation actionable instead of vague.
Production Example
Suppose an enterprise dashboard has custom dropdown filters that cannot be opened with the keyboard and do not announce selected values. The fix should happen in the shared filter component, include keyboard behavior, labels, focus management, tests, and documentation.
Then all dashboard filters benefit.
Design Collaboration
Accessibility requires design collaboration. Designers can define focus states, contrast, error messaging, reduced motion behavior, and content hierarchy.
Engineers should give design partners feedback early when a pattern is hard to make accessible.
Regression Prevention
Use lint rules, component tests, accessibility checks, Storybook checks if available, E2E tests for critical keyboard flows, and design-system documentation.
The goal is to prevent the same issue from being reintroduced.
Revision Notes
Accessibility audits require automated checks, manual testing, keyboard flows, screen reader review, prioritization, remediation, and regression prevention.
Key Takeaways
Accessibility is not a final polish step. It is part of product architecture and shared component quality.
Follow-Up Questions
- Why are automated tools not enough?
- How do you test keyboard accessibility?
- How do you test screen reader behavior?
- What is focus management?
- How do you prioritize accessibility issues?
- When should fixes happen in the design system?
- How do you prevent regressions?
- What makes custom controls risky?
- How do designers support accessibility?
- How do you audit a critical flow?
How I Would Answer This In A Real Interview
I would describe accessibility audit as workflow-based testing with automated and manual checks. I would prioritize user-blocking and shared-component issues, remediate with owners and tests, and update design-system patterns so fixes scale.