Automatisch accessibility testen – Een paar scenario’s.

Artikel

Automatisch accessibility testen – Een paar scenario’s.

door

Het droomscenario voor elke developer: je drukt op een knop als je commit naar GitHub of je draait npm of composer en je krijgt automatisch testresultaten voor alle accessibility issues die je introduceert met nieuwe code. Zou het niet mooi zijn, als je zo alles kunt controleren? Maar helaas is dit nog een brug te ver. Wat er wel kan, vertel ik je in dit (redelijke technische) artikel.

Hoe betrouwbaar is automatisch testen op toegankelijkheid?

Helaas kan je momenteel (nog) niet alles automatisch testen. Op dit moment kun je ongeveer 30% van de fouten geautomatiseerd uit je code halen (dit is een schatting). Dit is uiteraard afhankelijk van de functionaliteit van je code.

Ik hoor je denken: Dat is erg weinig. Waarom is het zo weinig? Dat komt doordat toegankelijkheid meer is dan alleen correcte code. Het is bijvoorbeeld ook belangrijk dat de automatische test software ‘snapt’ wat je wilt bereiken met je code. Denk aan een <div> met een JavaScript event erop. 

Wat je sowieso nu (nog niet) goed kunt testen is het verhaal dat je vertelt in de door de browser gegenereerde code. Denk hierbij aan het volgende:

Belangrijk is bijvoorbeeld ook:

  • Is de volgorde van de informatie logisch?
  • Staat alles wat bij elkaar hoort ook bij elkaar?
  • Slaan de alternatieve teksten ergens op? 
  • Gaat inzoomen goed en zijn de verschillende responsive views goed? 
  • Is alle functionaliteit met een toetsenbord te bedienen?
  • Geeft een screen reader voldoende feedback aan de blinde gebruiker?

Standaarden en richtlijnen

Testen doe je tegen standaarden. Voor toegankelijkheid gelden de Web Content Accessibility Guidelines, de WCAG, zoals opgesteld door de W3C. De laatste versie van deze guidelines is versie 2.1. Vervolgens zijn er 3 niveaus waar je aan kunt voldoen: A is de basistoegankelijkheid, AA is de wereldwijde standaard en AAA is het strengste niveau. De laatste wordt alleen toegepast bij speciale applicaties.

In Nederland en de EU houden we ons voor het web aan WCAG 2.1 AA. En dat is ook de standaard waartegen we testen. Daarnaast is foutloze, semantische HTML van belang. Hiervoor gelden de specificaties van de HTML Living Standard. Deze specificaties zijn gepubliceerd in een vrij onleesbaar document, de HTML Standard. Gelukkig staat er in de MND Web Docs veel leesbare documentatie, gebaseerd op deze living standard.

Automatisch testen op toegankelijkheid

Testen op toegankelijkheid is anders dan testen op bijvoorbeeld correcte PHP of  JavaScript syntax. Je kunt op twee manieren testen: op de statische code en in de genereerde DOM, dus hoe de browser je website verwerkt en aanbiedt. 

Bij statische code test je op (onder)delen en niet op een samengevoegd geheel. Statisch testen vangt dus veel minder fouten op, omdat het geheel niet gezien wordt.

Daarom kun je alleen echt goed testen op toegankelijkheid als je de DOM van een webpagina analyseert.

Test tools

Er bestaan diverse test tools. Axe van Deque is op dit moment de beste software voor webbouwers. Veel tools draaien op de engine axe-core, zoals Axe DevTools, Google Lighthouse, Microsoft accessibility insights, Pa11y, of de Automated Accessibility Testing Tool (AATT) van PayPal. De wijze van rapporteren en de focus van de soort foutmeldingen kan verschillen, maar de onderliggende engine is hetzelfde.

Sommige tools combineren axe met de HTML checks, zodat je een completere test hebt. En dan zijn er legio NPM modules voor bijvoorbeeld React en Vue. En wil je puur alleen de HTML checken, dan is er de Nu Html Checker.

Dit zijn allemaal gratis open source oplossingen die je kunt gebruiken tijdens het bouwen.

Hoe test je toegankelijkheid dan wel?

Verschillende resultaten?

Helaas geven niet alle tools dezelfde resultaten. Om hier verandering in te brengen werken op dit moment een aantal test tools samen om tot een vergelijkbaar resultaat te komen, dat project heet de Accessibility Conformance Testing Rules. ACT in goed Engels. 

Over het algemeen geldt dat wat je ook terug krijgt als feedback uit een test je er altijd zelf nog kritisch naar moet kijken. Het is namelijk een hulpmiddel en geen complete review. En bedenk je dat er dus maar 30% getest kan worden. Je zult ook altijd handmatige testen moeten uitvoeren met bijvoorbeeld je toetsenbord.

IDE checks 

