Toegankelijkheid op het web

Sessie Jeroen Hulscher op DrupalJam 2016

'Het sprookje over de 7 blinde dwergen en de prinses met het lamme handje': hoe houden we het web toegankelijk met de diversiteit van platformen, browsers, devices en gebruikers?

Sprookje: de 7 blinde dwergen en de prinses met het lamme handje

Deze eigenaardige titel van de sessie over toegankelijkheid op het web, door Jeroen Hulscher, in het programma wekte direct de aandacht. Met in het achterhoofd dat GoalGorilla per 1 juli start aan het WIM-project van Dimpact, een landelijk samenwerkingsverband voor gemeenten, besloot ik, Peter Polman (Frontend Developer bij GoalGorilla), de sessie bij te wonen. Deze zou mij meer leren over de toegankelijkheid van websites. Een vereiste voor websites van (semi) overheidsinstellingen.

De in de titel benoemde prinses met het lamme handje, geldt als boegbeeld voor de minderheden binnen een doelgroep: de 7 blinde dwergen. Het inleidende verhaal geeft een goed beeld van de houding van velen ten opzichte van het onderwerp “toegankelijkheid op het web”. We weten dat het een punt van discussie is, maar de daadwerkelijke implementatie van toegankelijkheidsstandaarden blijft dikwijls uit. Hoe kan dit?

 

Presentatie Jeroen Hulscher DrupalJam 2016
Klik en bekijk de presentatie van Jeroen Hulscher

Budget belemmert toegankelijkheid

Budgetten zijn er op geënt om een zo groot mogelijk deel van een doelgroep op een zo goedkoop mogelijk manier te voorzien van diensten. Vaak zijn de investeringen in toegankelijkheid te hoog voor de potentiële winst en wordt hier niet tot nauwelijks wat aan gedaan.

Een vrij logisch verhaal, maar tergend op het moment dat we de cijfers er bij pakken. Ons land telt zo’n 17.000.000 inwoners. Hieronder bevinden zich 78.000 blinden, 238.000 slechtzienden, 700.000 kleurenblinden, 1.500.000 doven en slechthorenden, 68.000 zwaar verstandelijk beperkten, 70.000 licht verstandelijk beperkten, 825.000 dyslectici en 1.500.000 laaggeletterden.

Aangezien dit geen op zich staande doelgroepen zijn, kun je er vanuit gaan dat een bepaald percentage van je eindgebruikers zich in één of meerdere van deze groepen bevindt. Dit betekent uiteindelijk dat je bijvoorbeeld conversie mis kunt lopen op het moment dat je website niet toegankelijk is gemaakt voor deze personen. Of erger nog, mensen bepaalde content niet kunt verschaffen, omdat ze deze niet kunnen bereiken. Erg vervelend.

Om dit wat tastbaarder te maken, hebben we het dan bijvoorbeeld over kleurenblinden die moeite hebben met het leveringsstatus icoontje in webshops. Wat rood, oranje of groen is. Kleuren die voor iemand met deze visuele beperking maar lastig te onderscheiden zijn.

Of denk aan de 65-plussers die geforceerd worden om online hun belastingaangifte te doen, of een reis met het openbaar vervoer willen plannen. Dit is een doelgroep die zich steeds vaker online bevindt, maar tevens beperkingen in zicht, gehoor en oog-hand coördinatie met zich mee brengt. Houden we hier rekening mee?

 

Aantal Nederlanders met beperking

Bron: https://www.microsoft.com/netherlands/toegankelijk/over-toegankelijkheid/feiten-en-cijfers.aspx

Voldoen aan bepaalde standaarden

