Waarover wordt er een rechtszaak aangespannen: een praktijkgids over de UI-patronen achter 6.666 klachten over toegankelijkheid

De koptekst is het eerste interactieve gedeelte op elke pagina, en de hamburgerknop is vaak het eerste waar een toetsenbordgebruiker op klikt. Wanneer die knop wordt weergegeven als een <div> als er een CSS-achtergrondafbeelding wordt gebruikt, er geen toegankelijke naam is, of als er een menu wordt uitgevouwen dat de focus vasthoudt of de status (open/gesloten) niet aangeeft, wordt de hele site structureel onbruikbaar via het toetsenbord nog voordat de gebruiker daadwerkelijk inhoud heeft aangeraakt.

De skip-link is de bijbehorende fout. Een werkende "Skip to main content" Die link is een kwestie van vijf regels code, maar het is ook de meest efficiënte manier om te controleren of een ontwikkelteam toegankelijkheid überhaupt op zijn checklist heeft staan. In klachten worden beide vaak in één alinea genoemd, omdat een ontbrekende of defecte skip-link als een soort waarschuwingssignaal fungeert: als het team geen skip-link heeft geïmplementeerd, heeft het vrijwel zeker ook geen `aria-expanded`-toestanden geïmplementeerd.

Geef de menutrigger weer als een echte <button> met een zichtbaar of alleen voor schermlezers bestemd tekstlabel en een beheerd aria-expanded attribuut. Geef een "Skip to main content" link die zichtbaar wordt wanneer de muis erop wordt geplaatst en die binnen de <main> oriëntatiepunt. Zorg ervoor dat de focus naar het menu gaat wanneer het wordt geopend, terugkeert naar de trigger wanneer het wordt gesloten, en dat Esc sluit het menu.

Op de meeste grote websites is de zoekfunctie opnieuw opgebouwd als een aangepaste component: een tekstinvoerveld met debounce-functionaliteit dat bij elke toetsaanslag een verzoek verstuurt en een zwevende lijst met suggesties weergeeft binnen een absoluut gepositioneerd <div>. De tekstinvoer zelf werkt meestal prima. De lijst met suggesties is dat bijna nooit. Deze wordt buiten de DOM-context van het invoerveld weergegeven en heeft geen role="listbox", nee aria-activedescendant, en er wordt geen melding gegeven in de live-regio wanneer de resultaten verschijnen. Een gebruiker van een schermlezer typt, hoort niets, drukt op Enter en krijgt een resultatenpagina te zien waarvan hij niet wist dat die klaarstond.

Hetzelfde architectuurpatroon komt terug in de filterpanelen van faceted search en in de resultatenlijst zelf: elementen waarop de toetsenbordfocus kan worden geplaatst, die visueel aanwezig zijn maar nooit worden aangekondigd. Klachten over de zoekfunctie hebben zelden betrekking op het zoekvak; ze gaan over alles wat verschijnt nadat de gebruiker iets heeft getypt.

Gebruik het gangbare WAI-ARIA-patroon voor keuzelijsten: role="combobox" op de invoer met aria-expanded, aria-controls, en aria-activedescendant aangesloten op een role="listbox" suggesties. Voeg een beleefd live-gebied toe dat het aantal resultaten weergeeft. Zorg ervoor dat de lijst met suggesties ook met de pijl-omlaag-toets kan worden bereikt, en niet alleen met de muis.

Het PLP-raster bundelt verschillende anti-patronen in één scherm. Elke tegel is doorgaans een aanklikbare kaart met drie of vier interactieve onderliggende elementen — afbeeldingslink, titellink, kleurstalen, knop voor snel toevoegen — die zijn verpakt in een andere link naar de productpagina. Het resultaat is geneste interactieve elementen (een HTML-fout), overbodige linktekst („Hero Dash Three Graphic Image Link” die vier keer wordt herhaald) en kleurstalen die zijn opgebouwd uit <div> elementen met klikgebeurtenissen maar zonder rol en zonder naam.

