Toegankelijkheid in webapplicaties: WCAG en HTML

Toegankelijkheid in een webapplicatie hangt af van meer dan kleurcontrast of een toegankelijkheidsplugin. Je leest hoe semantische HTML, toetsenbordbediening en WCAG-richtlijnen samen bepalen of mensen een interface kunnen waarnemen, bedienen en begrijpen, en hoe handmatige tests problemen zichtbaar maken.

Semantische HTML geeft interfaces betekenis

HTML zegt niet alleen iets over de vorm, maar vooral over wat een stuk van een webpagina is. Een <button> is bedoeld voor het starten van een actie en een <a> navigeert je ergens anders heen. Gebruik je zomaar een <div> met een klikfunctie voor zulke dingen, dan mis je standaard dingen zoals toetsenbordnavigatie, focus en een naam die hulptechnologie begrijpt. Al die extra logica zelf toevoegen is foutgevoeliger dan direct het goede element kiezen.

Koppen moeten logisch opgebouwd zijn. Dus een <h1> bovenaan, en kopniveaus daaronder als de inhoud het vraagt, niet alleen omdat een bepaald lettertype mooi is. Sla je een niveau over, dan kunnen mensen verdwalen, zeker met een schermlezer. Net zo voor lijsten, tabellen of formulieren, neem altijd het element dat het verband tussen de onderdelen duidelijk maakt.

Alleen semantiek maakt een interface natuurlijk nog niet bruikbaar. Een <button> met de naam "klik hier" levert weinig op, en een visueel mooie tabel zonder duidelijke structuur kan alsnog lastig zijn. Maar correcte elementen geven apparaten en hulpsoftware een basis die te vertrouwen is. CSS kan een pagina anders laten ogen zonder de betekenis te verliezen; omgekeerd voegt een layout geen semantiek toe.

Toetsenbordbediening voor alle interactieve onderdelen

Je webapplicatie moet zonder muis bruikbaar zijn. Je moet alle interactieve onderdelen kunnen bedienen met het toetsenbord: niet alleen knoppen of links, maar ook menu’s, tabbladen, pop-ups, agenda’s of zelfgebouwde interface-elementen. Test het zelf: Tab, Shift+Tab, Enter, spatie. Als je ergens niet bij komt, of een functie werkt alleen met een muisklik? Dan is daar werk te doen. Let er ook op dat links geactiveerd worden met Enter, knoppen meestal ook met spatie, dat verschil is belangrijk voor sommige toetsenbordgebruikers.

De volgorde van de focus moet logisch zijn, zodat gebruikers niet van hot naar her springen. Gebruik waar mogelijk de standaardvolgorde in de HTML. Een positieve tabindex geeft snel problemen als de pagina verandert. Gebruik hooguit tabindex="0" als je iets focusbaar wilt maken wat dat normaal niet is, maar let op: maak geen containers zomaar toegankelijk als ze niets doen.

Sommige onderdelen gebruiken extra toetsen. In een tablijst wil je bijvoorbeeld met de pijltjes van tabblad wisselen, niet via Tab tussen elk tabblad springen. Wordt iedere tab een Tab-stop, dan raakt het toetsenbordgedrag uit balans. Test dus niet alleen of je iets met Tab kunt bereiken, maar ook of de toewijzing van de toetsen klopt per componentsoort, en of niets onverwachts onderschept wordt.

Zichtbare focus voorkomt verdwalen in de interface

Zonder muis moet je kunnen zien waar je bent op het scherm. De browser zet er meestal een blauwe rand om, maar een regel als outline: none wist die meteen. Het alternatief moet echt opvallen, ook als het ontwerp subtiel is. Wat in het design zichtbaar lijkt, kan op een scherm juist wegvallen tussen achtergronden of kleuren.

Let erop dat focus niet wordt weggewerkt onder vaste onderdelen, zoals een plakkende menubalk of een cookie-melding. Je kunt dan doorgaan met navigeren, maar mist visuele context. WCAG 2.2 noemt dat Focus Not Obscured. Test dit bij formulieren, modale dialogen en interfaces met sticky headers of footers. De gebruiker moet altijd weten wat er verzorgd wordt en wat er actief is.

