Toegankelijkheid van een website testen: hoe doe je dat?

Auteur: Diede Gulpers

WCAG

In dit artikel leg ik uit hoe je zelf de toegankelijkheid van je website kan toetsen met een aantal basis tests. Voor deze tests heb je weinig technische kennis nodig. Eerst geef ik je 5 tests die je zonder hulpmiddelen kan doen en 2 tips over wat je niet hoeft testen. Daarna geef ik een lijst van toegankelijkheid scanners, vaak wcag scans, die een breder beeld geven over of de website voldoet aan de toegankelijkheidsrichtlijnen. Hiermee kan je zelf de eerste stappen zetten voor een toegankelijke website.

Dit artikel helpt je om vast te stellen of er rekening is gehouden met toegankelijkheid. Dit is handig als je bijvoorbeeld als ambtenaar zelf een website laat ontwikkelen en oog wil houden op de toegankelijkheid van websites. Als ontwikkelaar of ontwerper heb je ook iets aan deze tests, en eveneens als je als burger wil weten of een overheidswebsite aan toegankelijkheid heeft gedacht. Hou er rekening mee dat je met deze uitleg controleert op de makkelijk te toetsen onderwerpen. Voor de complexe en contextuele onderwerpen kan je het beste een specialist zoeken.

Toegankelijkheid test bijsluiter

Onze eigen testen zullen niet toetsen of alle richtlijnen voor toegankelijkheid worden gehaald. We testen of een website voldoet aan een paar onderdelen van de toegankelijkheidsrichtlijnen, en dan specifiek die richtlijnen die makkelijk te toetsen zijn. Als onze tests geen fouten vinden hebben we niet alle richtlijnen gecontroleerd. Ook de richtlijnen die we toetsen, toetsen we niet volledig. Komen er fouten uit onze eigen tests, dan weten we wel dat er nog te weinig aan de toegankelijkheid is gedaan.

Mocht je een veel completer beeld willen van je digitale toegankelijkheid dan kan je hiervoor het beste een specialist vragen. Het volledige controleren is namelijk een vak apart en vereist technische kennis van software, inhoudelijke kennis van de richtlijnen & beperkingen en contextuele kennis van de website en haar gebruikers.

We testen niet of de website toegankelijk is voor alle mensen die daar behoefte aan hebben. Deze “groep” is zo divers dat ik het geen groep wil noemen. Een paar voorbeelden van waar de ”groep” uit bestaat: kleurenblinden, ouderen, medewerkers die op werk in oude browsers moeten werken en statushouders die moeten lezen in een vreemde taal. Het spreekt voor zich dat deze groepen allemaal hele andere behoeften van een site hebben.

De scanners die we inzetten gaan niet in staat zijn om een website volledig te toetsen. Dit komt omdat een computer of een menselijke controleur de context van de website moet kennen voor een volledige controle. De menselijke controleur snapt daarbij de context sneller en beter dan een computer. Het is economisch gezien onmogelijk om een computer dit te laten doen. Ook geldt dat wat wel met software te controleren is, nog niet door een bestaande gratis scanner volledig wordt gedaan.

Toegankelijke website Quickscan

Start: bepaal welke pagina’s je gaat controleren en hoe

Om te zorgen voor een goed beeld van toegankelijkheid van een website, wil je meerdere pagina’s testen. Hiermee voorkom je toevalstreffers of toevalsmissers. Voordat we beginnen met het testen maken we eerst een lijstje van de pagina’s die we willen gaan testen. Als je het heel uitgebreid wil aanpakken kan je natuurlijk elke pagina testen, ik adviseer je echter voor deze eerste tests de volgende pagina’s te nemen:

