Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
["Components or pages needing accessibility audit","WCAG compliance level requirements (A, AA, AAA)","Accessibility CI pipeline setup needs","Screen reader testing guidance"]
outputs
["Automated accessibility test configurations","axe-core integration with test frameworks","CI pipeline accessibility gates","Manual testing checklists for screen readers"]
linksTo
["test","test-ui","cicd","design-systems"]
linkedFrom
["ui-ux-pro","testing-strategy"]
preferredNextSkills
["test-ui","design-systems"]
fallbackSkills
["test"]
riskLevel
low
memoryReadPolicy
selective
memoryWritePolicy
none
sideEffects
[]
Accessibility Testing
Purpose
Implement automated and manual accessibility testing to ensure WCAG 2.2 compliance. Covers integration of axe-core with testing frameworks, pa11y for page-level scanning, Lighthouse CI for performance and accessibility scoring, and manual screen reader testing protocols.
# Scan a single page
npx pa11y https://myapp.com --standard WCAG2AA --reporter json
# Scan with actions (interact before testing)
npx pa11y https://myapp.com/login \
--standard WCAG2AA \
--actions "set field #email to test@example.com" \
--actions "click element #submit" \
--actions "wait for url to be https://myapp.com/dashboard"
pa11y-ci for multiple pages:
{"defaults":{"standard":"WCAG2AA","timeout":10000,"wait":1000,"chromeLaunchConfig":{"args":["--no-sandbox"]}},"urls":["http://localhost:3000/","http://localhost:3000/login","http://localhost:3000/dashboard",{"url":"http://localhost:3000/settings","actions":["navigate to http://localhost:3000/login","set field #email to admin@test.com","set field #password to testpass","click element button[type=submit]","wait for url to be http://localhost:3000/dashboard","navigate to http://localhost:3000/settings"]}]}
## Manual Screen Reader Test Protocol
### Setup
- macOS: VoiceOver (Cmd+F5)
- Windows: NVDA (free) or JAWS
- Mobile: TalkBack (Android) or VoiceOver (iOS)
### Test Checklist
[ ] Page title announced on navigation
[ ] Headings hierarchy makes sense (h1 > h2 > h3, no skips)
[ ] All images have descriptive alt text (or alt="" for decorative)
[ ] Form labels announced for every input
[ ] Error messages associated with inputs (aria-describedby)
[ ] Buttons and links have descriptive names
[ ] Modal focus trapped inside dialog
[ ] Focus returns to trigger element when modal closes
[ ] Skip-to-content link works
[ ] Dynamic content announced via aria-live regions
[ ] Tables have headers (th) and captions
[ ] Custom widgets have correct ARIA roles and states
### Keyboard Navigation
[ ] Tab order is logical (visual left-to-right, top-to-bottom)
[ ] Focus indicator visible on all interactive elements
[ ] Escape closes modals/dropdowns
[ ] Enter/Space activates buttons
[ ] Arrow keys navigate within composite widgets (tabs, menus)
[ ] No keyboard traps (can always Tab away)
Automate first, manual second -- axe-core catches ~57% of WCAG issues automatically. Add it to every component test. Then do manual testing for the rest.
Test at multiple levels -- Component tests (axe + Testing Library), page tests (pa11y/Lighthouse), and manual screen reader testing.
Fail CI on accessibility regressions -- Treat a11y violations as blocking errors, not warnings.
Use semantic HTML before ARIA -- A <button> is always better than <div role="button">. ARIA is a patch, not a replacement.
Test with real screen readers -- Automated tools miss interaction patterns. Test with VoiceOver/NVDA quarterly.
Include keyboard-only testing -- Unplug the mouse and navigate your app. Every feature must be keyboard accessible.
Test dynamic content -- Modals, toasts, loading states, and live updates need aria-live and focus management testing.
Track accessibility score over time -- Use Lighthouse CI history to detect regressions before they ship.
Common Pitfalls
Pitfall
Problem
Fix
Only testing with axe
Automated tools catch ~57% of issues; misses interaction patterns
Combine axe with manual screen reader testing
Missing focus management in modals
Screen reader users can interact with content behind modal
Trap focus inside dialog; return focus on close
Icon-only buttons without labels
Screen readers announce nothing useful
Add aria-label or visually hidden text
Color as sole indicator
Color-blind users miss status changes
Add icons, text, or patterns alongside color
Skipping heading levels
Screen reader navigation by headings is broken
Use sequential heading hierarchy: h1 > h2 > h3
Auto-playing media
Disorienting for screen reader users
Never autoplay; provide play/pause controls
aria-hidden="true" on focusable elements
Focus lands on hidden element, confusing screen readers
Remove from tab order too: tabindex="-1"
Testing only desktop viewport
Mobile a11y issues missed (touch targets, zoom)
Test at mobile breakpoints; ensure touch targets are 44x44px minimum