Home / Blog

Toegankelijkheid in het dagelijks programmeren

De toegankelijkheid van websites wordt steeds belangrijker, en terecht, want je wilt niemand uitsluiten en graag iedereen voorzien van jouw content. Daarom geef ik je graag een aantal tips om mee te nemen in je dagelijks programmeren.

Geschreven door Merel

Eerder schreef Thomas al een blog over de toegankelijkheidsrichtlijnen (WCAG) die per 23 september in zijn gegaan voor websites van overheidsinstanties. Deze richtlijnen zijn erg uitgebreid het kost veel tijd en uitzoekwerk om deze goed te volgen.

Een website toegankelijk maken

In het dagelijks programmeren zijn er echter een aantal dingen waar je op kan letten die je website al veel toegankelijker maken. Je site toegankelijk maken voor echt iedereen lijkt bijna onmogelijk, want elke beperking is anders en sommige beperkingen vragen juist om tegenovergestelde maatregelen. Mensen met de oogaandoening maculadegeneratie hebben bijvoorbeeld behoefte aan hoog contrast (hoge helderheid), waar mensen met fotofobie juist slecht tegen licht kunnen juist minder contrast willen.

Natuurlijk is overal een oplossing voor te vinden. Als developer roep ik vaak genoeg: “alles kan, als er maar genoeg tijd voor is.” Over het algemeen geldt echter vaak: tijd is geld, en moet er zo veel mogelijk gebeuren in zo min mogelijk tijd. Het is daarom handig om te kijken naar relatief eenvoudige oplossingen die zoveel mogelijk gebruikers van een fijne ervaring voorzien. Een tool die daar prima bij helpt is Google Lighthouse.

Tip: gebruik Google Lighthouse

Elke webdeveloper zal er wel eens van gehoord hebben en de meesten zullen het waarschijnlijk ook wel regelmatig gebruiken. Google Lighthouse is een prima tool die een website analyseert en feedback geeft over wat beter kan. De tool houdt niet met alles rekening en je kan niet altijd alles doorvoeren wat aangegeven wordt, maar het dient als een prima leidraad.

Toegankelijkheid in navigatie

Een goed begin is het halve werk en een goed begin start met een goede navigatie. Stel iemand bezoekt je pagina met een screenreader om te lezen wat er op staat, maar bovenaan de pagina staat eerst een uitgebreid hoofdmenu met veel linkjes waar de screenreader zich doorheen moeten lezen, voordat de daadwerkelijke content aan de beurt is. Niet ideaal. Gelukkig zijn en er een paar simpele implementaties die het leven al zoveel simpeler maken. Als eerste heb je de zogenoemde landmarks. Dit zijn HTML5-elementen zoals main, nav en aside die duidelijk aangeven welke content zich waar bevindt. Probeer tabindexen en accesskeys zoveel mogelijk te vermijden en gebruik zoveel mogelijk van deze standaard HTML-elementen in de juiste volgorde.

Een handige truc om toe te passen is de skip link. Deze link plaats je als eerste in je HTML en die zorgt ervoor dat een bezoeker het hele – vaak lange en ingewikkelde – hoofdmenu kan overslaan en direct bij de content uitkomt. De link kan je met css verbergen voor de andere bezoekers, bijvoorbeeld:

<a class="c-button__skip" href="#main">Ga door naar hoofdcontent</a>
<main id="main"> Hoofdcontent </main>

.c-button__skip{ 
   position: absolute;
   top: -40px;
   left: 0;
   background: black;
   color: white;
   padding: 0.5rem 1rem;
   z-index: 100;
}
.c-button__skip:focus{ 
  top: 0; 
}

Gebruik van headings, maar dan goed

Iets wat vrij standaard wordt toegepast, maar niet altijd even goed, is het gebruik van headings. Er gaat nog steeds het gerucht rond dat er maar een h1 op een pagina mag staan. Anders ‘begrijpt Google de pagina niet’. Dat is echter niet het geval, je mag rustig meerdere h1-headings op de pagina zetten, zolang deze maar logisch zijn. Het belangrijkste hierin is de volgorde en daar gaat het nog wel eens fout, want de standaard styling is bijvoorbeeld dat de h1 groter is dan de h2 en de h2 groter is dan de h3. Daardoor zijn developers soms geneigd om als er in het design twee kopjes onder elkaar staan, waarvan de eerste kleiner is dan de tweede, om de eerste dan een h3 te geven en de tweede een h2. Styling is echter minder belangrijk dan de volgorde. Als er twee kopjes na elkaar komen waarbij de bovenste volgens het design kleiner is dan de daaropvolgende, dan zul je dit op moeten lossen met CSS en niet met HTML. Ook belangrijk om te onthouden, de kopjes volgen elkaar altijd op. Na een h2 komt altijd een h3 en niet een h4. Het is dus altijd:

<h1> Heading 1 </h1>
 
 
<h2> Heading 2 </h2>
 
 
<h3> Heading 3 </h3>
 
 
<h4> Heading 4 </h4>

En niet:

<h1> Heading 1 </h1>
 
  
 
<h3> Heading 3, want er moet een kleinere tekst voor de volgende heading komen</h3>
 
  
 
<h2> Heading 2, want deze tekst is volgens het design groter dan de tekst hierboven </h2>
 
  
 
<h5> Heading 5 die heading 4 overslaat</h5>

ARIA

ARIA staat voor “Accessible Rich Internet Applications” en definieert een aantal attributen die de semantiek van een website verbeteren door informatie toe te voegen die door bijvoorbeeld screenreaders te lezen is. Een ARIA-attribuut verandert niets aan de werking van het element waar deze op toegepast wordt, maar geeft puur extra informatie aan de screenreader. De meeste gebruikers merken hier doorgaans dus niets van.