Ook wil je weten hoe je bezoekers jouw website bezoeken. In welke browsers werken zij en bezoeken ze de website vanaf hun mobiel of vanaf hun desktop? Als de website die je test al een tijd online staat kan je dit te weten komen met een tool zoals Google Analytics. Zegt Google Analytics jou niks, dan kun je deze vraag stellen aan de afdeling ICT of je technische partner. Mocht je een nieuwe website laten ontwikkelen dan weet je niet wat voor bezoekers je gaat krijgen. Maar als jouw organisatie al vergelijkbare websites heeft, dan kan je de bezoekersinformatie van deze websites gebruiken om te voorspellen welke browsers en apparaten gebruikt gaan worden.

Als je echter geen gegevens hebt dan kan je altijd nog kijken naar algemene statistieken over website verkeer. Hiervoor kijk ik op gs.statescounter.com. Hierbij kijk je eerst naar welke apparaten er worden gebruikt in Nederland: vooral desktop en mobiel. Daarna kijk je apart naar de mobiele browsers die worden gebruikt en de desktop browsers. Dit zorgt dat je de meest prominente browsers per apparaat type goed in beeld hebt.

Gemiddelde verdeling desktop, mobiel, tablet en console aandeel internetverkeer in Nederland'.
                    ' van november 2019 tot november 2020. Desktop: 54,15%, Mobiel: 41,71%, Tablet 4,13% Console 0,01%.

Verdeling desktop, mobiel, tablet en console gebruik bij internetverkeer

Gemiddelde verdeling desktop browser gebruik in Nederland van november 2019 tot november'.
                    ' 2020. Chrome: 62,34%, Safari 14,66% Firefox 7,88%, Edge Legacy 5,22%, Edge 3,45%, Overig 6,45%.

Verdeling desktop browser gebruik

Gemiddelde verdeling mobiel browser gebruik in Nederland van november 2019 tot november'.
                    ' 2020. Chrome 47,61% 36,71% 12,64% UC Browser 0,93%, Firefox 0,7%, Opera 0,54%, NetFront 0,31%,'.
                    ' Android 0,21%, Edge Legacy 0,11% Overig 0,24%.

Verdeling mobiel browser gebruik

Met deze informatie kan je twee dingen. Ten eerste, als je de tijd en vaardigheden hebt, kan je zorgen dat je in alle prominente browsers test. Door het op je eigen mobiel en desktop te doen is dit ook als gewone gebruiker nog mogelijk (behalve safari, dat werkt alleen op Apple systemen). Met de gegevens over browsers en apparaten weet je welke browsers je kan installeren. Wil je alleen testen in de browser die jij al hebt dan heb je met de gegevens helder voor hoeveel mensen je test. Test je bijvoorbeeld alleen Edge op desktop dan zegt dit alleen iets over de ervaring van 5,12% van het Nederlands internetverkeer.

De toegankelijkheidstests

Voor mijn ideeën van handmatige controles heb ik me gebaseerd op een artikel van Erik Kroes op de fronteers website over hoe je toegankelijkheid toetst en de Quickscan Toegankelijkheid van de koepelorganisatie Ieder(in). Mocht je als ambtenaar diepgaander willen testen hoe toegankelijk je website is dan raad ik je ook aan om met Ieder(in) contact op te nemen voor het betrekken van mensen met een beperking voor het ontwikkelen en testen van de website. Dit voorkomt praten en denken over handicaps zonder dat de mensen met een handicap hierover meepraten.

Test 1: Begrijp je zelf de site?

Controleer op elke pagina van je selectie:

Kijk zowel op desktop als op mobiel naar je website. Er mogen geen pagina’s of delen van pagina’s niet beschikbaar zijn of uitsluitend beschikbaar zijn op mobiel of desktop. Niet iedereen kan namelijk op zowel desktop als mobiel werken.

Als je zelf betrokken bent bij de ontwikkeling van de website, heb je natuurlijk al veel voorkennis. Je bent dan ook een bovengemiddelde gebruiker van deze website. Ik adviseer je echter alsnog om alleen te toetsen of de site voor jou persoonlijk al aan de bovenstaande punten voldoet. Je voorstellen of simuleren dat je een beperking hebt is binnen deze en aankomende tests niet wenselijk, omdat we het over zo ontzettend veel en ontzettend verschillende mensen hebben.

