Deze 8 WCAG-fouten zien webbouwers vaak over het hoofd

Je website kan er goed uitzien en zonder opvallende meldingen door een automatische toegankelijkheidstest komen. Toch betekent dat niet dat de website ook echt aan de WCAG voldoet. Veel problemen zijn namelijk niet met een tool te herkennen.

Automatische tests kunnen bijvoorbeeld ontbrekende toegankelijke namen, ongeldige ARIA-attributen en sommige contrastproblemen vinden. Maar een tool begrijpt niet altijd wat er op een pagina gebeurt. De test weet niet vanzelf of de leesvolgorde logisch is, of een foutmelding duidelijk genoeg is of dat een menu volledig met het toetsenbord werkt.

Daarvoor moet je de website handmatig testen en weten waar je op moet letten. Dat vraagt kennis van de WCAG en van de manier waarop mensen een website gebruiken met een toetsenbord, schermlezer of andere hulpsoftware.

Webbouwers en bureaus kunnen toegankelijkheid serieus nemen en toch fouten missen. Zeker wanneer ze vooral vertrouwen op automatische scans of alleen controleren of de website er visueel goed uitziet.

In dit artikel bespreken we acht WCAG-fouten die webbouwers bij hun eigen controles makkelijk over het hoofd zien.

Waarom een automatische WCAG-test niet voldoende is

Automatische toegankelijkheidstests zijn handig om snel technische fouten te vinden. Ze kunnen bijvoorbeeld signaleren dat een knop geen toegankelijke naam heeft, een afbeelding geen alt-attribuut bevat of tekst te weinig contrast heeft. Daarmee geven ze een eerste indruk van de toegankelijkheid van een website.

Zo’n test ziet vooral wat technisch herkenbaar is. Een tool kan meestal niet beoordelen of een alt-tekst de juiste informatie geeft, of een formulier duidelijke instructies bevat en of de volgorde van onderdelen logisch is. Ook kan een test niet zelfstandig vaststellen of een menu, pop-up of datumkiezer volledig met het toetsenbord werkt.

Dat wordt duidelijk bij een formulier waarin fouten alleen met kleur worden aangegeven. In de foute versie krijgt een ongeldig veld een rode rand en een correct veld een groene rand. Voor iemand die dat kleurverschil niet goed ziet, is niet duidelijk welk veld fout is en wat er moet worden aangepast.

In een betere versie krijgt het foutieve veld naast een rode rand ook een fouticoon en de melding: ‘E-mailadres: vul een geldig e-mailadres in.’ Een automatische test kan kleurwaarden en contrast controleren, maar niet altijd betrouwbaar bepalen of kleur de enige aanwijzing is.

Daarom moet iemand de website ook echt gebruiken. Dat betekent onder andere navigeren zonder muis, formulieren bewust verkeerd invullen en controleren wat hulpsoftware meekrijgt wanneer inhoud verandert. Daarbij is kennis van de WCAG nodig om te bepalen wanneer iets daadwerkelijk een probleem is.

Een automatische scan is dus een nuttig startpunt, maar geen volledig WCAG-onderzoek. Alleen met automatische én handmatige controles wordt duidelijk welke drempels bezoekers in de praktijk tegenkomen.

WCAG 1.3.1 Info en relaties

Koppen, lijsten en relaties zijn alleen visueel duidelijk

Volgens dit succescriterium moeten informatie, structuur en onderlinge relaties niet alleen visueel duidelijk zijn. Ze moeten ook in de code of in tekst beschikbaar zijn, zodat hulpsoftware ze kan herkennen.

Een tussenkop kan er bijvoorbeeld groot en vet uitzien, terwijl deze in de code als gewone alinea is ingesteld. Een schermlezer herkent de tekst dan niet als kop. De gebruiker kan de kop daardoor ook niet gebruiken om snel door de pagina te navigeren.

Hetzelfde geldt voor een opsomming met vinkjes. Visueel lijkt dit een lijst, maar in de code kan deze uit losse tekstregels bestaan. Hulpsoftware kan dan niet aangeven waar de lijst begint, hoeveel onderdelen deze bevat en waar de lijst eindigt.

Ook bij formulieren kunnen relaties ontbreken. De opties telefoon, e-mail en WhatsApp kunnen zichtbaar onder de vraag ‘Hoe wil je worden benaderd?’ staan, zonder dat deze technisch als één groep zijn vastgelegd.