De filterzijbalk voegt een tweede categorie van fouten toe. Filterfacetten zijn meestal lijsten met selectievakjes, maar ze zijn opgebouwd uit aangepaste div- en span-elementen die zo zijn opgemaakt dat ze eruitzien als selectievakjes, waarbij de daadwerkelijke <input> verborgen buiten het scherm. Wanneer die verborgen invoer zijn koppeling verliest — door een CSS-regel, een JavaScript-gebeurtenishandler die het indrukken van de spatiebalk opvangt, of een ontbrekende for attribuut op het zichtbare label — het filter kan dan alleen met de muis worden bediend.

Gebruik één anker per tegel met een beschrijvende tekst, in plaats van drie links per product. Geef kleurstalen zo realistisch mogelijk weer <button> elementen binnen een role="radiogroup". Maak filterfacetten op basis van de feitelijke <input type="checkbox"> elementen waaraan <label> tags; geef de invoervelden een visuele opmaak in plaats van ze te verbergen. Geef wijzigingen in het filter aan met een beleefde live-regio.

Op de productdetailpagina moet een gebruiker van een schermlezer een aantal specifieke keuzes in de juiste volgorde maken: een kleur kiezen, een maat kiezen, een aantal opgeven en vervolgens het product aan het winkelmandje toevoegen. Elk van deze keuzes wordt in moderne e-commerce geïmplementeerd als een aangepaste widget — meestal een horizontale rij van <button>-vormig <div>Wat de afmetingen betreft: gekleurde tegels opgebouwd uit met CSS opgemaakte div-elementen, en een numerieke schuifregelaar bestaande uit twee pictogramknoppen aan weerszijden van een invoerveld. De knoppen voor verhogen en verlagen worden standaard geleverd zonder toegankelijke naam; in klachten worden ze omschreven als aangekondigd als „button, button“ zonder dat duidelijk wordt wat ze precies doen.

Maattabellen vormen een apart probleem: ze zijn bijna altijd te vinden achter een link met de tekst ‘Maattabel’ die een pop-upvenster opent, en de link zelf heeft vaak geen tekst, het pop-upvenster heeft vaak geen zichtbare titel en de tabel daarin heeft vaak geen kopteksten voor de rijen of kolommen.

Gebruik echte formulierelementen. Kleurstalen en maatkeuzeschakelaars moeten een role="radiogroup" van role="radio" knoppen (of onzichtbaar weergegeven keuzerondjes), elk met een toegankelijke naam zoals „Grootte: Medium“. De schuifregelaar voor het aantal moet een genummerd invoerveld met label zijn, met bijbehorende knoppen voor verhogen en verlagen waarvan de toegankelijke namen de actie en het huidige aantal bevatten. Plaats het gehele selectieblok in een fieldset met een legenda.

'Toevoegen aan winkelwagen' is het meest geteste moment in elke e-commerce-funnel en een van de punten die voor gebruikers van ondersteunende technologie het vaakst niet goed werken. Het patroon is mechanisch: een bezoeker drukt op de knop, er verschijnt twee of drie seconden lang een klein bevestigingsvenster of een mini-winkelwagen, en het winkelwagenpictogram werkt het aantal artikelen in de koptekst bij. Ziende gebruikers zien alle drie de signalen. Gebruikers van schermlezers ontvangen er doorgaans geen. De melding wordt buiten het actieve gebied weergegeven, het venster verschijnt zonder focusbeheer en de wijziging van het aantal in het winkelmandje wordt weergegeven als een gewone DOM-wijziging die geen enkele schermlezer zal aankondigen.

Het resultaat is een knop die, vanuit het oogpunt van de gebruiker, niets doet. Ze drukken erop, horen niets, denken dat het niet gelukt is en drukken er nog een keer op. In sommige klachten wordt beschreven dat men vijf of zes keer op de knop heeft gedrukt voordat men zich realiseerde dat er stilletjes vijf of zes artikelen in het winkelmandje waren terechtgekomen.