Test 2: Vergroten en verkleinen

Als tweede test gaan we in en uitzoomen op de website. Dit kan op windows desktop met “ctrl & +” en “ctrl & -” of met “cmd & +” en cmd & -” op Apple. Op Chrome mobile door op het “...” menu te drukken, naar “instellingen” te gaan, daar op “toegankelijkheid” te drukken en dan “Tekstschaal” te vergroten of te verkleinen.

Het resultaat moet zijn dat in ieder geval de tekst 200% groter kan worden en dat de rest van de website blijft werken. Je moet dus kunnen blijven navigeren door de pagina en de website heen. Het kan en mag gebeuren dat de website zijn layout aanpast als je inzoomt. Bij onze website verandert de menubalk bij 200%. Dit doet de website omdat hij zich aanpast voor de weergave op kleinere schermen zoals op tablet en mobiel (De website is dan responsive).

Op de afbeelding zie je onze site op 200%, onze navigatiebalk toont dan niet langer de namen'.
                    'van de pagina’s maar in plaats daarvan een uitklapbaar menu.

Met deze test, test je of de browser in staat is de tekst te vergroten. Browsers zijn tegenwoordig namelijk in staat om zonder extra moeite van ontwikkelaars de tekst op een website te vergroten en verkleinen. Wel kunnen ontwikkelaars (per ongeluk) code toevoegen die het schalen blokkeert. Dat is dan ook wat je eigenlijk toetst. Hou er bij deze test rekening mee dat oude browsers tekst niet kunnen schalen. Werkt je doelgroep met een verouderde browser, dan kan je het beste toetsen of het in die browser werkt.

Test 3: Navigeren met het toetsenbord.

Via aangepaste apparaten kunnen fysiek gehandicapte gebruikers de website bedienen zoals wij een website met ons toetsenbord kunnen bedienen. Om de website met het toetsenbord te bedienen ga je naar een pagina en druk je op “tab”. Nu kan je met tab van interactief element naar interactief element springen, het beeld springt dan mee. Interactieve elementen zijn: de knoppen, de links en de invulvelden van een formulier. Met “Shift & tab” kan je achteruit van element naar element springen.

Er zijn dan drie dingen om op te letten: Het element waarop je focust moet een opvallende omlijning krijgen waardoor de gebruiker weet op welk element hij nu focust. Ook moet je bij elk element kunnen komen en je moet elk element kunnen bedienen. Een knop moet je met “Enter” kunnen indrukken, in een formulierveld moet je kunnen typen.

Een pluspuntje voor toegankelijkheid, zoals op onze site, zijn verborgen “sla navigatie over” knoppen. Deze haal je met het tabben naar voren. Ze zorgen ervoor dat iemand die alleen tabs kan navigeren, niet elke keer heel het menu af moet. De knop ziet er bij ons zo uit:

De knop die je bij tab omhoog haalt met de tekst “Sla navigatie over”.

Test 4: Video en audio

Als je video’s op je website hebt staan horen deze een geschreven transcript te krijgen. Ook voor audio bestanden mogen transcripten worden toegevoegd. Een machine gegeneerd transcript, zoals deze op onze mijnwijkplan pagina, is helaas niet afdoende. Deze transcripten maken af en toe fouten zoals: “maak dan een account aan op mijn bij plank” en dit kan een lezer in verwarring brengen.

Bij een stille film geldt een uitzondering wanneer er een audio alternatief is toegevoegd. De stille film is beschikbaar voor zowel de horende als de niet-horende gebruiker. De audio is beschikbaar voor mensen die niet of niet goed zien maar wel kunnen horen. Een transcript is dan niet vereist voor het audio alternatief. Natuurlijk is het wel wenselijk voor mensen met alleen een haptische ervaring. Bijvoorbeeld een slechtziende die eerst braille leert en daarna zicht en gehoor geheel heeft verloren.

Test 5: Alternatieve tekst bij plaatjes