Websites van (semi) overheidsinstellingen moeten voldoen aan bepaalde standaarden. We spreken hier over de WCAG 2.0 richtlijnen. Deze richtlijnen omvatten succescriteria die met behulp van bepaalde technieken gewaarborgd kunnen worden. Op 12 april 2016 ging de Eerst Kamer akkoord met het VN verdrag over gelijke rechten voor mensen met een beperking uit 2006. De Tweede Kamer had haar instemming in januari van dit jaar al laten blijken. Gebouwen, winkels, openbaar vervoer en ook websites moeten toegankelijk gaan worden voor mensen met een handicap. Dit wordt nu bij wet geregeld. Bedrijven kunnen geleidelijk beginnen met eenvoudige aanpassingen en uiterlijk per 1 januari 2017 zal de regelgeving gehandhaafd worden.

Vooralsnog vinden we deze richtlijnen eigenlijk alleen terug in websites van (semi) overheidsinstellingen, universiteiten, hogescholen en bijvoorbeeld reisorganisaties. Hoofdzakelijk omdat zij bij wet verplicht zijn gesteld om hieraan te voldoen. In Nederland werkt dit anders dan in bijvoorbeeld Zweden, waar deze richtlijnen verplicht worden gesteld op basis van de hoeveelheid bezoekers die een website trekt. 

Denk vroeg in het ontwerpproces na over de toegankelijkheid

De uiteindelijke implementatie van deze technieken is over het algemeen geen rocket science. Je dient al vroeg in het ontwerpproces na te denken over de toegankelijkheid van de website. Gedurende de ontwikkeling moet je blijven testen op deze toegankelijkheid. Dit kan tegenwoordig goed in bestaande processen opgenomen worden, omdat theorie hierover publiekelijk beschikbaar is. Professionele partners als de stichting Accesibility zijn geen vereiste meer om hier stappen in te kunnen zetten. Waar deze stichting eerder de testen uitvoerde, neemt zij tegenwoordig eerder een inspecterende rol aan.

Als alle kennis voor het oprapen ligt, waar kan het dan nog mis gaan, zul je je afvragen. Dit heeft te maken met de procesinrichting van de ontwikkelende partij. Wanneer een 2D ontwerp omgezet gaat worden naar een dynamisch geheel binnen een specifieke context, ontstaan er nieuwe situaties die een ontwerper op het eerste gezicht misschien over het hoofd heeft gezien. 

Voorbeelden van ongeschikte toepassingen

Navigatie wordt steeds vaker in witte of half-transparante tekst over een vanzelf afspelende achtergrond video geplaatst. Zoals we hier kunnen zien op de website van Batavus fietsen. Hoogstwaarschijnlijk ontworpen op een donker frame uit de video.

 

Stoplicht voor een kleurenblinde
Zo zien kleurenblinden een stoplicht

 

We noemden eerder al de leverstatus iconen als probleem voor kleurenblinden. Maar ook met een combinatie van bepaalde kleuren kunnen problemen in de leesbaarheid optreden. Een goede tool om op contrast ratio te testen is gemaakt door frontend developer Lea Verou. Tekstkleur ten opzichte van achtergrondkleur krijgt hiermee een cijfer wat als handvat voor de te maken keuzes gebruikt kan worden.

 

>> Ken jij nog andere testing tools? Deel ze dan hieronder in een reactie. <<

 

Toegankelijkheid voor dyslectici

 

We zien een designtrend waarin vaak kapitalen worden gebruikt om titels vorm te geven. Dit is echter voor dyslectici een stuk moeilijker om te lezen, aangezien de vorm van de letters verdwijnt in het feit dat alles als een blok wordt weergegeven.

<a href=”http://www.goalgorilla.com”>Lees meer <span class=”hidden”>over internet bureau GoalGorilla</span></a>

Slechtzienden gebruiken screenreaders om te navigeren door een website. Als een link geen duidelijke waarde of title tag bevat (maar bijvoorbeeld slechts “Lees meer”), dan wordt navigeren voor hen vaak onmogelijk gemaakt, omdat ze de context van de link niet kennen. Door een gedeelte van een beschrijvende tekst te verbergen of een title tag aan de anchor toe te voegen, heeft dit geen design implicaties en is de eindgebruiker met een visuele beperking toch geholpen.

