Principles of UX / UI (Product Design): Accessibility Testing (Screen Readers, Keyboard Navigation)

Accessibility Testing (Screen Readers, Keyboard Navigation)

Portfolio-Ready Study Guide: Accessibility Testing (Screen Readers, Keyboard Navigation)

What This Is

Accessibility testing ensures your digital products work for everyone, including people with disabilities (e.g., visual, motor, or cognitive impairments). It’s not just ethical—it’s legally required (WCAG, ADA) and improves usability for all users. Example: A hospital’s patient portal might use screen readers to help blind users book appointments, while keyboard navigation lets users with motor disabilities skip repetitive mouse clicks. Poor accessibility = frustrated users, lost revenue, and potential lawsuits.

Key Terms & Principles

• WCAG (Web Content Accessibility Guidelines):
  The global standard for digital accessibility (e.g., WCAG 2.1 AA). Covers contrast, keyboard navigation, screen reader compatibility, and more.
  Example: A "Submit" button must have a 4.5:1 contrast ratio against its background.

• Screen Reader:
  Software (e.g., VoiceOver, NVDA, JAWS) that reads aloud on-screen text and describes UI elements for blind/low-vision users.
  Example: A screen reader announcing "Button, Add to Cart" instead of just "Add to Cart" (missing context).

• Keyboard Navigation:
  Users should be able to tab through interactive elements (links, buttons, forms) without a mouse. Critical for motor disabilities.
  Example: Pressing Tab moves focus from a search bar → "Search" button → results list.

• Focus Order:
  The sequence in which elements receive keyboard focus. Should follow a logical flow (left-to-right, top-to-bottom).
  Example: A modal’s "Close" button should be the last tab stop, not the first.

• Skip Links:
  Hidden links (visible on focus) that let keyboard users jump past repetitive content (e.g., navigation menus).
  Example: A "Skip to Content" link at the top of a webpage.

• ARIA (Accessible Rich Internet Applications):
  HTML attributes that improve screen reader interpretation of dynamic content (e.g., modals, dropdowns).
  Example: aria-label="Close menu" clarifies a hamburger icon’s purpose.

• Semantic HTML:
  Using proper HTML tags (<button>, <nav>, <h1>) instead of <div> for everything. Screen readers rely on these.
  Example: <button> instead of <div onclick="..."> for a clickable element.

• Contrast Ratio (WCAG):
  Text/background color contrast must meet 4.5:1 for normal text, 3:1 for large text.
  Example: Light gray text on white fails; dark gray on white passes.

• Alternative Text (Alt Text):
  Descriptions for images (alt="Golden retriever playing fetch"). Screen readers read this aloud.
  Example: A "Download PDF" icon needs alt="Download PDF"—not alt="icon" or empty.