Omring het gedeelte met de karstatus met aria-live="polite" en de tekst bij elke succesvolle toevoeging bijwerken. Als het ontwerp gebruikmaakt van een bevestigingsvenster, verplaats dan de focus naar het venster wanneer dit wordt geopend en breng de focus terug naar de oorspronkelijke knop wanneer het venster wordt gesloten. Werk het badge met het aantal artikelen in het winkelmandje bij met een mededeling die alleen voor schermlezers is bedoeld, zoals: „1 artikel toegevoegd. Totaal in winkelmandje: 3 artikelen.”

Bedieningselementen die uitsluitend uit pictogrammen bestaan, vertonen een voorspelbaar gedrag: de zichtbare inhoud bestaat uit een SVG-afbeelding of een pictogram uit een pictogramlettertype, de toegankelijke inhoud is leeg en de uitvoer van de schermlezer beperkt zich tot de structurele rol van het element zonder naam. Het winkelwagenpictogram wordt uiteindelijk aangekondigd als "link" of "ingeklapt"; de chatballon als "knop"; de rij met sociale pictogrammen in de voettekst als "link, link, link, link, link". De gebruiker heeft geen manier om te weten wat ze doen.

Winkelwagenpictogrammen geven vaker fouten weer dan andere pictogrammen, en dat heeft een structurele oorzaak: bij veel implementaties wordt het aantal artikelen in de toegankelijke naam van het pictogram weergegeven (het pictogram toont bijvoorbeeld „0“ in de SVG), en de schermlezer leest alleen het cijfer voor. Er zijn klachten dat het winkelwagenpictogram wordt aangekondigd als „3, link“ of „0, link“, zonder dat duidelijk wordt gemaakt dat „3“ verwijst naar het aantal artikelen in een winkelwagen.

Elk besturingselement dat alleen uit pictogrammen bestaat, moet een toegankelijke naam hebben. Voeg een aria-label op de knop of plaats er een visueel verborgen tekstlabel in: "Shopping cart, 3 items". Vermijd het gebruik van cijfers in de toegankelijke naam van het pictogram zonder context. Gebruik voor decoratieve pictogrammen die naast zichtbare tekst staan aria-hidden="true" klik op het pictogram en laat de tekst als label dienen.

De afrekenpagina brengt meer nalevingsrisico’s per pixel met zich mee dan welke andere pagina op een webshop dan ook, en er doen zich veel fouten voor. Adreskeuzelijsten die als aangepaste <div> onderdelen die de spatiebalk negeren. Markeringen voor verplichte velden worden alleen weergegeven als een rood sterretje, zonder aria-required en geen programmatische koppeling. Inline foutmeldingen worden in rode tekst onder het veld weergegeven, zonder aria-describedby het veld wordt gekoppeld aan de foutmelding en er wordt geen melding gegeven in het actieve gebied wanneer de validatie mislukt. De gebruiker vult het formulier in, klikt op ‘Doorgaan’, wordt zonder enige melding teruggestuurd en kan op geen enkele manier achterhalen welke velden niet kloppen of waarom.

In honderden gevallen komen steeds weer dezelfde klachten terug: foutmeldingen worden niet voorgelezen, foutmeldingen zijn vaag, factuurgegevens kunnen niet worden ingevoerd. Dit zijn geen op zichzelf staande bugs. Het is het standaardgedrag van de meeste afrekencomponenten voor webwinkels die worden geleverd zonder dat er expliciet aandacht is besteed aan toegankelijkheid.

Gebruik echte <label> elementen die zijn gekoppeld aan invoer via for/id. Markeer verplichte velden met aria-required="true" en geef aan dat het veld verplicht is in de zichtbare tekst, niet alleen via de kleur. Als de validatie mislukt, geef dan de foutmelding weer binnen het invoerveld aria-describedby doel, geef het veld dat niet voldoet aria-invalid="true", en verplaats de toetsenbordfocus naar het eerste ongeldige veld. Zorg bovenaan het formulier voor een overzicht van de fouten met koppelingen naar elk veld dat niet klopt.