Bij tabellen is alleen een vetgedrukte bovenste rij niet genoeg. De kopcellen moeten in de code aan de juiste gegevens worden gekoppeld. Anders is bij het voorlezen niet duidelijk bij welke kolom een waarde hoort.

WCAG 1.4.1 Gebruik van kleur

Kleur is de enige aanwijzing

Volgens dit succescriterium mag kleur niet het enige middel zijn om informatie, een actie of een verschil duidelijk te maken. De informatie moet ook op een andere zichtbare manier beschikbaar zijn.

Een bekend voorbeeld is een formulier waarin fout ingevulde velden alleen een rode rand krijgen. Wie dat kleurverschil niet goed ziet, weet niet welk veld moet worden aangepast. Een duidelijke foutmelding in tekst maakt dat wel begrijpelijk.

Ook links in een lopende tekst kunnen een probleem vormen. Wanneer een link alleen een andere kleur heeft dan de omliggende tekst, is deze niet voor iedereen herkenbaar. Een onderstreping of een andere zichtbare aanwijzing maakt het verschil duidelijker.

Hetzelfde geldt voor agenda’s, dashboards en keuzemenu’s. Groen kan bijvoorbeeld ‘beschikbaar’ betekenen en rood ‘bezet’. Of een gekozen optie krijgt alleen een andere achtergrondkleur. Voeg dan ook tekst, een pictogram of een ander zichtbaar kenmerk toe.

Instructies als ‘Klik op de groene knop rechts’ zijn eveneens kwetsbaar. Verwijs liever naar de naam van de knop, bijvoorbeeld: ‘Klik op Aanvraag versturen’. Kleur en plaats mogen wel als extra aanwijzing worden gebruikt.

WCAG 2.1.1 Toetsenbord

Onderdelen werken niet volledig met het toetsenbord

Volgens dit succescriterium moet alle functionaliteit van een website met het toetsenbord te bedienen zijn. Alleen door een pagina kunnen tabben is dus niet genoeg. Een gebruiker moet ieder onderdeel ook kunnen openen, bedienen en weer sluiten.

Een submenu kan bijvoorbeeld zichtbaar worden zodra iemand er met de muis overheen beweegt. Als datzelfde menu niet met Enter, de spatiebalk of een andere passende toets kan worden geopend, blijven de onderliggende pagina’s buiten bereik.

Ook cookiebanners leveren vaak problemen op. De knop ‘Alles accepteren’ is dan wel bereikbaar, terwijl opties als ‘Weigeren’ of ‘Voorkeuren instellen’ alleen met de muis werken. Een toetsenbordgebruiker krijgt daardoor niet dezelfde keuzes.

Een ander voorbeeld is een datumkiezer. Het invoerveld kan focus krijgen, maar de kalender zelf werkt alleen met muisklikken. De gebruiker kan dan geen datum kiezen, ook al lijkt het onderdeel technisch bereikbaar.

Test daarom niet alleen of de focus op een onderdeel komt. Controleer ook of iedere functie volledig met het toetsenbord kan worden uitgevoerd.

WCAG 2.4.3 Focusvolgorde

De toetsenbordfocus volgt geen logische route

Volgens dit succescriterium moeten interactieve onderdelen in een logische volgorde toetsenbordfocus krijgen. Die volgorde hoeft niet altijd exact gelijk te zijn aan de visuele opbouw, maar de pagina moet wel begrijpelijk en goed te bedienen blijven.

Een veelvoorkomend probleem ontstaat bij pop-ups. Na het openen blijft de focus soms op de onderliggende pagina staan. De gebruiker tabt dan verder langs links en knoppen die achter de pop-up verborgen zijn, terwijl het geopende venster nog niet bereikbaar is.

Ook gesloten menu’s kunnen problemen veroorzaken. De links zijn visueel verborgen, maar ontvangen nog wel focus. Daardoor lijkt de focus plotseling van het scherm te verdwijnen.

Na het sluiten van een venster hoort de focus bovendien terug te keren naar een logisch punt, meestal de knop waarmee het venster is geopend. Wanneer de focus naar het begin van de pagina springt, moet de gebruiker opnieuw langs alle eerdere onderdelen navigeren.