Als laatste test kijken we of plaatjes een alternatieve tekst hebben. Een alternatieve tekst is nodig bij plaatjes die een tekst ondersteunen en verder uitleggen. Plaatjes die gelden als decoratie hoeven geen alternatieve tekst te hebben voor toegankelijkheid. De tekst is wenselijk voor mensen die geen plaatjes kunnen zien of moeite hebben met het begrijpen van plaatjes. Naast slecht zicht zijn er ook mentale handicaps die het moeilijk maken om te begrijpen wat een plaatje symboliseert of waar het naar refereert.

Om plaatjes te controleren gaan we pagina’s inspecteren zoals programmeurs dit doen. We gaan kijken naar de programmeercode waaruit de website is opgebouwd. In deze code gaan we steeds op zoek naar een woord: ‘alt’. Dit staat voor 'alternative tekst' en wordt als een soort formule geschreven. Bij het plaatje in dit artikel van het desktop internetgebruik in Nederland staat bijvoorbeeld:

alt=’Gemiddelde verdeling desktop browser gebruik in Nederland van november 2019 tot november 2020. Chrome: 62,34%, Safari 14,66% Firefox 7,88%, Edge Legacy 5,22%, Edge 3,45%, Overig 6,45%”’.

Wij gaan op zoek naar dit woord ‘alt’ in de code. We willen hierbij altijd “alt=” geschreven zien, opgevolgd met een zinvolle tekst, die het plaatje goed uitlegt. De “alt=” hoort verder altijd in een zin te staan die begint met ‘<img’. Als er geen “alt=” bij een zin met ‘<img’ staat terwijl het plaatje niet decoratief is, dan is dit een fout. Ook wanneer de “alt=’’ is leeg gelaten, is dit niet goed. Net zo is een “alt=12140-tag-download.png” ook geen goede uitleg van een plaatje. Het is namelijk de bestandsnaam die de lezer niks duidelijk maakt.

Het volgende stappenplan werkt in Chrome, Firefox, Safari en Edge:

  1. Rechtsklik op een plaatje.
  2. Op de laatste of een na laatste plek van je menu staat of “Inspect” of “Inspecteren” of “Inspect Element” of “Element inspecteren”.
  3. Klik hierop. Onder in beeld, of links, of rechts, of in een nieuw scherm, verschijnt de code die de pagina opbouwt. In dit scherm staan bovenaan veel tabjes. Helemaal links staat “Elements” of “Elementen”. Als het goed is, is deze al geselecteerd en hoef je hier niks aan te doen. Deze tab bestaat weer uit 2 of 3 kleine schermpjes.
  4. In het meest linker of bovenste kleine scherm is blauw omlijnd (In Edge grijs omlijnd) een zin die begint met ‘<img’. In deze omlijnde zin hoort een alt tag te staan.

Het beoordelen van plaatjes brengt wel de nodige complexiteit met zich mee. Ten eerste: de alt tag ooit is gecreëerd om het web toegankelijker te maken. Maar helaas zijn mensen niet langer de enige die deze teksten lezen. Zoekmachines gebruiken deze tekst ook om beter te begrijpen waar een website over gaat. En deze twee doelgroepen, mensen en machines, hebben andere leesbehoeftes.

Een mens snapt een pagina beter als alle decoratieve plaatjes geen alt tekst hebben. Stel je bijvoorbeeld voor dat je als slechtziende je bankdruk set in elkaar wil zetten. Als er dan op de pagina, midden in het stappenplan een foto staat dan leest je voorleessoftware opeens: “Een groep jonge mensen sporten met plezier” voor. Dit is natuurlijk verwarrend. De zoekmachines lezen echter wel alle alt tags, ook die van decoratieve plaatjes. Hoe beter zoekmachines je pagina’s begrijpen hoe beter zij relevante bezoekers naar je website sturen. Zet je als programmeur teksten in al je plaatjes dan werkt dit positief op je bezoekers aantal. Je wordt dus beloond om bij alle plaatjes een tekst neer te zetten.