Het betalingsblok is ongebruikelijk omdat het vaak wordt weergegeven via een ingebed iframe van een derde partij — Stripe Elements, Braintree Hosted Fields of een Adyen-drop-in. Binnen het iframe is het formulier van de betalingsprovider doorgaans duidelijk gelabeld. Maar zodra een site zijn eigen kaartinvoer bouwt, of de ingebedde velden in een aangepaste lay-out plaatst die de labels overschrijft met visuele plaatshouders, worden de vier velden — nummer, vervaldatum, CVV, postcode — voor een schermlezer een rij lege invoervelden.

Het CVV-veld wordt het vaakst verkeerd gelabeld, omdat ontwerpers het label vaak vervangen door een vraagtekenpictogram dat een tooltip opent waarin wordt uitgelegd wat een CVV is. De tooltip is niet het label; het veld heeft nog steeds een programmatische naam nodig. Als die ontbreekt, leest de schermlezer het hele betaalblok voor als „bewerken, bewerken, bewerken, bewerken” en wordt de transactie afgebroken.

Als je een integratie met door derden gehoste velden gebruikt, volg dan de toegankelijkheidsrichtlijnen van de leverancier — de meeste bieden een gedocumenteerde manier om velden buiten het iframe te labelen. Als je een aangepaste kaartregistratie bouwt, moet elk invoerveld een echte <label> element met een zichtbaar tekstlabel, plus autocomplete="cc-number" / cc-exp" / cc-csc" attributen, zodat wachtwoordbeheerders en ondersteunende technologie de velden op basis van hun functie kunnen herkennen.

Op de winkelwagenpagina doet zich dezelfde fout met de hoeveelheidsregelaar voor productpagina’s voor, maar dan met grotere gevolgen: een gebruiker van een schermlezer die de regelaar niet kan bedienen, kan de bestelling niet afronden. De knop ‘Verwijderen’ is op zichzelf al een anti-patroon — het is meestal een klein ×-pictogram naast elk product, vaak zonder zichtbare tekst, geen aria-label, en er wordt niets gemeld wanneer de rij wordt verwijderd. De gebruiker drukt op wat hij hoopt dat de verwijderknop is, de rij verdwijnt en de schermlezer zegt niets. Er is geen manier om te controleren of de handeling is gelukt.

In verschillende klachten wordt een verwante foutmelding beschreven: het lopende totaalbedrag in het winkelwagentje wordt dynamisch bijgewerkt wanneer de hoeveelheden veranderen of artikelen worden verwijderd, maar het nieuwe totaalbedrag wordt weergegeven als gewone DOM-tekst buiten een live-gebied, waardoor de gebruiker geen idee heeft wat er in rekening zal worden gebracht.

Elk rijdend item moet een gelabelde verwijderknop bevatten (bijv., "Remove Blue T-Shirt, size M, from cart"). Schuifregelaars voor hoeveelheden moeten hun huidige waarde vermelden als onderdeel van de toegankelijke naam of via bijbehorende updates van de live-regio. Het subtotaal van het winkelmandje moet worden weergegeven in een aria-live="polite" regio, zodat wijzigingen worden aangekondigd. Bevestig verwijderingen met een knop om de actie ongedaan te maken.

Dit is de grootste categorie in de dataset, omdat dit het goedkoopst is om op te sporen en het duurst om te negeren. Een schermlezer doorloopt de DOM, komt bij een <input>, en leest de toegankelijke naam ervan — die het berekent op basis van, in volgorde: aria-labelledby, aria-label, een gelieerde <label for>, de title attribuut of de plaatshouder. Als geen van beide aanwezig is, leest de schermlezer alleen de rol voor: „bewerkingsveld“ of „bewerken, leeg“. Die zin komt, bijna letterlijk, in honderden klachten terug.

