Wanneer een gebruikersinterfacecomponent toetsenbordfocus ontvangt, moet de focusindicator een minimaal contrastverhouding van 3:1 hebben ten opzichte van aangrenzende kleuren en ten minste de omtrek bedekken van een 2 CSS-pixel brede doorgetrokken outline rondom het gefocuste element, of een equivalente indicatoroppervlakte. Het criterium is een van de weinige WCAG-toevoegingen die meetbare geometrie specificeert in plaats van gedrag.

De standaard browserfocusringen die ontwerpers vijftien jaar lang overschreven om esthetische redenen, falen deze meting op de meerderheid van geauditeerde productiesites. Aangepaste focusstijlen gebruiken doorgaans 1px-outlines of accentkleuren met laag contrast die er correct uitzien in ontwerpprogramma’s, maar een score lager dan 3:1 halen ten opzichte van de achtergrond van het feitelijk gefocuste element.

Het getal doet ertoe, ook al is het criterium AAA: het geeft aan wat er zou gebeuren als een toekomstige regelgever zou vastpinnen op WCAG 2.2 niveau AAA, of als een aanbestedingscontract dit ene criterium zou opwaarderen.

Stel een 2 CSS-pixel outline in met een kleur die ten minste 3:1 scoort ten opzichte van de achtergrond van het element; controleer met een contrastchecker in plaats van op het oog. Waar het ontwerpsysteem de browserfocus overschrijft, stel dan een focusstijltoken in dat ontwerpers niet per ongeluk onder de contrastdrempel kunnen verlagen.

Het aanraakdoel van elke pointerinvoer moet ten minste 24 bij 24 CSS-pixels zijn, behalve wanneer het doel inline in een zin staat, wanneer het wordt bepaald door de user agent, wanneer een equivalent doel beschikbaar is, of wanneer de functie van het doel essentieel is. Het criterium meet het aanraakdoel, niet het zichtbare pictogram.

Het criterium treft een specifiek UI-patroon: dichte icoontoolbalken, met name in editors, dashboards en datatabellen. De meeste pictogramknopiblibliotheken hanteren standaard visuele pictogramformaten van 16×16 of 20×20 pixels in een iets groter aanraakdoel. Wanneer ook het aanraakdoel kleiner is dan 24×24, faalt het criterium — en toolbalkontwikkelpers verkleinen de tussenruimten stelselmatig om meer pictogrammen in beperkte horizontale ruimte te plaatsen.

Stel een minimumtoken voor aanraakdoelgrootte in van 24 bij 24 CSS-pixels in het ontwerpsysteem, toegepast via opvulling (padding) in plaats van de eigen afmetingen van het pictogram. Waar toolbalken de ondergrens niet kunnen opvangen, voeg dan voldoende tussenruimte toe zodat aangrenzende doelen niet binnen de overlappingsuitzondering van het criterium vallen. Bied een equivalent op instellingsniveau aan (een groter menu) voor werkelijk krappe oppervlakken.

De authenticatiestap van een website of app mag niet afhankelijk zijn van een cognitieve functietest — een puzzel oplossen, een vervormde afbeelding overtikken, objecten herkennen in een raster — tenzij een alternatieve authenticatiemethode beschikbaar is, een ondersteunend mechanisme aanwezig is, of een objectherkenningsuitzondering van toepassing is. Het onthouden van een wachtwoord geldt als cognitieve functietest, wat de reden is dat wachtwoordbeheerders uitdrukkelijk worden geaccommodeerd.

De meeste op afbeeldingen gebaseerde CAPTCHA’s falen dit criterium op het eerste gezicht. Dat geldt ook voor “klik op de vakjes met verkeerslichten”-uitdagingen, tests voor het overtikken van vervormde tekst en elke stroom waarbij een eenmalig wachtwoord in een veld moet worden geplakt maar de plakfunctie is uitgeschakeld. Het patroon is geconcentreerd in inlog-, wachtwoordherstel- en accountaanmakstromen — precies de kritieke punten waar buitensluiting de grootste consequenties heeft.

Authenticatiestromen zijn ook het gebied waar de impact van het criterium het scherpst is, omdat een fout de ervaring niet verslechtert maar beëindigt.

Vervang cognitieve CAPTCHA’s door een niet-cognitief alternatief — apparaatgebaseerde attestatie, magische links, passkeys of onzichtbare risicobeoordeling. Laat automatisch invullen door wachtwoordbeheerders toe. Zorg dat kopiëren en plakken werkt in velden voor eenmalige wachtwoorden. Waar een CAPTCHA toch nodig blijft, bied een geluidsalternatief aan dat zelf geen transcriptie van vervormde spraak vereist.

Wanneer een gebruikersinterfacecomponent toetsenbordfocus ontvangt, mag het gefocuste element niet volledig verborgen zijn door door de auteur gecreëerde inhoud. Gedeeltelijke bedekking is op dit niveau toegestaan (een plakkerige koptekst die de bovenste helft van een gefocust veld overlapt is toegestaan); volledige bedekking niet.

De meest voorkomende botsing is een plakkerige koptekst — soms een cookiebanner of zwevende chatwidget — die het gefocuste formulierveld overlapt wanneer een toetsenbordgebruiker er naartoe tabt. Productiesites die tijdens de herontwerpgolf van 2020–22 een plakkerige koptekst aan een bestaand formulier toevoegden, misten routinematig het focus-en-scrollgedrag, omdat het originele formulier was geschreven voordat plakkerige elementen bestonden.

Stel scroll-margin-top (of scroll-padding-top op de scrollcontainer) in op de hoogte van eventuele plakkerige overlays. Test of tabben door een lang formulier het gefocuste element volledig zichtbaar scrollt onder elke koptekst. Combineer dit met zichtbare focusstijlen zodat de gebruiker kan zien waar de focus is terechtgekomen.

