Behavioral: Advocating for Accessibility (a11y)

Accessibility is a key indicator of a senior engineer's architectural maturity. Building inclusive interfaces involves technical knowledge of semantic HTML, browser APIs, and assistive devices:

"Tell me about a time you advocated for accessibility improvements in an application. How did you pitch the idea to stakeholders, and what was the technical implementation?"

1. What Interviewers Are Evaluating

Stakeholder Communication: Can you pitch technical initiatives (like accessibility) in business terms (e.g., legal risk reduction, market size expansion, SEO gains)?
A11y Technical Knowledge: Do you understand semantic HTML, WAI-ARIA guidelines, keyboard focus management, and color contrast rules?
Workflow Integration: Do you set up systems (testing, design guidelines) so accessibility is built-in rather than treated as a checklist item at the end?

2. Structured STAR Method Answer

Here is a structured answer template focusing on WCAG 2.1 AA Compliance Audit & Remediations.

Situation: The Inaccessible Dashboard

"In my previous role, our SaaS product was auditing its vendor compliance policies. I noticed our main user dashboard—built with unsemantic <div> layout structures, dynamic inline modals, and custom interactive widgets—was completely unusable for keyboard-only navigators and screen readers. We were facing legal compliance risks under the ADA (Americans with Disabilities Act) and losing potential contracts with government and education partners."

Task: The Objective

"My objective was to convince product managers to allocate engineering time to accessibility, audit the codebase, refactor the application to meet WCAG 2.1 AA compliance, and establish automated pipelines to keep it compliant."

Action: The Pitch and Remediations

"Here are the steps I took:

The Business Pitch: Instead of just saying 'we should do this because it's good engineering,' I framed the pitch in terms of business metrics:

Compliance: Pointed out the threat of ADA litigation.

Expansion: Explained that government and enterprise contracts require a VPAT (Voluntary Product Accessibility Template) document.

SEO benefits: Highlighted that screen-reader friendly semantic structures improve indexable search hierarchies.

Integrating Auditing Tooling: I introduced axe-core into our local development server console and set up Lighthouse CI in our GitHub workflow to fail pull requests that dropped below an accessibility score of 90.

Semantic Refactoring: I led the team in replacing nested interactive <div> structures with semantic elements. For custom dropdowns and accordion widgets where native elements couldn't be used, I added appropriate ARIA attributes and keyboard event listeners:
// Refactoring div custom buttons to accessible components
function AccessibleButton({ label, onClick }) {
  return (
    <div 
      role="button" 
      tabIndex={0} // Place component in keyboard tab sequence
      onClick={onClick}
      onKeyDown={(e) => {
        // Standard keyboard triggers for buttons
        if (e.key === "Enter" || e.key === " ") {
          e.preventDefault();
          onClick();
        }
      }}
      className="custom-btn"
    >
      {label}
    </div>
  );
}
Keyboard Focus & Contrast: I audited our global stylesheets. I removed all instances of outline: none (which hides focus outlines), replacing them with customized, highly visible CSS :focus-visible borders. I adjusted our theme palette to ensure a minimum text contrast ratio of 4.5:1 for standard copy.

Team Training: I ran a 1-hour workshop where engineers navigated our application using only keyboard commands with the Mac VoiceOver screen reader enabled. This build empathy and highlighted missing headers and label mappings."

Result: The Outcome

"Within two quarters, we achieved full WCAG 2.1 AA certification, our accessibility Lighthouse rating reached a consistent 100/100, and we successfully landed two major enterprise contracts that previously blocked us due to the lack of a VPAT. Additionally, accessibility checkups are now a standard part of our design handoffs, and our UI library has default accessible components."

Senior-Level Interview Answer

Senior-level highlights of this approach:

Speaks in Standards: Use terminology like WCAG 2.1 AA, VPAT compliance, Focus Ring Management, Screen Reader announcements, and Contrast Ratios.
Business-Focused Motivation: Highlight that accessibility expanded client reach (VPAT) and minimized legal issues.
Developer Enablement: Instead of doing the work alone, show that you created templates, ran training, and installed automated pipeline checkers (like axe-core) to empower the entire team.

Common Interview Mistakes

❌ Relying solely on automated checkers

Automated tools (like Lighthouse or Axe) only catch about 30-40% of accessibility issues. A senior engineer knows that manual testing (keyboard flow, screen reader usability) is the only way to verify compliance.

❌ Recommending "Overlay Widgets"

Do not recommend overlay widgets (third-party tools that insert toolbar widgets to adjust font size or colors). They are generally disliked by users with disabilities, can cause performance degradation, and do not solve core code inaccessibility.

Key Takeaways

Speak the Business Language: Connect accessibility to revenue growth, search engine optimizations, and contract acquisitions.
Prioritize Keyboard Navigation: Ensure every interactive element can be reached via Tab, triggered by Enter/Space, and displays a clear focus ring.
Implement Shared Tooling: Use axe-core, Lighthouse CI, and eslint-plugin-jsx-a11y to build automatic guardrails directly in the development lifecycle.

Behavioral: Advocating for Accessibility