De reden waarom dit zo vaak voorkomt, is structureel van aard. In moderne ontwerpsystemen wordt in het invoerveld vaak plaatshoudende tekst weergegeven als vervanging voor het zichtbare label, en ontwikkelaars gaan ervan uit dat de plaatshouder de functie van label vervult. Dat is echter niet het geval. De plaatshouder verdwijnt zodra de gebruiker begint te typen, laat geen programmatische naam achter en maakt het veld onbruikbaar voor iedereen die er later in het proces op terechtkomt of er na een fout naar terugkeert.

Elk interactief besturingselement krijgt een zichtbaar label dat programmatisch aan het element wordt gekoppeld. <label for="email">Email</label><input id="email" type="email"> is het standaardpatroon. Plaatshouders zijn aanvullende aanwijzingen, geen vervangingen. Gebruik voor besturingselementen waarbij een zichtbaar label echt ongewenst is (zoekvakken, pictogramknoppen), aria-label met beschrijvende tekst — nooit met een dubbele tijdelijke aanduiding.

De zin „niet aangekondigd of in focus gebracht“ komt letterlijk voor in meer dan 400 klachtmeldingen en is een van de meest voorkomende zinnen in de hele dataset. Deze zin beschrijft een specifieke fout: er verschijnt een modaal venster of dialoogvenster op de pagina (vaak automatisch — aanmelding voor een nieuwsbrief, leeftijdsverificatie, locatiebevestiging), de zichtbare inhoud verandert, maar de schermlezer krijgt geen signaal dat er iets is veranderd. De focus blijft op de onderliggende pagina. De gebruiker blijft met de tab-toets door de inhoud bladeren die zich onder het modaal venster bevond, zich er totaal niet van bewust dat er een blokkerend dialoogvenster is verschenen.

Dit is een schoolvoorbeeld van een modaal dat op alle fronten tegelijk tekortschiet: nee role="dialog", nee aria-modal="true", geen programmatische verschuiving van de focus bij het openen, geen focusval bij het openen, geen gedrag waarbij met Esc wordt gesloten, geen aangekondigde titel. Omdat al deze fouten samen voorkomen, heeft het los oplossen van één ervan geen invloed op de voortgang van de zaak.

Gebruik een gangbaar dialoogvensterpatroon (de WAI-ARIA Authoring Practices-specificatie dient als referentie). Bij het openen: verplaats de focus naar het eerste element in het dialoogvenster waarop de focus kan worden geplaatst, stel aria-modal="true" en role="dialog", geef het dialoogvenster de naam aria-labelledby met de muis naar de titel wijzen. Zolang het venster open is: houd de focus binnen het dialoogvenster. Bij het sluiten: breng de focus terug naar het element dat het venster heeft geopend. Reageer op de Esc-toets. Als het modale venster een proces onderbreekt (bijvoorbeeld automatisch afspelen bij het laden van de pagina), geef de gebruiker dan één manier om het venster definitief te sluiten.

Focusindicatoren worden meestal bewust uitgeschakeld door een ontwikkelaar of ontwerper die de standaardbrowseromtrek als visuele ruis beschouwde en *:focus { outline: none; } in een algemeen stylesheet. De pagina ziet er nu overzichtelijker uit voor een ziende muisgebruiker. Voor een ziende toetsenbordgebruiker — waaronder de meeste slechtziende gebruikers, gebruikers met een motorische beperking en gebruikers die zonder muis navigeren — wordt de pagina onbruikbaar. De gebruiker kan op Tab drukken, maar kan niet zien waar hij zich bevindt.

Dit is een van de weinige fouten die zonder hulpmiddelen zichtbaar is. Een kwaliteitscontroleur die zonder extra hulpmiddelen één keer met de tab-toets door de startpagina bladert, zal dit binnen een minuut opmerken. Het feit dat toegankelijkheidsteams dit consequent aantreffen op websites waarover een rechtszaak loopt, terwijl het bij interne controles over het hoofd is gezien, is een van de meest betrouwbare aanwijzingen in de dataset dat de website de toetsenbordtest helemaal niet heeft doorstaan.