Ten tweede: er zijn uitdagingen bij het inspecteren van de plaatjes zelf. Plaatjes kunnen worden toegevoegd als een decoratieve achtergrond en dan kan je ze niet terug vinden op de manier zoals hierboven omschreven. Een voorbeeld hiervan is de grote foto op onze landingspagina. Als gebruiker zie je dan wel een plaatje op het scherm maar lijkt het alsof die in de programmeercode niet bestaat. Ook kan je andere grafische elementen maken die voor de eindgebruiker op een plaatje lijken. Ga je naar de statescounter website en je inspecteert de grafiek, dan zal je geen `<img` zien. Wil je als leek controleren of deze elementen toegankelijk zijn, dan moet je naar hele andere woorden zoeken.

Tips: Wat je niet hoeft te testen

Nu we vijf tests hebben gedaan van wat je zelf goed kan testen heb ik ook twee tips over wat je beter kan overslaan. Dit zijn tests die door andere sites wel worden aangeraden.

Test niet: Contrast

Er wordt vaak geadviseerd om je contrast te testen. Ik denk dat dit geadviseerd wordt omdat er veel contrast testers op het internet zijn. Die zijn er veel omdat er een stukje wiskunde is om contrast te berekenen. Dit maakt een contrast tester relatief makkelijk om te bouwen en dus zijn er veel contrast testers.

Ik adviseer je om niet zelf met contrast testers aan de haal te gaan. De meest praktische reden hiervoor is dat de meeste automatische scanners die we gaan gebruiken hier ook op testen. Je hoeft het dus niet nog een keer los te controleren.

Ook is er een theoretisch bezwaar. De huidige formule voor de contrast berekening neemt niet alle relevante omgevingsfactoren mee. Dat betekent dat je soms de melding krijgt dat het contrast te laag ligt, terwijl het geen daadwerkelijk obstakel is voor kleurenblindheid. De contrast berekening is wel een goede ondersteuning om contrast problemen op te sporen. Echter zou ik het aan een specialist overlaten om te beoordelen of de contrast berekening in elke specifieke situatie een kloppend oordeel heeft geveld. Dit word beter en langer uitgelegd in dit artikel.

Mocht het toch belangrijk zijn om je website te testen voor kleurenblinden, dan raad ik simulators aan zoals Colorblindly in Chrome. Hiermee kan je de vier meest voorkomende soorten kleurenblindheid simuleren: groen-zwakte, rood-zwakte, groen-blindheid en rood-blindheid. Door de ervaring te simuleren kan je beter als leek beoordelen wat de impact is voor kleurenblinden dan met een automatische test. Ook zie je veel beter hoe verschillend de ervaring is binnen de groep van kleurenblinden. Ter illustratie heb ik een foto van onze website toegevoegd waar je het volgende ziet: linksboven zie je groen-zwakte, dan rechtsboven groen-blindheid, linksonder rood-zwakte en rood-blindheid zie je als laatste rechtsonder.

De meestvoorkomende typen kleurenblindheid in beeld

Vaak is de tekst bij links of knoppen niet goed bruikbaar voor blinden en slechtzienden, geeft Ieder(In) aan in hun stappenplan. Dit gaat mis wanneer voorleessoftware wordt gecombineerd met het navigeren met tabs (test 3). Dit komt vaak voor, omdat een muis moeilijker te besturen is met weinig of geen zicht. Wanneer je door de pagina tabt moet je alsnog in staat zijn om te begrijpen op wat voor knoppen je kan klikken.

In de basis moet daarom elke tekst op een link en knop zonder context te begrijpen zijn. Bijvoorbeeld is de knop “Naar volgende pagina” beter te begrijpen dan “>>”. Een link met de tekst “Digitoegankelijk website” begrijp je beter dan “Klik hier”. Omdat dit vaak mis gaat is het zinvol om dit te testen.

