Pa11y og axe til tilgængelighedstest

Browserudvidelsen axe DevTools (Chrome, Firefox, Edge) tilføjer en fane med navnet "Accessibility" til DevTools. Klik på "Scan alle sider", så viser den alle overtrædelser med berørte elementer, alvorlighedsgrad og vejledning i, hvordan de udbedres. Den er bedst til enkeltstående analyser under udviklingen.

Pa11y er en Node.js-CLI: npx pa11y https://example.com analyserer en URL. Den skriver en liste over problemer til terminalen. Brug den til hurtige analyser, i shellscripts eller til CI-integration med lavt ressourceforbrug.

Kombiner axe-core med Playwright til end-to-end-afprøvning af tilgængelighed: const results = await new AxeBuilder({ page }).analyze(). Kontrollér, at results.violations.length === 0. Det fanger forringelser, før de når produktionen.

jest-axe kører axe mod renderede komponenter i Jest-afprøvninger. Render komponenten med React Testing Library, og giv containeren videre til axe: expect(await axe(container)).toHaveNoViolations(). Nu indeholder hver komponentafprøvning også en tilgængelighedskontrol.

Begge værktøjer lader dig deaktivere eller ændre regler pr. projekt: slå regler fra, der er i konflikt med bevidste designbeslutninger, og gør regler, der er kendt som kritiske, strengere. Dokumenter alle deaktiverede regler med en kommentar, der forklarer hvorfor — det er den sammenhæng, fremtidige udviklere har brug for.

Automatiske værktøjer fanger cirka 30-40 % af WCAG-problemerne. Resten (meningsfuld fokusrækkefølge, læsbar alt-tekst, semantisk overskriftshierarki og ARIA-brug, der afspejler den faktiske brugerfladeadfærd) kræver manuel gennemgang. Automatisering er nødvendig, men ikke tilstrækkelig, for at opnå tilgængelighed.

Afprøv med NVDA på Windows, VoiceOver på Mac og JAWS til målgrupper i virksomheder. Afprøvning med rigtige skærmlæsere afslører problemer, som automatisering ikke kan — forvirrende oplæsninger, ødelagte landmærker og ulogisk fokusrækkefølge. Én gang pr. udgivelse med hver større skærmlæser er et rimeligt udgangspunkt.

Den mest værdifulde validering af tilgængelighed kommer fra brugere med handicap, der anvender det faktiske produkt. Rekrutter gennem konsulentfirmaer inden for tilgængelighed, universiteters handicapservices eller afprøvningsplatforme som UserTesting.com. Deres feedback fra virkeligheden fanger problemer, som ingen automatiske værktøjer finder.

Bloker PR'er ved forringelser af tilgængeligheden (nye overtrædelser), men ikke ved gamle overtrædelser (den eksisterende baseline). På den måde hæver du løbende niveauet uden at blokere for udgivelse. Følg det samlede antal overtrædelser over tid som en tidlig indikator for den generelle tilgængelighed.

Brug flere værktøjer: axe til den omfattende automatiske kontrol, Pa11y som en ekstra vurdering og manuel afprøvning med skærmlæsere til den kvalitative del. Overlapningen er begrænset; tilsammen dækker de flere problemer, end noget enkelt værktøj kan finde.

axe-core driver de fleste tilgængelighedsanalyser; browserudvidelsen er god til enkeltstående kontroller, mens jest-axe- og Playwright-integrationer er gode til løbende afprøvning. Pa11y er en supplerende CLI. Automatisering fanger cirka 30-40 % af problemerne; kombiner den med manuel afprøvning med skærmlæsere (NVDA, VoiceOver) og afprøvning med rigtige brugere med handicap for fuld dækning. Bloker nye forringelser i CI uden at blokere på den eksisterende baseline.