• Heuristic: Error Prevention (Nielsen’s #5):
  Design to minimize mistakes (e.g., confirmation dialogs, clear labels).
  Example: A "Delete Account" button should require a second confirmation.

• Heuristic: Flexibility & Efficiency (Nielsen’s #7):
  Accommodate both novice and expert users (e.g., keyboard shortcuts).
  Example: Gmail’s Shift + ? shortcut menu.

• Law: Miller’s Law (7±2):
  Users can only hold ~7 items in working memory. Avoid overwhelming them.
  Example: A dropdown menu with 20 options violates this; group into categories.

Step-by-Step / Process Flow

1. Audit Your Design (Figma/Code)

• Action: Use Figma’s A11y plugins to check contrast ratios.
• Action: Run your prototype through WAVE or axe DevTools to flag issues.
• Example: WAVE highlights a low-contrast button in red: "Contrast ratio 2.1:1 (Fail)."

2. Test Keyboard Navigation

• Action: Unplug your mouse. Tab through your prototype (use Shift + Tab to go backward).
• Checklist:
• Can you reach all interactive elements?
• Is focus visible (e.g., a blue outline)?
• Does the tab order make sense?
• Example: If a dropdown menu can’t be opened with Enter, it fails.

3. Test with a Screen Reader

• Action: Enable VoiceOver (Mac: Cmd + F5) or NVDA (Windows). Navigate your design.
• Checklist:
• Are buttons/forms labeled clearly? (e.g., "Search button" vs. "Button").
• Do dynamic elements (modals, tooltips) announce changes?
• Are images described meaningfully?
• Example: A screen reader says "Graphic, image123.jpg" → Fix with alt="Chart: Q3 sales growth".

4. Fix Common Issues

• Problem: Missing focus states.
  Fix: Add :focus-visible in CSS to show outlines (don’t remove them!).
• Problem: Non-semantic HTML.
  Fix: Replace <div class="button"> with <button>.
• Problem: Low contrast.
  Fix: Use WebAIM Contrast Checker to adjust colors.

5. Validate with Real Users

• Action: Recruit users with disabilities (e.g., via UserTesting, Fable) or use Accessibility Insights.
• Example: A blind user struggles to find the "Checkout" button → Add aria-label="Proceed to checkout".

6. Document in Your Portfolio

• Action: Create a case study slide showing:
• Before/after screenshots (e.g., low-contrast vs. fixed contrast).
• A video of you testing with a screen reader (even a 10-second clip).
• Key fixes (e.g., "Added skip links to improve keyboard navigation speed by 40%").

Common Mistakes

Design Interview / Portfolio Tips

What Interviewers Look For

• Problem-Solving: "How would you test a mobile app’s accessibility?" Answer: "I’d start with keyboard navigation (using VoiceOver’s rotor), check contrast with Figma plugins, and recruit users with disabilities for feedback."
• Portfolio Depth: Include a specific accessibility fix (e.g., "Redesigned a form to meet WCAG 2.1 AA by adding error messages and increasing contrast").
• Tricky Distinction: "Usability Testing vs. Accessibility Testing" Answer: Usability testing = general ease of use (e.g., "Can users find the checkout button?"). Accessibility testing = ensuring the product works for people with disabilities (e.g., "Can a screen reader user complete checkout?").

Portfolio Tips

• Show the Process: Include a slide with:
• A screenshot of your design failing an accessibility audit (e.g., WAVE errors).
• A video of you testing with a screen reader (even a short clip).
• The final, fixed design.
• Quantify Impact: "Improved keyboard navigation efficiency by 30% by adding skip links and fixing tab order."
• Avoid Jargon: Instead of "I used ARIA landmarks," say "I added aria-label to clarify button purposes for screen readers."

Quick Check Questions

1. Scenario: A stakeholder says, "We don’t need to test with screen readers—our users aren’t blind."
   Answer: "1 in 4 adults in the U.S. has a disability. Screen reader testing also improves usability for low-vision users, motor disabilities, and even situational impairments (e.g., a broken arm). WCAG compliance is also a legal requirement for many organizations."

2. Scenario: You’re reviewing a form where the "Submit" button has no focus state. What’s the risk, and how do you fix it?
   Answer: Risk: Keyboard users can’t see where they are, leading to frustration or abandonment. Fix: Add :focus-visible { outline: 2px solid #005fcc; } to CSS.

3. Scenario: A designer argues, "We don’t need alt text for decorative images."
   Answer: "True—but decorative images should use alt="" (empty alt text) so screen readers skip them. Otherwise, they’ll announce "Image, image123.jpg", which is confusing."

Last-Minute Cram Sheet

1. WCAG 2.1 AA = 4.5:1 contrast ratio (3:1 for large text).
2. Screen readers read alt text, ARIA labels, and semantic HTML (<button>, <nav>).
3. Keyboard navigation must work for all interactive elements (no mouse required).
4. Focus order should match visual flow (left-to-right, top-to-bottom).
5. Skip links let keyboard users jump past repetitive content (e.g., navigation).
6. ARIA is a last resort—use native HTML first (e.g., <button> over <div role="button">).
7. Test early: Accessibility isn’t a "final check"—it’s part of every design iteration.
8. ⚠️ "We’ll fix accessibility later" = Never happens. Advocate for it upfront.
9. ⚠️ Removing focus outlines = Breaks keyboard navigation. Use :focus-visible instead.
10. ⚠️ Color alone = Fails WCAG. Add text/icons (e.g., red + "Error").