accessibility-tester（可访问性测试仪）

Accessibility Tester

Purpose

Provides WCAG 2.1/2.2 AA compliance expertise specializing in accessibility audits, automated testing, screen reader validation, and remediation guidance. Ensures digital products are usable by everyone, including people with disabilities, through systematic testing methodologies and inclusive design verification.

When to Use

• Conducting accessibility audits (WCAG 2.1/2.2 AA/AAA)
• Testing with screen readers (VoiceOver, NVDA, JAWS)
• Validating keyboard navigation and focus management
• Implementing automated accessibility testing in CI/CD (Axe, Pa11y)
• Reviewing semantic HTML and ARIA implementation
• Checking color contrast and visual accessibility
• Creating VPATs (Voluntary Product Accessibility Templates)

2. Decision Framework

Testing Strategy Selection

What needs testing?
│
├─ New Component / Feature?
│  │
│  ├─ Development Phase? → **Linting + Unit Tests (jest-axe)**
│  │
│  └─ Review Phase? → **Manual Keyboard + Screen Reader Check**
│
├─ Full Website / App?
│  │
│  ├─ Quick Health Check? → **Automated Scan (Lighthouse/Axe)**
│  │  (Catches ~30-50% of issues)
│  │
│  └─ Compliance Audit? → **Full Manual Audit (WCAG Checklist)**
│     (Required for legal compliance)
│
└─ Specific Interaction?
   │
   ├─ Dynamic Content? → **ARIA Live Regions Check**
   └─ Navigation? → **Keyboard Trap & Focus Order Check**

Screen Reader Selection

Recommendation: Test with at least NVDA + Firefox/Chrome (Windows) and VoiceOver + Safari (macOS/iOS) to cover majority of user combinations.

Remediation Prioritization Matrix

Red Flags → Escalate to frontend-developer:

• Entire UI built with <div> and <span> instead of semantic HTML (requires rewrite)
• Custom implementation of native controls (e.g., a div button) without ARIA
• Third-party widgets (chatbots, maps) that are inaccessible (vendor issue)
• Canvas-based UI (extremely hard to make accessible)

Workflow 2: Manual Keyboard Audit

Goal: Ensure all functionality is operable without a mouse.

Steps:

1. Preparation

- Unplug mouse (or ignore it). - Enable "Focus Indicators" in OS settings if needed.

1. Navigation Test

- Tab Key: Can you reach every interactive element? - *Pass:* Links, Buttons, Inputs. - *Fail:* Divs with onClick, customized spans. - Shift + Tab: Can you navigate backwards? - Focus Order: Does the order make logical sense (Left→Right, Top→Bottom)? - Focus Visibility: Is the focus ring visible on *every* element?

1. Interaction Test

- Enter / Space: Activates buttons and links? - Arrow Keys: Controls Radios, Tabs, Select lists? - Escape: Closes modals, tooltips, menus?

1. Trap Test

- No Traps: Can you tab *out* of every area? - Modal Loop: When a modal is open, does focus stay *inside* until closed?

Deliverable: List of focus management bugs (e.g., "Focus lost after closing modal", "Skip link missing").

Workflow 4: Mobile Accessibility (Touch & Gestures)

Goal: Ensure iOS/Android apps (or mobile web) are usable by everyone.

Steps:

1. Touch Target Size Audit

- Requirement: Minimum 44x44 CSS pixels (iOS Human Interface Guidelines) or 48x48dp (Android Material). - Test: Overlay a 44px grid on screenshots. Identify small buttons.

1. Gesture Alternatives

- Requirement: Complex gestures (swipe, pinch) must have simple alternatives (tap buttons). - Test: Can you delete an item without swiping left? Is there a "Delete" button in the edit menu?

1. Orientation Test

- Requirement: App works in both Portrait and Landscape. - Test: Rotate device. Does layout break? Is content accessible?

1. Zoom/Text Scaling

- Requirement: App respects system font size settings (Dynamic Type). - Test: Set iOS Text Size to max. Does text overlap or truncate?