Zoals eerder al genoemd is het altijd handig om zoveel mogelijk gebruik te maken van de standaard HTML-elementen en zo ook in verband met ARIA, want alle ARIA-functies zitten hier al ingebouwd. Voor onder andere stylingopties is het echter soms nodig om toch een ander attribuut te gebruiken dan dat hier eigenlijk voor gedefinieerd is. Wat dacht je van een list element in je formulier gebruiken als checkbox?

<li class="c-form__checkbox" role="checkbox" checked aria-checked="true">
  Accepteer onze voorwaarden
</li>

Pop-up is lastig voor screenreaders

Iets dat ook vaak voorkomt en lastig is voor screenreaders is een pop-up. In dit stukje code (HTML+Twig) dat ik onlangs schreef stonden er meerdere auteurs naast elkaar genoemd, waarbij de extra informatie dus in een pop-up getoond werd. Omdat een ARIA-id, zoals alle id’s, maar één keer gebruikt mag worden, gaf ik de naam van de auteur hierin mee.

<div role="dialog" aria-labelledby="dialogTitle-{{ author.title }}" aria-describedby="dialogDesc-{{ author.title }}" class="b-authors__popup js-author-popup">
    {{ picture(author.thumbnail|resize(192,192, 'center'), 'Afbeelding voor ' ~ author.title, 'b-authors__single-image small') }}
     
<div class="b-authors__single-content small">
         
<h5 id="dialogTitle-{{ author.title }}">{{ author.title }}</h5>
 
        <small id="dialogDesc-{{ author.title }}">{{ author.summary }}</small>
        <a href="{{ author.url }}" title="Biografie {{ author.title }}" class="c-button c-button--ghost small mt-2">Volledige biografie</a>
    </div>
 
</div>

Het is dus altijd goed om na te denken over welke elementen je gebruikt en of deze ook daadwerkelijk weergeven wat een gebruiker verwacht. Is dit niet het geval? Controleer dan of je het element een role mee kan geven om dit duidelijk te maken en welke extra attributen nog toegevoegd kunnen/moeten worden. Ook handig om te onthouden is dat je altijd nog een extra label kan toevoegen op een standaard element om meer duidelijkheid te scheppen.

Namen en labels

Doorgaand op het onderwerp labels, het toevoegen van namen en labels zou bij sommige elementen eigenlijk automatisme moeten zijn voor elke developer. Een afbeelding moet bijvoorbeeld altijd een alt=”” meekrijgen. Probeer altijd zo duidelijk mogelijk te omschrijven wat er op een afbeelding staat. Dit geldt ook voor bijvoorbeeld linkjes. De informatie die zich tussen de a tag bevindt wordt in principe gebruikt om duidelijk te maken waar deze link naar toe gaat. Helaas wijst de praktijk uit dat hier vaak niets meer staat dan ‘lees meer’ of ‘verder’. In dit soort gevallen is het altijd raadzaam om een title mee te geven die duidelijkheid verschaft over waar deze link naar toe gaat.

<a href="/testen" title="Link naar pagina over testen">Lees meer</a>

Ook handig om te onthouden is dat een icoon als link/button allesbehalve duidelijk is voor een screenreader. Hier komt de eerder genoemde aria-label goed voor van pas.

<button class="c-button" aria-label="Link naar facebookpagina"> <i class="fab fa-facebook" aria-hidden="true"></i> </button>

Contrast is bijzonder belangrijk

Ik prijs mezelf altijd gelukkig met dat er een ding is dat gelukkig erg goed is en waar ik me nooit druk om hoef te maken, en dat is mijn zicht. In mijn familie heeft vrijwel iedereen hele goede ogen en zijn er alleen wat 50+ers met een leesbril te vinden. Toch kom ook ik af en toe sites, reclames, of folders tegen waar de kleuren zo slecht op elkaar zijn afgestemd dat de tekst amper nog te lezen is. Als ik hier al last van heb, hoe zit het dan met de visueel beperkte medemens? Een goed contrast is dus bijzonder belangrijk en hangt natuurlijk samen met het lettertype en de grootte van de letters. In de richtlijnen van WCAG worden dan ook verschillende contrastratio’s gehanteerd voor verschillende lettergroottes. Bij Linku hebben we gelukkig een aantal hele goed designers die hier altijd rekening mee houden. Een extra check kan echter nooit kwaad, want je weet maar nooit.

Niet alles kan getest worden met een tool

Bovenstaande punten worden gelukkig allemaal gecheckt door Google Lighthouse en als je iets goed hebt toegepast krijg je dat direct te zien. Achteraf alles weer moeten aanpassen, daar zit je natuurlijk ook niet op te wachten. Probeer de richtlijnen dus zoveel mogelijk in je systeem te krijgen en toe te passen tijdens het ontwikkelen. Het helpt om ook tussendoor Lighthouse eens te draaien.

Belangrijk is wel om te onthouden dat niet alles getest kan worden door deze tool en het daarom ook handig is om zelf zo goed mogelijk na te kijken of alles wel toegankelijk is. Tab bijvoorbeeld zelf eens een keer door je website heen. Het allerbeste is natuurlijk om je site te laten testen door mensen binnen de doelgroep die daadwerkelijk slechtziend zijn of een andere beperking hebben.

Moet jouw site voldoen aan de WGAG richtlijnen? Dan is naast Google Lighthouse de axe™ tool erg handig om te gebruiken. Deze geeft duidelijk aan welke richtlijnen er overtreden worden, met een handige link naar meer informatie over die richtlijn.

Sparren?