Schakel nooit alles in één keer uit :focus contouren zonder opvulling. Zorg voor een duidelijk herkenbare stijl — meestal een contour van 2-3 px met voldoende contrast ten opzichte van zowel het element als de achtergrond — door gebruik te maken van :focus-visible de indicator verschijnt dus bij navigatie met het toetsenbord, maar niet bij muisklikken. Controleer dit bij elk interactief onderdeel, inclusief aangepaste widgets, links in kaarten en elementen met tabindex.

Het logo is de meest bekeken afbeelding op een website en een van de afbeeldingen die het vaakst niet werkt. Meestal is het een link die terugleidt naar de startpagina, maar de afbeelding wordt geleverd zonder alt, nee aria-label op de link, zonder omringende tekst. De schermlezer leest alleen voor “link”, zonder dat er informatie is over waar het naartoe leidt. Vermenigvuldig dat met elke pagina op de site.

De bredere categorie — afbeeldingen zonder alt-tekst — omvat bannerafbeeldingen, productfoto’s, hero-illustraties, pictogrammen voor sociale media en de enorme verzameling marketingafbeeldingen die een doorsnee webshop aanbiedt. In klachten in deze categorie worden vaak specifieke bestandsnamen van afbeeldingen genoemd, wat erop wijst dat de deskundige van de eiser een geautomatiseerde controle heeft uitgevoerd waarbij alle afbeeldingen werden opgesomd waarvan alt het kenmerk ontbrak of was leeg, terwijl het een beschrijving had moeten bevatten.

Logo’s moeten alt-tekst bevatten waarin de bedrijfsnaam wordt vermeld en, als het logo naar een andere pagina linkt, de bestemming — alt="Acme Co. — homepage". Decoratieve afbeeldingen krijgen een leeg alt-attribuut (alt=""), waardoor ze bewust aan ondersteunende technologie worden onttrokken. Informatieve afbeeldingen krijgen een beschrijvende alt-tekst. Vermijd het automatisch genereren van alt-tekst op basis van bestandsnamen of AI-ondertiteling zonder menselijke controle; in klachtenregisters worden herhaaldelijk gevallen genoemd waarin overlay-tools een bedrijfslogo omschreven als „een blauw en geel bord“.

Schermlezers bieden een weergave met een „lijst met links“, die door ervaren gebruikers veelvuldig wordt gebruikt om een pagina in enkele seconden te scannen. In die weergave wordt alleen de linktekst getoond, los van de omringende alinea. Een pagina waarop elke blogteaser eindigt met “Lees meer” wordt in die weergave weergegeven als vijftien identieke vermeldingen. Een pagina met vijf lege links — <a href="..."></a>, wat vaak voorkomt wanneer pictogrammen in link-tags staan zonder tekst als alternatief — wordt weergegeven als vijf spaties.

De oplossing is algemeen bekend en het probleem is algemeen bekend; daarom duikt dit patroon steeds weer op in klachten — het feit dat het blijft voorkomen, wijst op een ontwikkelingsproces zonder geautomatiseerde linter voor linktekst en zonder handmatige controle met een schermlezer.

Elke link moet een toegankelijke naam hebben die de bestemming of actie beschrijft. Vervang algemene uitdrukkingen door beschrijvende — “Lees meer” wordt “Lees meer over de resultaten van het derde kwartaal”. Voeg bij links die alleen uit een pictogram bestaan visueel verborgen tekst toe of een aria-label. Voer een geautomatiseerde controle uit (Axe, Lighthouse, enz.) op lege <a> elementen tijdens CI.

Video komt in klachten op twee manieren voor. De eerste is voor de hand liggend: een marketingvideo, productdemo of uitlegvideo wordt aangeboden zonder ondertiteling, transcriptie of enige tekstuele alternatieven — waardoor een dove of slechthorende bezoeker geen toegang heeft tot de inhoud. Het tweede is subtieler: een hero-video die automatisch wordt afgespeeld wanneer de pagina wordt geladen, wat de uitvoer van de schermlezer verstoort en in strijd is met de pauze-/stopknoppen die worden verwacht op WCAG 2.2 AA-niveau (volgens SC 2.2.2 Pauzeren, Stoppen, Verbergen voor bewegende inhoud en SC 1.4.2 voor alle audio).