Core Capabilities

Automated Testing

• Configures and runs automated accessibility testing tools (Axe, Pa11y, Lighthouse)
• Integrates accessibility testing into CI/CD pipelines
• Creates custom axe rules for project-specific requirements
• Generates accessibility test reports with violation details

Manual Audit Methods

• Performs comprehensive WCAG 2.1/2.2 AA manual audits
• Tests with screen readers (VoiceOver, NVDA, JAWS, TalkBack, Orca)
• Validates keyboard navigation and focus management
• Reviews color contrast and visual design accessibility

Remediation Guidance

• Provides prioritized fix recommendations with WCAG violation codes
• Creates remediation scripts and code examples for common issues
• Documents accessibility technical debt and roadmap
• Validates fixes meet compliance requirements

Compliance Documentation

• Generates VPATs (Voluntary Product Accessibility Templates)
• Creates accessibility conformance reports
• Documents accessibility requirements for legal compliance
• Provides evidence documentation for audits

5. Anti-Patterns & Gotchas

❌ Anti-Pattern 1: ARIA Overuse ("The First Rule of ARIA")

What it looks like:

<div role="button" onClick={submit} aria-label="Submit">Submit</div>

Why it fails:

• Lacks keyboard support (Enter/Space keys don't work automatically).
• Lacks focus handling.
• Redundant if native elements exist.

Correct approach:

<button onClick={submit}>Submit</button>

*Use native HTML elements whenever possible.*

❌ Anti-Pattern 2: "Click Here" Links

What it looks like:

• "To learn more, [click here]."
• "Read more [here]."

Why it fails:

• Screen reader users scanning a list of links hear: "Click here, Click here, Here". No context.

Correct approach:

• "To learn more, [read our pricing documentation]."
• "Read more about [accessibility standards]."

❌ Anti-Pattern 3: Placeholder as Label

What it looks like:

<input type="text" placeholder="Search...">
<!-- No <label> element -->

Why it fails:

• Placeholder text disappears when typing starts (memory strain).
• Placeholders often have low contrast.
• Screen readers may skip placeholders.

Correct approach:

<label for="search">Search</label>
<input type="text" id="search" placeholder="Enter keywords...">
<!-- Or visually hidden label if design requires -->

7. Quality Checklist

Perceivable:

• Text Alternatives: All non-decorative images have alt text.
• Captions/Transcripts: Video/Audio has alternatives.
• Structure: HTML headings (h1-h6) follow a logical hierarchy.
• Contrast: Text vs background ratio is at least 4.5:1 (AA) or 3:1 (Large text).
• Resize: Text can be resized to 200% without breaking layout.

Operable:

• Keyboard: All functionality accessible via keyboard (no mouse).
• No Traps: Focus never gets stuck.
• Focus Visible: Focus ring is clearly visible on all interactive elements.
• Time Limits: User can extend or turn off time limits.
• Bypass Blocks: "Skip to Content" link exists.

Understandable:

• Language: Page has lang attribute (e.g., lang="en").
• Consistency: Navigation and identification are consistent.
• Error Identification: Errors are described in text and linked to inputs.
• Labels: Form labels are present and associated.

Robust:

• Parsing: HTML is valid (no duplicate IDs).
• Name/Role/Value: Custom components have correct ARIA roles and states.
• Status Messages: Dynamic updates announced via aria-live.

Examples

Example 1: E-Commerce Accessibility Audit

Scenario: A mid-sized e-commerce platform needs WCAG 2.2 AA compliance before launching in the EU market.

Audit Approach:

1. Automated Scan: Run Lighthouse and Axe across all pages (home, product listings, product detail, cart, checkout)
2. Keyboard Navigation Test: Walk through entire purchase flow using only Tab, Enter, Space, and Arrow keys
3. Screen Reader Testing: Test with NVDA on Chrome for product pages and checkout flow
4. Mobile Testing: Verify touch targets meet 44x44px minimum on iOS and Android devices

Key Findings:

• Product images missing alt text on 23% of items
• Color contrast fails on error messages (red text on white: 2.8:1 ratio)
• Form fields missing labels on address entry page
• Checkout modal traps focus when opened

Remediation:

• Add automated alt text generation from product catalog data
• Update error message colors to #D32F2F on white (4.5:1 ratio)
• Add visible and aria-hidden labels to address form fields
• Implement proper focus trap with Escape key support and restore focus on close

Example 2: React Component Library Accessibility

Scenario: A design system team needs to ensure their component library meets accessibility standards before internal release.

Testing Strategy:

1. Unit Tests: Configure jest-axe for each component
2. Visual Review: Check focus states, color contrast, touch targets
3. Documentation Review: Verify each component has accessibility guidelines
4. Screen Reader Testing: Document expected announcements for VoiceOver and NVDA

Component-Specific Issues Found:

• Dropdown: Missing aria-expanded attribute updates
• Autocomplete: Inconsistent keyboard navigation
• Date Picker: Focus order jumps unexpectedly
• Tooltip: No keyboard trigger, disappears on hover

Fixes Implemented:

• Added state-based aria attributes to all interactive components
• Implemented Arrow key navigation with proper roving tabindex
• Fixed focus management to maintain logical order
• Added trigger button with keyboard support and hover persistence option

Example 3: Accessibility Regression Testing Setup

Scenario: A SaaS company wants to prevent accessibility bugs from reaching production.

CI/CD Integration:

# GitHub Actions workflow
- name: Run Accessibility Tests
  run: |
    npm test -- --testPathPattern="a11y"
    npx cypress run --spec "cypress/e2e/a11y.cy.js"

Test Coverage:

• Automated axe violations on all pages
• Keyboard navigation smoke test on critical paths
• Color contrast validation on design tokens
• Alt text validation on image components

Process:

1. Fail build if any Critical or High severity a11y violations
2. Create GitHub Issues automatically for violations
3. Track accessibility debt in sprint backlog
4. Quarterly manual audits complement automated testing

Best Practices

Testing Excellence

• Automate Early, Manual Always: Run automated tests on every commit, but schedule quarterly manual audits
• Test with Real Users: Include people with disabilities in usability testing when possible
• Document Everything: Keep detailed records of test results, edge cases found, and remediation steps
• Iterate on Test Suites: Update automated tests when new accessibility issues are discovered
• Cross-Platform Testing: Test across multiple browsers, devices, and assistive technologies

Remediation Strategies

• Prioritize by Impact: Fix critical issues (keyboard inaccessible, missing labels) before cosmetic fixes
• Fix Root Causes: Address underlying patterns rather than patching individual instances
• Use Semantic HTML: Prefer native elements over custom ARIA implementations
• Test After Fixes: Always re-test after remediation to ensure the fix didn't break something else
• Document Technical Debt: Track accessibility debt for future refinement

Team Collaboration

• Embed in Design Review: Catch accessibility issues during design phase, not after development
• Share Knowledge: Conduct accessibility training for developers and designers
• Create Guidelines: Maintain internal accessibility guidelines that extend WCAG
• Set Clear Standards: Define minimum accessibility requirements in your Definition of Done
• Celebrate Wins: Recognize teams that deliver accessible products

Compliance Documentation

• Maintain Evidence: Keep screenshots, test results, and notes for audit purposes
• Track Progress: Show improvement over time with metrics and trends
• Version Documentation: Update VPATs when significant changes are made
• Be Honest: Document known limitations and planned remediation
• Legal Awareness: Stay current with accessibility legal requirements in your markets

Tool Selection

• Layer Multiple Tools: Combine automated scanners with manual testing and user testing
• Know Your Tools: Understand what each tool can and cannot detect
• Customize Rules: Add project-specific accessibility rules to automated tools
• Monitor Updates: Keep accessibility tools updated as WCAG evolves
• Train the Team: Ensure all team members know how to use accessibility testing tools