Toegankelijke code is voor een groot deel correct gebruikte semantische HTML5. En dat valt in de code editor al voor een deel af te vangen door middel van IDE checks. Dus begin bij het begin: foutmeldingen tijdens het code kloppen. Dit kan bijvoorbeeld met PHPStorm of Visual Studio Code.

PHPStorm geeft syntax errors, ook voor HTML. Zoals bijvoorbeeld een form input zonder label. Ook geeft het autocompletes voor ARIA attributen. 

Voor Visual Studio Code kun je axe-linter installeren: Shift further left with Deque’s axe-linter for VS Code | Deque. Dit is een static analyser voor je code die het doorheeft als je bijvoorbeeld een ongeldige tabindex of ARIA role gebruikt. Configuratie doe je via een yaml bestand in je project, waarmee je regels aan en uit kunt zetten.

Als je een andere editor gebruikt, ga eens op zoek of er add-ons zijn of settings waarmee je dit soort checks kunt doen.

Command Line linters

Naast het verkrijgen van foutmeldingen tijdens het tikken van code, kun je er ook voor kiezen om te testen in de command line. Dat kan bijvoorbeeld met:

Testen in de browser tijdens het bouwen

Persoonlijk vind ik dit de handigste manier van testen. Je bent aan het bouwen, je kunt alles als een geheel bekijken en direct op fouten checken. Tijdens het bouwen moet je toch controleren of alles werkt zoals je in gedachten hebt. Doe dan meteen een toegankelijkheids check en test of alles met een toetsenbord werkt.

De go-to browser add-on voor Chrome, Firefox en Edge is (je raad het al) Axe DevTools. Deze add-on voegt een tab toe in de browser inspector waarna je per pagina een test kunt uitvoeren.

Een andere tool die je misschien al kent is WAVE. Deze tool geeft info voor non-techies maar is voor een echte code review niet zo handig.

Testen met GitHub actions

Je hebt een stuk af en je pusht het naar GitHub. Via GitHub actions doe je een aantal checks op de kwaliteit van je code voordat het samengevoegd kan worden.  

Er is echter één grote ‘maar’ bij het gebruik van een accessibility check van een pull request naar GitHub: je kunt een pull request niet helemaal goed- of afkeuren op basis van een accessibility waarschuwing of een fout. Daarvoor zijn de foutmeldingen (nog) niet goed genoeg. Je zult het daarom altijd nog handmatig moeten checken.

Daarnaast kan het lastig, tijdsintensief en daardoor duur zijn als je je code pas in GitHub actions controleert. Ik zou je daarom willen adviseren, als je het via GitHub actions wilt opzetten, dit lokaal te doen via act. Daarmee check je vooraf je pull requests. En zo ben je minder tijd en dus kosten kwijt.

Adrián Bolonio beschrijft in een aantal uitstekende posts hoe je dit stap voor stap aan kunt pakken: Automating the accessibility tests of your source code with GitHub Actions. Hij gebruikt als voorbeeld jest-axe om accessibility unit tests op te zetten voor React.

Workflow

Ik raad je aan de toegankelijkheid in het hele proces te checken en niet pas aan het eind. Dus: in je IDE, bij de build of run, in de browser, en als je het wilt via GitHub actions.

Maar je zult nog altijd aanvullende tests moeten doen, zoals bijvoorbeeld:

  • Testen met een toetsenbord. Is de focus zichtbaar? Is de toetsenbord volgorde logisch? Zijn er geen keyboard-traps? Is de focus management goed, bijvoorbeeld een modal?
  • Testen op verschillende responsive views. Is alles ook als je inzoomt zichtbaar en bruikbaar?
  • Vertel je een logisch verhaal met je HTML5? 
  • Worden dynamische veranderingen uitgesproken voor een screen reader? 
  • Zijn foutmeldingen in formulieren begrijpelijk? 
  • Zijn alt-teksten van afbeelding goed?

Het is dus belangrijk is om niet voor 100% te vertrouwen op een tool. Er zijn veel meer tools, zoals de accessibility opties van Storybook, waarbij je per component kunt testen. De ontwikkelingen gaan razendsnel en het is interessant om te volgen.

Conclusie

Als je pas test op commit naar GitHub ben je eigenlijk te laat. Het kan een mooie extra check zijn, maar het is te kostbaar en te tijdsintensief om het dan pas te doen. 

Testen tijdens ontwikkelen in je eigen browser is sneller en bied je meer opties. Bovendien zie je dan het hele verhaal, niet alleen in code, maar ook in user experience en kun je snel aanvullende handmatige testen doen.

Note; dit is mijn mening op moment van schrijven (juli 2021). To be continued.

  • Rian Rietveld

    Rian Rietveld

    Accessibility Consultant

    Bij Level Level begeleid ik onze projecten zodat deze toegankelijk voor iedereen worden gebouwd. Ik geef training aan het team en de opdrachtgevers om de toegankelijk van een webproject te waarborgen.

    Ga naar de team pagina van Rian Rietveld

Meer weten over automatisch accessibility testen?

Wij staan je graag te woord.