Alle onderdelen kunnen technisch bereikbaar zijn, terwijl de volgorde toch verwarrend is. Daarom moet de focusroute handmatig met het toetsenbord worden gecontroleerd.

Denk aan een knop ‘Afspraak maken’ die een pop-up opent. Visueel verschijnt het venster netjes in beeld. Toch kan de toetsenbordfocus op de onderliggende pagina blijven staan. De gebruiker tabt dan verder langs links en knoppen achter het venster, terwijl de pop-up nog niet bereikbaar is. In een goede focusvolgorde gaat de focus direct naar een logisch punt in het venster, bijvoorbeeld de sluitknop of het eerste invulveld.

WCAG 2.4.4 Doel van de link (in context)

Links lijken duidelijk, maar missen de juiste context

Volgens dit succescriterium moet duidelijk zijn waar een link naartoe leidt. Dat mag blijken uit de linktekst zelf of uit informatie die technisch aan de link is gekoppeld.

Een linktekst als ‘Lees meer’ is daarom niet automatisch fout. Het probleem ontstaat wanneer niet duidelijk is waarover iemand meer gaat lezen.

Denk aan een overzicht met drie kaarten voor een WCAG-onderzoek, een quickscan en toegankelijke PDF’s. Iedere kaart bevat een titel, een korte tekst en dezelfde link ‘Lees meer’. Voor een ziende bezoeker lijkt door de plaatsing duidelijk welke link bij welk onderwerp hoort. Hulpsoftware kan die relatie echter alleen gebruiken wanneer deze ook goed in de code is vastgelegd.

Visuele nabijheid is dus niet altijd voldoende. Als de titel, beschrijving en link technisch geen duidelijke relatie hebben, hoort een schermlezergebruiker mogelijk alleen drie keer ‘Lees meer’.

Een duidelijke oplossing is om het onderwerp in de linktekst op te nemen, bijvoorbeeld ‘Lees meer over het WCAG-onderzoek’. Daarmee is het linkdoel ook zonder aanvullende context meteen begrijpelijk.

WCAG 3.3.1 Foutidentificatie en 3.3.2 Labels of instructies

Formulieren geven te weinig uitleg

Volgens deze succescriteria moet vóór het invullen duidelijk zijn welke informatie nodig is. Als er daarna een fout ontstaat, moet in tekst worden uitgelegd welk veld fout is en wat er misging.

Een formulier heeft daarom duidelijke, zichtbare labels nodig. Alleen een placeholder in het invoerveld is meestal niet genoeg. Die tekst verdwijnt zodra de gebruiker begint te typen. Bij een lang formulier is dan niet meer goed te controleren welke informatie bij welk veld hoort.

Ook moet vooraf duidelijk zijn welke velden verplicht zijn en in welk formaat gegevens moeten worden ingevoerd. Bij een datumveld kan bijvoorbeeld staan: ‘Gebruik het formaat DD-MM-JJJJ’. Wachtwoordeisen horen eveneens zichtbaar te zijn voordat iemand het formulier probeert te verzenden.

Na het invullen moet een fout duidelijk worden beschreven. Alleen een rode rand om een veld helpt niet iedereen. Ook een algemene melding als ‘Er is iets misgegaan’ vertelt niet waar het probleem zit.

Een betere melding noemt het veld en de fout, bijvoorbeeld: ‘E-mailadres: vul een geldig e-mailadres in.’ De gebruiker weet dan direct wat moet worden aangepast.

Een goed formulier helpt bezoekers dus op twee momenten: het voorkomt fouten met duidelijke labels en instructies, en het helpt gebruikers om ontstane fouten te begrijpen en te herstellen.

WCAG 4.1.2 Naam, rol, waarde

Interactieve onderdelen vertellen niet wat ze zijn of doen

Volgens dit succescriterium moet hulpsoftware kunnen bepalen hoe een interactief onderdeel heet, wat voor onderdeel het is en wat de huidige status is.

Denk aan een accordeon met veelgestelde vragen. Voor een ziende bezoeker is duidelijk dat de vraag kan worden geopend. Na een klik draait het pijltje en verschijnt het antwoord. Een schermlezer moet diezelfde informatie ook krijgen.