Modale vensters vragen extra aandacht. De focus hoort direct in het venster te beginnen en mag niet ontsnappen naar de onderliggende pagina. Sluit je een modal, dan moet de focus terug naar hetgeen waarmee je hem opende. Heb je een andere stap die logischer is, kan dat natuurlijk, maar het moet altijd duidelijk blijven waar je bent. Test de focus zowel bij gewone interacties als bij fouten of dynamische updates.

Kleurcontrast en informatie die niet alleen op kleur steunt

Zwak contrast maakt tekst moeilijk leesbaar, of nu door verminderd zicht, kleurenblindheid, of gewoon door fel licht. WCAG 2.2 geeft als richtlijn voor gewone tekst een contrastverhouding van minimaal 4,5:1, voor grote tekst 3:1 op niveau AA. Onderdelen als knoppen, grafieken, statusindicatoren moeten ook aan eisen voldoen. Een kleurtje kiezen op het oog is niet genoeg, check altijd de werkelijk gebruikte waarden van voorgrond en achtergrond, niet alleen in het designbestand.

Dingen als transparantie, overlays, achtergrondplaatjes en hover/focus-stijlen kunnen het contrast ineens veranderen. Kijk dus ook naar placeholdertekst, foutboodschappen, uitgeschakelde onderdelen of grafieklabels. Tekst die onleesbaar is in een bepaalde staat, blijft een probleem. Een knop kan in normale toestand prima zijn, maar bij focus een te zwak contrast krijgen.

Staat er informatie op een plek die alleen via kleur duidelijk wordt? Dan is dat onvoldoende. Foutmeldingen die alleen een rode rand toevoegen geven mensen met kleurenblindheid geen signaal. Voeg daarom altijd tekst toe of een pictogram met een duidelijke naam. In grafieken of bij labels kun je werken met vormen, patronen, iconen of tekst. Let wel op dat die extra aanduiding niet verdwijnt in het beeld, een verkeerd geplaatst symbool zegt dan alsnog niets.

WCAG-criteria vertalen naar concrete ontwerpkeuzes

WCAG maakt toegankelijkheid handiger met vier principes: waarneembaar, bedienbaar, begrijpelijk, robuust. Die zijn vervolgens omgezet in testbare succescriteria, onderverdeeld in A, AA en AAA. Voor de meeste projecten is AA het uitgangspunt, maar wat nodig is, hangt af van de context en soms van wetgeving. Een lijstje met criteria helpt, maar zegt niet wanneer gebruikers echt problemen tegenkomen; bekijk daarom welke taken uitgevoerd moeten worden.

Lagen lopen in elkaar. Een label dat op het scherm boven een veld staat, moet in de code ook echt gekoppeld zijn. Een waarschuwing moet visueel te zien zijn, maar ook aangekondigd worden voor wie zonder zicht werkt. Een losse toets voldoet misschien op papier, maar als een knop wel focusbaar is maar geen duidelijke naam heeft, blijft de praktijk onbruikbaar.

Leg vast wat je onderzoekt: welke pagina's, toestanden, componenten zijn getest? Alleen de homepage zonder foutmeldingen test zegt eigenlijk weinig over de toegankelijkheid van het hele systeem, zoals afrekenen of zoeken. Vergeet variaties niet: ingelogd, zonder resultaten, met fouten, of op mobiel. Criteria zijn een hulpmiddel; het draait om het vinden van echte oorzaken, zoals missende semantiek of te zwak contrast. Zo kun je design, HTML en interacties gericht verbeteren.

Formulieren toegankelijk maken met labels en foutmeldingen

Start bij een formulier met een label dat ook in de HTML aan het veld is gekoppeld. Alleen visuele tekst naast het invulveld is niet genoeg; zonder koppeling snapt een schermlezer niet waar het label bij hoort. Gebruik altijd een <label> en kies een naam die is afgestemd op wat je wilt dat de gebruiker doet. Placeholdertekst is niet hetzelfde: die verdwijnt bij typen en is vaak nauwelijks leesbaar. Uitleg over het juiste formaat of verplichte velden hoort technisch verbonden te zijn aan het veld.