In sommige klachten in deze dataset wordt gesteld dat „het ontbreken van ondertiteling bij video’s op de website een schending van de ADA vormt“, wat als een juridische conclusie wordt gepresenteerd. Of die interpretatie standhoudt, hangt af van het rechtsgebied en de omstandigheden; wat echter wel vaststaat, is dat deze video’s consequent niet voldoen aan WCAG 2.2 AA, de norm die door de meeste rechtbanken en in schikkingsovereenkomsten als de geldende nalevingsmaatstaf wordt beschouwd.

Zorg voor gesynchroniseerde ondertitels bij alle vooraf opgenomen video’s met geluid. Zorg ook voor een teksttranscript; transcripten zijn handig voor gebruikers met het geluid uitgeschakeld, in omgevingen met een lage bandbreedte en voor indexering. Vermijd automatisch afspelen; als automatisch afspelen om ontwerptechnische redenen noodzakelijk is, zorg dan voor een pauze-/stopknop die direct via het toetsenbord te bedienen is. Voor inhoud die alleen uit video bestaat (zonder geluid), zorg voor een audiodescriptie of een tekstalternatief.

Het inloggen vormt de poort naar de gehele geauthenticeerde ervaring. Wanneer het formulier niet werkt, worden alle daarachter liggende pagina’s onbereikbaar, en in klachten wordt die kettingreactie vaak als één enkele barrière gezien. Het patroon is dezelfde fout in de formulierlabels als bij E·01, vaak gecombineerd met drie specifieke subfouten: een schakelaar voor 'Wachtwoord weergeven' die is geïmplementeerd als een knop met alleen een pictogram, zonder naam en zonder melding van de statuswijziging; een CAPTCHA die het gebruik van een schermlezer volledig onmogelijk maakt; en inline-fouten ('ongeldige inloggegevens') die op het scherm worden weergegeven maar niet worden aangekondigd.

Het selectievakje 'Onthoud mij' is een extra terugkerende subfout: weergegeven als een opgemaakte <div>, met de feitelijke <input> Omdat het selectievakje buiten het scherm ligt, kan het wel met de muis worden bediend, maar niet met het toetsenbord of een schermlezer. De gebruiker heeft geen mogelijkheid om zich aan te melden voor een permanente sessie.

Gebruik echte <input>, <label>, en <button> elementen. Maak van de schakelaar voor het tonen/verbergen van het wachtwoord een echte knop met een toegankelijke naam die wordt aangepast aan de status ("Show password" / "Hide password") en kondig de wijziging aan met aria-pressed. Zorg voor een toegankelijk alternatief voor CAPTCHA’s op basis van afbeeldingen (audio-CAPTCHA, of — bij voorkeur — vervang CAPTCHA door op risico gebaseerde authenticatie of de toegankelijke varianten van hCaptcha).

Schermlezers presenteren de pagina via drie navigatiemodi: op kop, op herkenningspunt en op link. Een pagina die wordt geleverd zonder een <h1>, zonder <main>, <nav>, en <footer> bezienswaardigheden, en zonder een lang="en" attribuut op de <html> element heeft alle drie deze navigatiemogelijkheden tegelijkertijd verwijderd. Gebruikers kunnen niet door de pagina bladeren, niet direct naar bepaalde inhoud springen en de schermlezer kan niet de juiste uitspraakmodule laden.

Dit is een ongewoon ingrijpende fout: het ontbreken van één enkel oriëntatiepunt leidt tot een lawine van klachten, omdat alle navigatiestrategieën van schermlezers die hiervan afhankelijk zijn, nu mislukken. Klachten in deze categorie noemen doorgaans vier of vijf specifieke structurele problemen tegelijk, die worden aangevoerd als bewijs dat de website geen semantische basis heeft.

