Så gör TetraLogical tillgänglighetskrav till tester
Den 14 oktober berättade Craig Abbott på TetraLogical att de släppt sitt komponentbibliotek som öppen källkod. Det som enligt Abbott skiljer biblioteket från andra är kraven. Varje komponent har en lista över vad den ska klara, knuten till WCAG 2.2 och egna rekommendationer, och tester som kontrollerar varje krav.
Varför det glider tillbaka
Abbott beskriver ett vanligt mönster. En organisation betalar för en granskning och rättar felen. Några uppdateringar senare har allt i tysthet glidit tillbaka. Ingen märker det förrän en kund klagar eller en ny bedömning beställs, och det kan bli dyrt, skriver han.
TetraLogical har publicerat dokumentationen, kraven, testscenarierna och de automatiska testerna tillsammans med koden.
Åtta komponenter, samma sju rubriker
Version 1.0.0 innehöll åtta komponenter:
- Accordion
- Breadcrumbs
- Dialog
- Disclosure
- Pagination
- Tabs
- Text input
- Textarea
Fler ska komma de närmaste månaderna, skriver Abbott. Varje komponent dokumenteras under samma rubriker, här i vår översättning:
- Vilket problem den löser
- När den ska användas
- När den inte ska användas
- Var den ska användas
- Tillgänglighetskrav
- Testscenarier
- Kompatibilitet med hjälpmedel
Kraven, knutna till WCAG 2.2
För varje komponent har de listat de kriterier i WCAG 2.2 som gäller, på nivå A, AA och AAA. De har lagt till egna rekommendationer för sådant WCAG inte täcker, till exempel användbarhet med högkontrastteman. I bibliotekets kravdokument är AA golvet, och AAA beskrivs som god praxis där det går.
Kraven är sorterade i tio teman, bland annat tangentbord, färg och kontrast, navigering samt pekare och beröring. Ta flikkomponenten Tabs. Under tangentbord finns bland annat krav knutna till kriterierna 2.1.1, 2.1.2 och 2.4.3, alla tre på nivå A. Ett av dem lyder "The tabs component does not trap focus", alltså att fokus inte fastnar i komponenten.
Scenarier som hela teamet kan läsa
Varje krav har blivit ett testscenario i klartext, skrivet med stegen Given, When och Then (givet, när, då). Enligt Abbott blir testerna då lättare att förstå för den som inte är utvecklare, och kraven blir acceptanskriterier som hela teamet kan läsa.
Varje scenario är märkt med det kriterium det gäller, eller som en rekommendation. Bakom varje steg finns kod som styr en riktig webbläsare. Abbott menar att de därför går längre än färdiga tillgänglighetskontroller, som mest granskar statisk HTML. Han rekommenderar ändå sådana verktyg.
Testerna kan bland annat köras för nivå A och AA, för rekommendationerna eller för ett enda kriterium. De kan också kopplas till en CI-kedja (kontinuerlig integration), så att de körs vid varje ändring i koden.
Där maskinen slutar
Gränsen mellan automatiskt och manuellt är uttalad:
- 97 procent av scenarierna i version 1.0.0 är helt automatiska.
- För resterande 3 procent samlar testerna in det en granskare behöver och listar vad som ska kontrolleras för hand.
- All testning med hjälpmedel är manuell.
Abbott skriver att allt inte går att automatisera på ett pålitligt sätt, och att de skulle vara misstänksamma mot verktyg som påstår det. Enligt kravdokumentet ska komponenterna fungera med bland annat:
- JAWS med Chrome
- NVDA med Firefox
- VoiceOver i Safari på macOS och iOS
- Voice Access i Windows 11
- skärmförstoring
- webbläsarzoom till 200 procent
- högkontrastteman
Förbehållen
TetraLogical är tydliga med gränserna. Komponenterna är byggda för deras egna behov och är, med deras ord, "not a production-ready design system", inget färdigt designsystem för skarp drift. Testa dem i din egen produkt först, skriver de. Även en komponent som klarar alla automatiska och manuella tester kan bete sig oväntat med en viss skärmläsare eller webbläsare.
Låna arbetssättet
Du behöver inte använda deras komponenter för att göra som de:
- Skriv kraven per komponent, och knyt varje krav till ett kriterium eller märk det som rekommendation.
- Skriv scenarierna så att hela teamet kan läsa dem.
- Kör de automatiska testerna vid varje ändring, så syns det när något glider tillbaka.
- Lista det maskinen inte kan avgöra, och testa med hjälpmedel för hand.
Då har du en chans att upptäcka felen när de uppstår, i stället för vid nästa granskning. Léonie Watsons syn på varför en lägstanivå blir målet tar vi upp i vår artikel WCAG AA är ett golv, inte ett tak.
Vill du veta var din webbplats står i dag? Läs mer om vår tillgänglighetsanalys.
Karin Holm Grundare, Holm Digital AB