Lang niet alle eisen uit de richtlijnen voor toegankelijkheid zijn automatisch te toetsen. Toetsen blijft echter mensenwerk en veel in de code kijken. Tools zijn vaak een eerste indicatie voor waar je verder op gaat onderzoeken. Ze kunnen je daarom goed op weg helpen. Voor het verder testen heb je verstand van de norm en digitale toegankelijkheid nodig. Daarnaast is het goed om bovenop deze tests, dus niet in plaats van, te testen met mensen in diverse situaties en met verschillende browsers, apparaten of hulpapparatuur.
Geeft een tool antwoorden?
Met tools kun je een indruk krijgen van de toegankelijkheid van pagina’s. Als je weet wat toegankelijkheid inhoudt en de richtlijnen goed kent. Een tool is geen wondermiddel waarmee je expert wordt. Het zijn wel handige hulpmiddelen. Als je de resultaten niet kan interpreteren, zul je dat moeten leren of je moet een expert inschakelen.
We willen heel graag dat tools ons antwoord geven of dat er 1 tool komt voor heel WCAG 2.1. Dat is helaas onmogelijk, ook willen we dat nog zo graag. Veel punten moet je handmatig checken en daarvoor heb je kennis over toegankelijkheid nodig. Daarnaast moet je de toetsresultaten kunnen controleren, interpreteren en de impact overzien. Ook daar heb je kennis voor nodig. Verlies niet de punten uit het oog die je helemaal niet met behulp van een tool kan checken.
Gratis tools en betaalde tools
Alle tools zijn gratis, behalve Screaming Frog en Adobe Acrobat Pro.
Toetsenbordtoegankelijkheid
Niet echt een tool, maar op elke laptop en desktop te testen. Eén van de belangrijkste en makkelijkste tests die met testen toch vaak vergeten wordt: met je tabtoets door de website. Je krijgt hiermee al een aardig idee van of de website werkend en logisch in elkaar zit. Let hierbij het volgende:
- Kun je zien waar de focus is? (Bijvoorbeeld Chrome voegt zelf een rand toe, dit kun je beter met Firefox testen).
- Is de volgorde van tabben logisch? Voorbeeld: Ga je bijvoorbeeld niet bij een servicemenu opeens van rechts naar links?
- Kun je overal bijkomen, of is niet alles wat een link of knop lijkt ook te bereiken?
- Kun je makkelijk door een formulier en het formulier ook verzenden?
- Blijf je niet ergens ‘hangen’ met de tabtoets?
Toetsenbordtoegankelijkheid testen op een Mac
Wanneer je met een Apple-computer wilt testen op toetsenbordtoegankelijkheid, moet je eerst nog wat instellen:
- Safari Safari > Voorkeuren > Geavanceerd > Tabtoets markeert elk onderdeel op de webpagina
- Firefox Apple > Systeemvoorkeuren > Toetsenbord > Toetsenbordcombinaties > check radiobutton onderaan ‘Alle regelaars’.
- Chrome Voorkeuren > Instellingen > Webinhoud > check ‘Als u op een webpagina op Tab drukt worden links en velden in een formulier gemarkeerd’.
Testen met browsers en browsertools
- Firefox met:
- Axe
Een add-on die je in verschillende browsers kunt gebruiken. Daarnaast kun je deze tool ook integreren in andere testsoftware. Een van de betere tools om toegankelijkheid te testen. Axe is duidelijk, onder andere doordat de tool alleen fouten weergeeft die met grote zekerheid automatisch vast te stellen zijn. Ook geeft ze fouten aan die je zelf niet zo snel handmatig vindt. Daarnaast goede doorverwijzingen naar documentatie. - Headingsmap
Deze add-on zorgt voor een overzicht van koppen op een webpagina. Let op deze tool kan ook koppen laten zien die niet getoond worden aan screenreaders, bijvoorbeeld door display:none - A11y Outline
In screenreaders kun je met toestsencombinaties een overzicht opvragen van bijvoorbeeld alle koppen op een pagina, alle links of ‘landmarks’. Met deze extensie kun je deze overzichten opvragen zonder dat je een screenreader nodig hebt. - Accessibility Tree
Klik ergens op een pagina en selecteer ‘Inspect Element’ om de Firefox Developer Tools te openen. Klik op het tabblad ‘Accessibility’. Je kunt nu onderzoeken hoe hulptechnolgie de pagina en elementen ziet. Er zijn extra opties voor het onderzoeken van toetsenbordtoegankelijkheid en simulatie van verschillende soorten kleurenblindheid.
- Axe
- Chrome met
- Axe
Een add-on die je in verschillende browsers kunt gebruiken. Daarnaast kun je deze tool ook integreren in andere testsoftware. Een van de betere tools om toegankelijkheid te testen. Axe is duidelijk, onder andere doordat de tool alleen fouten weergeeft die met grote zekerheid automatisch vast te stellen zijn. Ook geeft ze fouten aan die je zelf niet zo snel handmatig vindt. Daarnaast goede doorverwijzingen naar documentatie. - Accessibility Insights
Hiermee kun je mooi koppen en tabvolgorde inzichtelijk maken. - Accessibility Tree
Klik ergens op een pagina en selecteer ‘Inspect Element’. Klik op het tabblad ‘Accessibility’. Je kunt nu onderzoeken hoe hulptechnolgie de pagina en elementen ziet. Er zijn extra opties voor het onderzoeken van toetsenbordtoegankelijkheid en simulatie van verschillende soorten kleurenblindheid.
- Axe
Bookmarklet
- Text spacing Bookmarklet
Deze bookmarklet kan je helpen met het testen op Success Criterium 1.4.12 Text Spacing. Dit succescriterium gaat overhet veranderen van regelhoogte, afstand tussen alinea’s, letterafstand en spatiëring. Er mag bij vastgestelde veranderingen geen sprake zijn van verlies van content of functionaliteit.
Een sitebrede inspectie
- Screaming Frog
Screaming Frog is een SEO-spider. Deze spidert een site en helpt je met het opsporen van SEO-problemen. Maar je kunt hem ook heel goed gebruiken om sitebreed te kijken of er bepaalde toegankelijkheidsproblemen zijn. Met de betaalde versie van Screaming Frog spider je een hele site. Je kunt gericht zoeken naar toegankelijkheidsproblemen of plekken waar je toegankelijkheidsproblemen verwacht. Hiervoor kun je het customfilter gebruiken en bijvoorbeeld gericht zoeken op inline styles, tabellen, afgekeurde elementen. Ook kun je goed zien of bijvoorbeeld koppen beschrijvend zijn. Kosten: jaarlijks ongeveer 120 euro, exclusief btw. Met de betaalde versie kun je een hele site spideren, specifieke filters instellen en ook resultaten opslaan.
Contrast
Tools om contrast te meten heb ik beschreven in het uitgebreide artikel over contrast: Tools om contrast te meten.
Parsen / valideren
- W3 Validator NU
Experimentele validator. Als je ‘Show image report’ aanvinkt krijg je een overzicht van afbeeldingen op de pagina die in de HTML aangeboden worden. Je ziet dan afbeelding met de opgegeven alternatieve tekst. - Parse Error Bookmarklet
Nadat je bovenstaande validator hebt gebruikt kun je met deze experimentele bookmarklet filteren. Alleen parsefouten zouden dan over moeten blijven.
Testen met screenreaders
Een screenreader kan je helpen inzicht te krijgen in de toegankelijkheid van een website. Mijn ervaring is wel dat het moeilijk is er mee te leren werken als je niet echt een screenreader nodig hebt. Bedenk ook dat je het met 1 screenreader test die zaken wel of niet ondersteunt en die ook bugs kan bevatten
- VoiceOver voor Mac
VoiceOver zit standaard op Applecomputers. Met deze gratis screenreader kun je goed kijken hoe een screenreader door een pagina gaat. VoiceOver zet je aan met Cmd F5. Met ctrl + alt+ u krijg je een overzicht van koppen en links. Een uitgebreide handleiding: Using VoiceOver to Evaluate Web Accessibility - NVDA
NVDA is een open source screenreader voor Microsoft Windows. Je kunt deze gratis installeren op een computer of vanaf een USB-stick draaien. Download NVDA. Het kost tijd om met een screenreader te leren werken. Hoe je met NVDA leest kun je lezen in de Engelstalige NVDA User Guide
Testen op UTF-8 en basistaal
W3C Internationalization Checker Online tool die checkt op taal van de pagina, UTF-8 in meta-element en of UTF-8 is aangegeven via HTTP-headers. Een aantal punten die de tool signaleert:
- Het voorkomen van een byte order mark (BOM)
- Gebruik van <meta http-equiv=”content-language” content=”nl-NL”/>. In de HTML5 specificatie is dit een achterhaalde eigenschap. Browsers gaan hier inconsistent mee om. Daarom wordt in elke HTML-versie het gebruik ervan afgeraden.
- Probleem als de utf-8 niet zo hoog mogelijk binnen de head en niet binnen de eerste 1024 bytes staat.
- Als er 2 verschillende talen worden aangegeven: xml:lang=”en” en lang=”nl” Met het ene stukje code wordt dus aangegeven dat de pagina in het Engels is, met het andere stukje dat de code in het Nederlands is.
- Als in HTML5 de taal alleen wordt aangegeven met xml:lang. Dit is niet goed in HTML5.
- Als XHTML wordt gepresenteerd als text/html. Er is dan niet alleen een xml:lang attribuut nodig om de taal aan te geven maar ook een gewoon lang attribuut.
Voor meer informatie zie ook techniek H57 Using language attributes on the html element
Testen pdf
Vergeet de pdf’s niet! Pdf’s die je online aanbiedt moeten aan dezelfde eisen voldoen als andere webpagina’s. Ze worden namelijk ook als webpagina gezien. Een klein aantal tools om te testen:
- Adobe Reader
In Reader kun je al snel een indicatie krijgen of er aandacht besteed is aan de toegankelijkheid van pdf. Zie hiervoor ook het artikel: In 5 stappen een pdf onderzoeken op toegankelijkheid en Webrichtlijnen. - PAC: Pdf Accessibility Checker (alleen voor Windows)
- Adobe Acrobat Pro (ook reparatie en bewerken)
Hiermee kun je een (beperkte) toegankelijkheidscontrole doen. Schaf deze tool niet aan voor de werkwijze om ontoegankelijke pdf’s te repareren. Doorgaans doe je dat 100 keer sneller en beter in het brondocument. Firm Ground biedt tooling aan die aansluit op de workflow van het toegankelijk maken van ontoegankelijke pdf’s. En om vanuit Word een volledig toegankelijke pdf te maken zonder nabewerking. - VIP PDF Reader
VIP is een afkorting voor Visually Impaired People, mensen met een visuele beperking. Dit is een pdf-reader speciaal voor mensen die slechtziend zijn. Je kunt een pdf in 1 kolom bekijken, zoomen, een andere kleurcombinatie kiezen. Ook kun je makkelijk door toegankelijke tabellen scrollen, afbeeldingen vergroten en navigeren. Geeft inzicht in hoe je op een andere manier pdf’s gebruikt. Beschikbaar voor Windows en Mac. - Acrobat Reader
Zie ook het artikel In 5 stappen een pdf onderzoeken op toegankelijkheid en Webrichtlijnen
Citrix
Test niet binnen een omgeving als Citrix. Sites en kleuren kunnen net wat anders worden weergegeven.
Documenteer en deel je bevindingen!
Dit onderwerp is een apart artikel waard en heeft ook met ‘governance’ te maken. Voorkom dat binnen je organisatie iedereen het wiel uitvindt of dezelfde fouten blijft maken. Zorg ervoor dat je documenteert wat niet goed werkt en wat wel goed werkt en deel dit binnen je organisatie. Wees hierbij nauwkeurig. Dit helpt je ook te voorkomen dat je een oude oplossing toch weer gaat gebruiken, omdat je niet alle details kan onthouden of waarom het nu wel of niet goed was. Deze bevindingen maakt het ook makkelijk om je te leren voor anderen om oplossingen te controleren. Noteer het volgende:
- Wat heb je onderzocht? Waar heeft het betrekking op (uitklappen van informatie)
- Hoe heb je het onderzocht (welke browser, tool, methode)?
- Waar in de code of het design problemen zaten
- Waarom of voor wie is dit een probleem?
- Had het moeten werken, maar wordt het nog niet ondersteund? Schrijf dat dan ook op, misschien is de oplossing later wel te gebruiken.
- Wat is de manier om het op te lossen (als je dat weet)?
- Datum en naam developer, ontwerper of onderzoeker
Meer tools
Er zijn nog veel meer tools. Deze pagina wordt verder bijgewerkt en dan gepubliceerd op firmground.nl. Kijk wat je zelf prettig vindt werken en check altijd of de resultaten ook kloppen. Heb je een goede aanvulling op deze lijst? Ik hoor het graag via info@iacobien.nl