Nachweise zur Barrierefreiheit

Accessibility Testing & Evidence

Automated scanners (axe-core, Lighthouse, linter plugins) catch roughly 30–40% of real accessibility barriers — they verify static rules, but cannot judge whether a keyboard flow makes sense, whether focus lands in the right place after an async mutation, or whether an accessible name is meaningful in context. Combine automated checks with manual verification and report exact evidence.

1. Layered Verification Workflow

Execute accessibility checks in deliberate layers:

1. Static & Automated Scan:
   • Run project accessibility lint rules, typechecks, and axe-core / Playwright assertions across all view states (initial, open modal/menu, validation error, empty state).
2. Keyboard-Only Walkthrough (Unplug the Mouse):
   • Walk the entire user task from entry to completion using only Tab, Shift+Tab, Enter, Space, Escape, Arrow keys, Home and End.
   • Verify reachability, activation, visible :focus-visible contrast, logical focus order, and that focus never gets trapped or drops onto <body> or hidden elements.
3. Accessibility Tree & Computed Properties Check:
   • Inspect computed Role, Accessible Name, Description, States (expanded, selected, checked, disabled, invalid) and live regions in DevTools or Playwright accessibility snapshots.
4. Zoom, Reflow & Media Preference Check:
   • Check 320px CSS width (400% zoom), 200% text sizing, prefers-reduced-motion: reduce and forced-colors: active.
5. Assistive Technology Verification (When Available):
   • Test with a real screen reader pair (VoiceOver + Safari, NVDA + Firefox/Chrome, JAWS + Chrome/Edge, TalkBack + Chrome) when available in the runtime environment.

2. Strict Honesty About What Was Tested

Never conflate DOM/accessibility-tree inspection with an actual screen reader test:

• Automated tools prove: valid ARIA syntax/roles, label presence, static contrast on flat backgrounds, duplicate IDs and landmark structure.
• Keyboard walkthroughs prove: focus reachability, tab sequence, modal trapping, focus restoration and keyboard handlers.
• Real assistive technology proves: actual speech output timing, live-region interruption behavior, virtual-cursor vs. focus-mode switching, and browser-specific AT quirks.
• State explicitly in your handoff: OS, browser, automated tools run, manual keyboard paths walked, and whether a screen reader was actually run or only the accessibility tree was inspected.

3. Actionable Barrier Reporting & Root-Cause Fixing

Structure every finding around user impact:

1. User barrier: who is affected (keyboard-only, screen reader, low-vision zoom, voice-control, motion-sensitive user) and what task is blocked or degraded.
2. Reproducible scenario: exact route/state, keystrokes/steps, and observed vs. expected behavior.
3. Relevant standard: cite the specific WCAG 2.2 criterion (e.g., WCAG 2.4.3 Focus Order, WCAG 4.1.2 Name, Role, Value) or WAI-ARIA APG pattern.
4. Root-cause fix: fix the defect in the shared component primitive (Button, Dialog, Select, FormField) rather than patching a single screen whenever the issue stems from a shared primitive.