Accessibility Interview Questions and Challenges
# CHAPTER 19
Accessibility Interview Questions and Challenges
1. Introduction
Accessibility (A11y) is no longer a "nice-to-have" bonus skill on a resume; it is a strict legal requirement for enterprise organizations. When interviewing for roles at companies like Google, Microsoft, or any major banking institution, you will be heavily grilled on your accessibility knowledge. Hiring managers are looking for designers who treat WCAG compliance as a baseline engineering constraint, not an afterthought. If you cannot articulate the math behind contrast ratios or explain the concept of Semantic HTML, you will fail the technical screening. In this chapter, we will prepare you for the gauntlet. We will drill the highest-stakes Accessibility Interview Questions, establish a framework for answering live "A11y UI Audits," and ensure you can confidently articulate the ROI of inclusive design.2. Learning Objectives
By the end of this chapter, you will be able to:- Confidently answer the top strategic and technical Accessibility interview questions.
- Defend your portfolio design choices using WCAG mathematics and POUR principles.
- Execute a live, 15-minute "UI Accessibility Audit Challenge" under pressure.
- Articulate the mechanical workflow of testing (Lighthouse, axe, Keyboard).
- Discuss the business ROI and legal necessity of A11y to stakeholders.
3. The Top 10 Accessibility Interview Questions
Q1: What is Accessibility (A11y) and why does it matter? *Answer:* Accessibility is the practice of engineering digital products so they are fully operable by all humans, regardless of permanent, temporary, or situational disabilities. It matters across three pillars: Ethically (it's a human right), Legally (preventing ADA/EAA lawsuits), and Financially (expanding the Total Addressable Market by including the 1+ billion people globally with disabilities).
Q2: Explain the "POUR" principles of the WCAG guidelines. *Answer:* POUR stands for Perceivable, Operable, Understandable, and Robust.
- *Perceivable:* Information cannot be invisible to all senses (e.g., requiring Alt text for images).
- *Operable:* UI must be navigable regardless of hardware (e.g., full Keyboard navigation).
- *Understandable:* Content must be clear and predictable (e.g., explicit error messages).
- *Robust:* Code must be cleanly interpreted by a wide range of Assistive Technologies (e.g., using Semantic HTML).
Q3: How do you ensure your color choices are accessible? *Answer:* I do not rely on subjective aesthetic judgment; I use strict mathematics. I run my Figma palettes through contrast plugins (like Stark or Able) to ensure all normal body text meets the WCAG AA minimum contrast ratio of 4.5:1, and large text/UI components meet the 3.0:1 ratio.
Q4: Walk me through how you design accessible forms.
*Answer:* I never use disappearing placeholder text as the only label. Every input must have a persistent, explicit text <label> placed outside the box. For error validation, I never rely solely on a red border (which fails for color-blind users); I ensure the error state includes a thick border, a warning icon, and explicit text stating the exact error and how to fix it inline.
Q5: What is Semantic HTML, and why should a UX Designer care about it?
*Answer:* Semantic HTML uses tags that have inherent meaning (<header>, <nav>, <button>). While I don't write the final code, I must annotate my designs so developers know exactly which tags to use. If a developer builds my button using a generic <div>, the screen reader has no idea it's interactive, and the blind user is locked out. Clean HTML is the foundation of the screen reader experience.
Q6: How do you design for keyboard-only users? *Answer:* I map out a logical DOM reading order that matches the visual layout. I mandate highly visible "Focus States" (thick outlines) for every interactive element so the user knows where their cursor is. Finally, I design "Skip Links" to bypass massive menus, and I ruthlessly audit my modals to prevent "Keyboard Traps."
Q7: Explain the concept of "Color-Independent Feedback." *Answer:* WCAG states color cannot be the *only* means of conveying information. If a stock market dashboard shows positive stocks in green and negative in red, a color-blind user just sees gray. You must provide a secondary, structural indicator, such as adding an upward arrow icon for positive, and a downward arrow for negative.
Q8: How do you balance a client's desire for a "minimalist" aesthetic with strict accessibility requirements? *Answer:* True minimalism is about clarity, not illegibility. If a client wants 12px ultra-thin light gray text, I explain the "Curb Cut Effect"—that building high-contrast, legible typography doesn't just help low-vision users; it helps every single user reading the app outside in the bright sun. Accessibility improves the UX for everyone, driving higher conversion rates.
Q9: Walk me through your Accessibility Testing workflow. *Answer:* It's a dual-pronged approach. First, I use automated scanners like axe DevTools or Lighthouse to quickly catch missing ARIA labels or severe contrast failures. However, knowing automation only catches ~30% of errors, I follow up with Manual Testing: I unplug my mouse to test keyboard navigation, and I use VoiceOver to ensure the semantic layout makes sense audibly.
Q10: What is your approach to "Alt Text" for images?
*Answer:* Context is everything. If an image conveys vital data, I write concise, descriptive Alt text explaining its purpose. However, if an image is purely decorative fluff used for spacing, I explicitly instruct the developer to use an empty alt="" attribute, which safely hides the image from the screen reader, reducing cognitive noise for the user.
4. The Live Accessibility Audit Challenge
The Scenario: You are given a printed screenshot of a webpage and a red pen. *Prompt: "You have 10 minutes. Identify as many accessibility failures on this UI as possible, and explain how to fix them."*Your Execution Framework:
- 1. The Contrast Pass: Instantly circle any light gray text on white backgrounds, or white text placed directly over busy photographs. Write: *"Fails 4.5:1 ratio."*
-
2.
The Form Pass: Circle any input boxes that only use Placeholder text instead of permanent labels. Write: *"Cognitive amnesia / Missing
<label>."*
- 3. The Target Pass: Circle tiny UI icons (like a 16px 'X' to close a modal) that are stacked tightly together. Write: *"Fails 44x44px touch target rule (Motor impairment)."*
- 4. The Keyboard Pass: Look at the selected elements. Ask: *"Is there a visible Focus Ring designed for keyboard users?"* (Usually, there isn't).
- 5. The Hierarchy Pass: Look at the typography. Does it jump from a massive H1 title down to tiny text? Write: *"Verify Semantic HTML heading hierarchy."*
5. Best Practices for the Portfolio Presentation
- Include an "A11y Checklist": In your portfolio case studies, dedicate a section specifically to Accessibility. Show a screenshot of your Figma file demonstrating how you annotated the tab order for developers. Show a screenshot of the "Able" plugin proving your contrast passes WCAG AA. This puts you in the top 5% of candidates instantly.
6. Common Mistakes
- "I use automated plugins to fix accessibility." Never say this in an interview. As discussed in Chapter 14, automated tools only catch 30% of errors. If you say you rely purely on Lighthouse, the Senior Designer interviewing you will instantly know you do not actually understand manual keyboard or cognitive accessibility testing.
7. Mini Project: Do a Mock A11y Interview
Set a timer for 5 minutes and answer this question out loud to an empty room: *Prompt: "A Lead Developer tells you they don't want to use the native HTML<button> tag because it's hard to style, and they want to build all the buttons out of <div> tags instead. Walk me through the exact technical arguments you would use to defend the necessity of Semantic HTML for Assistive Technologies."*
(Hint: Discuss native keyboard focus, the Enter key event listener, and how screen readers rely on the tag to announce the element's purpose to a blind user).