Functionaliteit die gebruikmaakt van een sleepbeweging moet ook bedienbaar zijn via een enkelpuntsactie — een tik, een klik of een equivalent dat geen aanhoudende pointerbewegingen vereist. Drag-and-drop-interacties zijn niet verboden; ze kunnen alleen niet het enige beschikbare pad naar de functie zijn.

Lijstvolgorde- en kanban-stijl-UI’s worden vaak geleverd met alleen sleepsortering. Hetzelfde geldt voor schuifregelaar-besturingen die zijn geïmplementeerd als sleepbare duimpjes zonder overeenkomende spinknop of tekstinvoer, en voor afbeeldingbijsnij-UI’s die een sleepbeweging vereisen om grenzen in te stellen. Het criterium treft deze patronen telkens.

Bied voor elke sleepinteractie een equivalent tik/klik-alternatief aan — knoppen “omhoog verplaatsen” en “omlaag verplaatsen” naast sleepbare lijstitems, een numerieke invoer naast een schuifregelaar, een klik-om-grenzen-in-te-stellen-modus in de bijsnijder. Waar het alternatief verborgen is in een contextmenu, zorg dan dat het via het toetsenbord bereikbaar is.

Binnen hetzelfde geauthenticeerde proces mag de gebruiker niet worden gevraagd dezelfde informatie tweemaal in te voeren — tenzij herhaling essentieel is, de vorige invoer niet langer geldig is, of de informatie betrekking heeft op beveiliging (een wachtwoordbevestiging bij het aanmaken van een account is de canonieke uitzondering). Automatisch invullen of selecteren uit eerder ingevoerde waarden voldoet aan het criterium.

Meerstapsafrekenstappen, formulieren met meerdere pagina’s en visum- of vergunningsaanvragen vragen stelselmatig naar hetzelfde adres, dezelfde naam of contactinformatie in twee afzonderlijke stappen, omdat die stappen door verschillende teams werden gebouwd en nooit op elkaar zijn afgestemd. De eerder ingevoerde waarden worden niet opgeslagen in een sessie die over de stappen heen gedeeld wordt.

Bewaar door de gebruiker ingevoerde waarden over de stappen van een enkel proces; vul overeenkomende velden in volgende stappen vooraf in; of bied een “gebruik hetzelfde adres”-knop met één klik aan. Het patroon komt doorgaans naar voren bij procesbeschrijving in plaats van bij een front-end-audit, zodat een cross-team-stroomreview de praktische herstelstap is.

Als een hulpmechanisme aanwezig is — een contactlink, een helplink, een chatwidget, een ondersteuningstelefoon, een zelfhulplink — moet dit op dezelfde relatieve positie verschijnen op alle pagina’s waar het aanwezig is. Het criterium vereist niet dat hulp aanwezig is; alleen dat de plaatsing consistent is waar het wél aanwezig is.

Het criterium is eenvoudig in theorie en treft een beperkte groep sites die een “Neem contact op”-link in de koptekst hebben op sommige pagina’s, in een footer op andere, en in een zwevende chatwidget op een derde groep pagina’s — vaak het gevolg van meerdere sitegedeelten die eigendom zijn van verschillende teams met afzonderlijke sjablonen.

Controleer de plaatsing van hulpmechanismen in alle sjablonen; kies één canonieke locatie (koptekst, permanente footer of zwevende widget) en reconcileer eventuele afwijkingen. De oplossing is zelden technisch; het is een stap in content- en sjabloonbeheer.

De AAA-variant van 2.4.11: wanneer een gebruikersinterfacecomponent toetsenbordfocus ontvangt, mag het gefocuste element helemaal niet verborgen zijn door door de auteur gecreëerde inhoud. Gedeeltelijke bedekking is op dit niveau verboden — een plakkerige koptekst die enig deel van het gefocuste veld dekt, faalt.

Dezelfde overlaybotsingen die 2.4.11-fouten veroorzaken, blijven bestaan bij 2.4.12. Sites die scroll-margin-top hebben toegepast om aan het minimumcriterium te voldoen, laten doorgaans enkele CSS-pixels overlap achter bij randgevallen met bepaalde viewporthoogten. Op AAA-niveau is die overlap de fout.

Stel scroll-margin-top ruimschoots in boven de hoogte van elke door de auteur gecreëerde overlay, inclusief dynamische (cookiebanners die bij eerste bezoek verschijnen, chatwidgets die bij hover uitvouwen). Voeg expliciete regressietests toe voor tab-in-formulier-gedrag op gangbare viewportformaten.

De AAA-variant van 3.3.8: authenticatie mag in geen geval afhangen van een cognitieve functietest. De uitzonderingen voor objectherkenning en persoonlijke inhoud die op AA van toepassing zijn, gelden hier niet. Geheugentests, overtikken en afbeeldingsherkenningsuitdagingen falen allemaal op dit niveau.

Zelfs sites die traditionele CAPTCHA’s hebben vervangen door objectherkenningsuitdagingen (de AA-uitzondering) falen 3.3.9. Het criterium is het signaal van de werkgroep over de richting die authenticatie op moet: weg van cognitieve uitdagingen en naar apparaatattestatie of biometrische verificatie.

Adopteer passkeys (WebAuthn) als primair authenticatiemechanisme; behandel wachtwoord plus passkey als een overgangsstatus, niet als bestemming. Waar afbeeldingsherkenning is behouden voor risicobeoordeling, voer dit server-side uit op basis van gedragssignalen in plaats van als zichtbare gebruikersvraag.