Elke pagina krijgt er precies één <h1>, met tussenkopjes (<h2>, <h3>) logisch genest. Omring regio’s met HTML5-landmark-elementen: <header>, <nav>, <main>, <aside>, <footer>. Instellen lang op de hoofdmap <html> element. Controleer dit met een outline-checker of voer het volgende uit document.querySelectorAll('h1').length === 1 als rooktest in CI.

Het grootste deel van de kwaliteitscontrole op toegankelijkheid vindt plaats in desktopbrowsers met NVDA of JAWS. Hulptechnologie voor mobiele apparaten — VoiceOver op iOS, TalkBack op Android — geeft een andere weergave van dezelfde DOM weer, vaak met andere fouten. In klachten wordt herhaaldelijk de afkorting "mobiele SRU" (mobiele schermlezergebruiker) gebruikt om fouten aan te duiden die specifiek zijn voor de mobiele weergave: een hamburgermenu dat werkt met NVDA op de desktop maar stil blijft onder VoiceOver, een Apple Pay-knop die bereikbaar is op een laptop maar niet op de iPhone-versie van de pagina, foutmeldingen die op de desktop worden weergegeven maar niet op mobiel.

Uit de gegevens blijkt dat verdachten die op desktopgebied overigens prima presteren, toch worden aangeklaagd vanwege problemen die specifiek met mobiele apparaten te maken hebben. Mobiele gelijkwaardigheid is een aparte toetsingscriterium.

Test minimaal met VoiceOver in Safari op iOS en TalkBack in Chrome op Android, aan de hand van dezelfde workflows die bij de kwaliteitscontrole op de desktop worden doorlopen. Besteed daarbij extra aandacht aan interacties via gebaren, ingebouwde betaalknoppen en de uitspraak van formuliervelden wanneer deze actief worden. Als er een native app beschikbaar is, voer dan dezelfde controle daarop uit — klachten hebben vaak betrekking op zowel de webversie als de app binnen hetzelfde dossier.

De toegankelijkheids-overlay is het enige voorbeeld in deze catalogus waarbij de fout helemaal niet in de onderliggende website zit — maar juist in de zogenaamde ‘oplossingslaag’ die is toegevoegd om het probleem te verhelpen. Klachten in deze categorie wijzen op twee verschillende nadelen. Ten eerste lossen overlays de onderliggende barrières niet daadwerkelijk op, waardoor de gebruiker nog steeds te maken krijgt met dezelfde defecte modale vensters, verkeerd gelabelde formulieren en onverwachte foutmeldingen, ongeacht of de widget aanwezig is. De tweede is nog scherper: overlays introduceren soms nieuwe fouten door onjuiste labels in te voegen, ARIA-rollen verkeerd toe te passen of de eigen configuratie van ondersteunende technologie van de gebruiker te verstoren.

Een opvallend detail: in klachten uit 2024 en 2025 wordt de leverancier van de overlay steeds vaker met naam genoemd. In twee specifieke passages uit klachten worden UserWay en AccessiBe in ondubbelzinnige bewoordingen genoemd, en recente maatregelen van de FTC hebben ertoe geleid dat het toevoegen van een overlay nu expliciet het risico met zich meebrengt dat dit op zichzelf wordt gezien als bewijs dat er geen daadwerkelijke aanpassingen zijn doorgevoerd — in plaats van als verdediging tegen een rechtszaak.

Beschouw overlays als een waarschuwing, niet als een oplossing. Als er momenteel een overlay wordt gebruikt, stel dan een plan op voor een daadwerkelijke oplossing die de onderliggende code aanpakt in plaats van deze te verbergen. De beproefde aanpak bestaat uit een combinatie van: een geautomatiseerde scanner die in CI is geïntegreerd, een handmatige controle aan de hand van WCAG 2.2 AA, handmatig testen met ten minste één schermlezer en navigatie met alleen het toetsenbord, en voortdurende kwaliteitscontrole op toegankelijkheid tijdens het ontwerp- en ontwikkelingsproces.