De naam vertelt om welk onderdeel het gaat, bijvoorbeeld ‘Wat kost een WCAG-onderzoek?’. De rol maakt duidelijk dat het om een knop gaat en niet om gewone tekst. De status geeft aan of het antwoord open of gesloten is.

Bij zelfgebouwde onderdelen gaat dit regelmatig mis. Een klikbaar tekstblok kan er precies uitzien als een knop en met de muis goed werken, terwijl hulpsoftware alleen gewone tekst herkent. Ook kan een onderdeel visueel openen zonder dat de status in de code verandert. Een schermlezer blijft dan melden dat het onderdeel gesloten is.

Gebruik waar mogelijk standaard HTML-elementen. Die bevatten de juiste rol en bediening vaak al. Bij maatwerk moeten naam, rol en status zorgvuldig worden toegevoegd en bijgewerkt.

Let ook op de toegankelijke naam. Een knop kan op het scherm ‘Zoeken’ tonen, terwijl hulpsoftware de naam ‘Verstuur opdracht’ krijgt. Voor gebruikers van spraakbediening is de knop dan moeilijker te activeren.

<button aria-label=”Verstuur opdracht”>Zoeken</button>

WCAG 4.1.3 Statusberichten

Nieuwe meldingen worden niet aangekondigd

Volgens dit succescriterium moeten belangrijke meldingen die tijdens het gebruik van een pagina verschijnen ook door hulpsoftware kunnen worden herkend. De toetsenbordfocus hoeft daarvoor niet naar de melding te worden verplaatst.

Denk aan een zoekfunctie waarbij na het invoeren van een zoekterm de tekst ‘7 resultaten gevonden’ verschijnt. Een ziende bezoeker ziet direct dat de zoekactie is uitgevoerd. Een schermlezergebruiker krijgt dat niet automatisch mee wanneer de melding alleen visueel aan de pagina wordt toegevoegd.

Hetzelfde kan gebeuren nadat een formulier is verzonden. De tekst ‘Je formulier is verzonden’ verschijnt onder de knop, maar de gebruiker hoort niets en weet niet of de actie is gelukt. Bij een webshop kan alleen het aantal producten in het winkelmandje veranderen, zonder dat wordt aangekondigd dat een product is toegevoegd.

De oplossing is niet om de focus steeds naar iedere nieuwe melding te verplaatsen. Dat zou de gebruiker juist uit de huidige taak halen. De melding moet in de code als statusbericht herkenbaar zijn, zodat hulpsoftware deze op het juiste moment kan aankondigen.

Een zichtbare verandering is dus niet automatisch ook een waarneembare verandering voor iedere gebruiker.

Wat betekent dit voor je website?

Veel toegankelijkheidsproblemen vallen niet op wanneer je een website alleen bekijkt en met de muis gebruikt. Een kop ziet eruit als een kop, een menu opent en een formulier toont een melding. Toch kan de technische structuur ontbreken, kan de bediening zonder muis vastlopen of krijgt hulpsoftware belangrijke informatie niet mee.

Automatische tools kunnen een deel van deze problemen signaleren. Andere fouten vragen om context, handmatige bediening en kennis van de afzonderlijke succescriteria. Een webbouwer kan toegankelijkheid serieus nemen en toch belangrijke problemen missen.

Een automatische scan is daarom een startpunt, geen onderbouwde eindbeoordeling.

Wil je eerst weten waar de belangrijkste digitale drempels op je website zitten? Dan kan een quickscan passend zijn. Wil je volledig en onderbouwd weten in hoeverre je website voldoet aan WCAG 2.2 niveau A en AA? Dan is een volledig WCAG-onderzoek nodig.

Meer achtergrondinformatie vind je op de pagina over digitale toegankelijkheid.

Bronnen

De uitleg in dit artikel is gebaseerd op de officiële Understanding-documenten van W3C:

• WCAG 1.3.1 Info and Relationships en WCAG 1.3.3 Sensory Characteristics
• WCAG 1.4.1 Use of Color
• WCAG 2.1.1 Keyboard
• WCAG 2.4.3 Focus Order
• WCAG 2.4.4 Link Purpose (In Context)
• WCAG 3.3.1 Error Identification, WCAG 3.3.2 Labels or Instructions en WCAG 3.3.3 Error Suggestion
• WCAG 4.1.2 Name, Role, Value en WCAG 2.5.3 Label in Name
• WCAG 4.1.3 Status Messages