Daarnaast kennen we bijvoorbeeld date picker plugins die je forceren om met de muis een keuze te maken. Voor mensen met beperkte hand-oog coördinatie is dit een probleem. Zij gebruiken het toetsenbord (tab en shift+tab) om door een site te navigeren en kunnen deze features daardoor niet gebruiken. We zien dit probleem ook terug bij dropdowns. Soms wordt zelfs de visuele feedback bij het selecteren van elementen verwijderd, zodat de gebruiker niet kan zien wat er met het toetsenbord geselecteerd is. 

Voorbeeld: een reis plannen bij NS

Aan het eind van de sessie werd geprobeerd een reis te plannen op de NS website, met behulp van enkel het toetsenbord en een screenreader. Dit bleek nagenoeg een onmogelijk proces. De conclusie is dat mensen met een beperking in dit soort situaties afhankelijk worden van derden. Dit beperkt hen in hun eigen bewegingsvrijheid en dat zou ik persoonlijk als zeer vervelend ervaren.

 

Test bij de NS


Onze oplossing: continu testen met SiteImprove

Toegankelijkheid is geen rocket science, maar wel structurele aandacht voor standaarden die front-end developers en ontwerpers in hun achterhoofd moeten houden bij het ontwerpen en ontwikkelen van webpagina’s. Dit valt en staat over met het waarborgen van een goede semantiek in de pagina. Vervolgens moeten specifieke gebruikerstesten de implementatie van deze technieken gewaarborgd worden en hierbij kunnen de Web Content Accessibility Guidelines gebruikt worden om dit te testen. De tool HTML Codesniffer is bij uitstek geschikt om één individuele pagina hierop te testen.

[Update juli 2016] Inmiddels hebben we de WCAG standaarden opgenomen binnen ons development proces. We hebben onze continuous integration (CI) omgeving gekoppeld aan de tools van SiteImprove. Die omgeving wordt iedere nacht geüpdatet met ons laatste werk en de SiteImprove API genereert vervolgens automatisch een accessibility report.

Voorbeeld: https://reports.siteimprove.com/runreports/scheduled/6010328/2016/7/d980db0af4b34d35b8c366daa63c03d7.html

Elke ochtend kunnen de ontdekte issues omgezet worden naar taken binnen het projectmanagement systeem. Op deze manier ontdekken we problemen in een vroeg stadium, wat de investering omtrent dit onderwerp laag houdt en uiteindelijk een verbeterde gebruikservaring oplevert.

>> Ken jij nog andere testing tools? Deel ze dan hieronder in een reactie.


Een toegankelijk webplatform voor de eindgebruikers van Dimpact

Al met al heeft deze sessie het huidige proces weer even op scherp gesteld. In het project voor Dimpact wordt vereist te conformeren aan de WCAG 2.0 AA richtlijnen. De WCAG richtlijnen zijn sinds kort wettelijk verplicht gesteld als onderdeel van de WGDI (Wet Generieke Digitale Informatiestructuur). Deze zogeheten aanbouwwet verplicht overheidsinstanties om voor 1 januari 2017 op gefaseerde wijze diensten en content online en op een toegankelijke manier aan te bieden.  

Stichting Accessibility of een andere professionele toegankelijkheidspartner zal de website inspecteren en hierna zal de website het waarmerk drempelvrij.nl mogen dragen. We zullen de tools van SiteImprove inzetten voor controle en rapportage en samenwerking zoeken met het Ministerie van Binnenlandse Zaken en digitaleoverheid.nl.

De impact van het doorvoeren van deze standaarden is aan de hand van treffende voorbeelden helder geworden. En met dit in het achterhoofd kunnen we voor Dimpact en haar eindgebruikers een toegankelijk webplatform neer gaan zetten.


Credits headerafbeelding: Imre Gmelig Meijling

Front-end Developer
Peter Polman

Bekijk ook onze andere nieuwsartikelen

Klik voor onze award winnende klanten