Voor een leek is het volgens mij echter te complex om dit goed te testen. Dit komt omdat er naast de zichtbare tekst op een knop of link voorgelezen kan worden er ook verborgen tekst voorgelezen kan worden, zoals de alt code bij test 3. Hiervoor zijn er echter twee mogelijke codes: het aria-label en de title. Of de zichtbare tekst, het aria-label of de title wordt voorgelezen ligt aan teveel factoren, zoals bijvoorbeeld de voorleessoftware, de versie van de voorleessoftware, de instellingen op je voorleessoftware, de browser die je gebruikt en of de title, het aria-label en de zichtbare tekst van elkaar verschillen. Dat baseer ik op het vergelijkingsonderzoek van Deque. Mocht je in diepte willen gaan uitzoeken met welke screen readers je het best kan gaan testen dan zou ik starten met te kijken naar de screenreader survey van WebAIM.

WCAG Scanners die gratis online beschikbaar zijn

Nu we de punten die wij als eindgebruiker kunnen controleren hebben gecontroleerd gaan we de hulp van computers inschakelen om mee te kijken naar de problemen. We gaan kijken naar een aantal gratis beschikbare tools op het web. Deze tools zijn te gebruiken door of de url van onze webpagina’s op te geven of door een browser extensie of add-on te installeren en je zelf pagina’s bezoekt. Extensies zijn hierbij iets makkelijker in gebruik als je meerdere pagina’s wil controleren.

De lijst is een eerste selectie van wat ik op het internet kon vinden en wat in de W3C toolbox hiervoor staat. Ik heb tools op de volgende punten geselecteerd:

  1. De tool streeft er naar de pagina’s “volledig” te controleren op toegankelijkheid. Het zijn bijvoorbeeld geen tools die alleen kijken naar contrast of titel structuur of naar een (te) select groepje WCAG criteria. Hou er rekening mee dat geen van de tools alle mogelijke barrières kan waarnemen. Er is nog geen software ontwikkeld die dat kan.
  2. De tool is gratis te gebruiken en geeft zonder invoer van je gegevens inzicht in de resultaten. Hierbij is siteImprove een uitzondering. SiteImprove wordt echter door BZK zelf aangeraden en daarom heb ik deze in de lijst opgenomen.
  3. De tool is nog up to date, ze scant dan op zowel WCAG 2.0 als haar uitbreiding WCAG 2.1.
  4. De tool is geen (legale) kopie van een andere tool. Sommige van de genoemde tools zijn open source pakketten. Andere aanbieders gebruiken dan deze open source tools voor hun scanners. Ze voegen zelf geen extra scans toe maar bieden bijvoorbeeld wel een overzichtelijke layout. Omdat deze tools geen scans toevoegen, maar wel kunnen achterlopen in updates heb ik ze uitgesloten.

Als je de scanners gebruikt zal je resultaten krijgen die je nog moet interpreteren. Om dit te doen kan je de resultaten even een paar minuten rustig doorklikken en lezen wat ze vermelden. Tijdens het doorklikken kan je op de volgende punten letten:

Dan volgt nu de lijst van scanners op alfabetische volgorde, met een gebruiksaanwijzing per scanner. Je hoeft natuurlijk niet alle scanners te gebruiken. Met één scanner weet je al een hoop. Op dit moment kan ik geen advies geven over welke scanner het beste werkt. Ik heb ze namelijk nog niet in detail getest.

Bij veel scanners hoef je alleen een url in te vullen. Overal waar staat “Url invullen” hoef je alleen nog de url of urls van de pagina’s in te vullen en door te klikken om de resultaten te zien.

Vragen of opmerkingen over dit artikel?

Dit is de meest complete lijst van scanners die ik op dit moment op het internet kan vinden. Mocht je willen reageren op dit artikel, vragen hebben over dit artikel of in het algemeen, neem dan gerust contact met me op via

Bel naar +31 40 3041457

mail naar diede@cell-0.com

Wil je mij contact laten op nemen? Ik doe het graag. Vul dan de twee velden in. Ik gebruik de gegevens uitsluitend om contact met je op te nemen.