Laat bij een fout direct waar en wat weten. Alleen een rood randje rond het veld mist detail. Zet een tekst vlakbij het probleemveld, omschrijf wat er aangepast moet worden en koppel dit met bijvoorbeeld aria-describedby aan het invoerveld. Gebruik een extra markering als het veld ongeldig is. Zijn er meerdere fouten, dan helpt een foutoverzicht bovenaan, mits elke link werkt en de gebruiker duidelijk hoort dat er problemen zijn.

Test alles met toetsenbord en schermlezer, vooral na validatie. Krijgt de gebruiker het juiste bericht? Komt focus op de juiste plek terug en blijven gegevens bewaard? Meldingen bij elke toetsaanslag storen vaak, terwijl pas melden na een verzending soms te laat is. Welk moment het beste is, hangt af van de taak en de risico’s. Belangrijk is in ieder geval dat fouten snel zichtbaar zijn, concreet en niet alleen met kleur aangegeven.

ARIA en dynamische componenten zorgvuldig toepassen

Waar standaard HTML niet kan uitleggen wat iets doet, kun je ARIA gebruiken om extra betekenis toe te voegen. Zo kun je een element een naam geven, de status "gekozen" of "aan" aangeven, of duidelijk maken wanneer iets is veranderd. Maar let op: ARIA zorgt niet dat iets focusbaar of bedienbaar wordt, en voegt geen gedrag toe. Een div met role="button" heeft nog steeds goede toetsenbordlogica, focus en activatie nodig.

Voorkom dat je rollen en eigenschappen toevoegt die botsen met wat een element al is. Een fout gekozen naam levert soms meer verwarring op dan geen ARIA. Gebruik altijd standaard HTML als het kan en voeg ARIA alleen toe als er iets ontbreekt. Test het resultaat in browsers en met verschillende hulpmiddelen; hoe ARIA werkt hangt af van die combinatie en verschilt soms flink.

Dynamische updates vragen extra. Meldingen zoals "opgeslagen" zijn voor zienden soms duidelijk, maar voor een schermlezergebruiker niet hoorbaar, tenzij je een live region gebruikt. Wees zuinig daarmee, want te veel signalen maken het onrustig. Kondig alleen informatie aan die voor de taak nodig is en op het juiste moment. Let erop dat verborgen onderdelen echt onzichtbaar zijn voor hulpsoftware, en check of gefocuste interactie bij open menu’s en modals altijd goed loopt.

Handmatige toegankelijkheidstests naast automatische controles

Automatische tools sporen technische missers op als missende alt-teksten, foute ARIA-verwijzingen en slechte contrasten. Daarmee vind je snel technische fouten, maar geen onduidelijke links, rare leesvolgorde, of taken die met een schermlezer niet meer te doen zijn. Een goede scan is dus geen bewijs dat alles werkt. Automatiseer daar waar het kan, maar beoordeel complexe dingen altijd menselijk.

Zelf toetsenbordtesten levert andere inzichten. Met Tab, Shift+Tab, Enter, spatie en pijltjes check je direct of de focus logisch blijft, niet uit beeld springt, en of de volgorde werkt zoals verwacht. Test altijd een complete taak, bijvoorbeeld zoeken, een filter instellen en iets openen. Leg per probleem vast wanneer en hoe het fout ging, welke toets je gebruikte en wat je verwachtte, zodat ontwikkeling verder kan.

Controle met een schermlezer laat rollen, namen en status zien die je anders mist. Begin met kerngebruik, op verschillende browsers en hulpsoftware. Kijk ook naar vergroting, herschikking van de layout en aangepaste contrastopties als dat relevant is. Laat gebruikers met echte hulpmiddelen testen; die merken dingen op die technisch goed zijn, maar in het gebruik gewoon niet prettig of duidelijk blijken. In een testrapport maak je onderscheid tussen ernst, impact en richting voor herstel.

Veelgestelde vragen