Een modal met een onbereikbare sluitknop

Een modal onderbreekt de gewone leesvolgorde van de pagina. Dat is precies waarom hij betrouwbaar moet sluiten: de bezoeker heeft daarna geen ander uitgangspunt meer. Wie alleen met een toetsenbord werkt, bijvoorbeeld door een motorische beperking of door een schermlezer, kan niet klikken op een knop die niet de focus kan krijgen.

Het W3C beschrijft in zijn toegankelijkheidstutorials (https://www.w3.org/WAI/tutorials/) hoe je webinhoud ontwikkelt die bruikbaar is voor mensen met een beperking en een betere ervaring geeft aan iedereen. Een modal is daar een goed onderwerp voor een eigen controle: je test of bezoekers hem met toetsenbord en op kleine schermen kunnen sluiten. De bron zelf zegt daar niets specifieks over.

Let op de grens van dit artikel: we onderzoeken hier één gedrag, namelijk het kunnen sluiten van de modal. We beoordelen niet of je hele site aan een toegankelijkheidsstandaard voldoet, en deze procedure is geen conformiteitsaudit.

Het is ook een snelheidsonderwerp. Een modal die pas laat laadt of veel script meetrekt, vertraagt de pagina en kan het moment verschuiven waarop een bezoeker de sluitknop effectief kan gebruiken. MDN omschrijft webperformance als zowel objectieve meting als ervaren gebruikservaring (https://developer.mozilla.org/en-US/docs/Web/Performance), inclusief vragen als: reageren knoppen en laden pop-ups vlot? Controleer daarom ook zelf of de sluitknop meteen reageert nadat de modal zichtbaar wordt. De bron beschrijft dit niet specifiek voor modals.

Doe deze test op de pagina waar de modal opent, in een gewoon browservenster. Werk op volgorde en noteer bij elke stap wat je ziet.

1. Open de modal zoals een bezoeker. Gebruik de echte knop of trigger, niet een tijdelijke link. Noteer of de modal vanzelf opent (bijvoorbeeld na enkele seconden) of na een klik.
2. Zet de muis weg en gebruik alleen het toetsenbord. Druk op Tab. Landt de focus binnen de modal of ergens achter de overlay op de pagina? Druk door tot je de sluitknop bereikt of tot je merkt dat dat niet lukt.
3. Test Escape. Druk op Escape terwijl de modal open is. Sluit hij? Dat is geen vervanging van een bereikbare sluitknop, maar het is een bruikbare aanvullende uitweg.
4. Verklein de viewport. Maak het browservenster smal en laag, of gebruik de apparaatmodus van de browser. Controleer of de sluitknop volledig zichtbaar blijft zonder dat je de pagina erachter moet scrollen. Probeer ook liggende stand op een telefoon.
5. Controleer waar de focus terechtkomt na sluiten. Na het sluiten hoort de focus terug te keren naar het element dat de modal opende, zodat een toetsenbordgebruiker niet bovenaan de pagina opnieuw begint.

Controleer ook of de modal een overlay heeft die klikken op de achterliggende pagina tegenhoudt: dan moet de sluitknop zelf ook echt klikbaar zijn en niet bedekt worden door een ander laagje.

Gebruik de tabel om te bepalen hoe je verder gaat. De linkerkolom is wat je tijdens de test zag.

Een eenvoudige vuistregel: lukt het sluiten met muis en Tab, maar alleen Escape of focusherstel ontbreekt, dan is het een verbetering. Lukt het sluiten met het toetsenbord helemaal niet, behandel het dan als een blokkerend probleem.

Ben je niet zeker welk onderdeel de modal levert (thema, plugin of een extern script), vraag dan eerst aan de beheerder van de site wie de modal toevoegde. Probeer de modal niet te verwijderen of te herschrijven zonder te weten welke andere functies erop leunen.

Stel dat je een fictieve dienstenwebsite beheert. Op de contactpagina opent na een klik op 'Offerte aanvragen' een modal met een formulier. Jij test volgens bovenstaande stappen en noteert dit:

• Invoer: pagina contact, trigger 'Offerte aanvragen', browser op volledig scherm en daarna op smalle viewport.
• Stap 2: na vier keer Tab bereikt de focus een link op de pagina achter de modal, niet de sluitknop.
• Stap 3: Escape sluit de modal niet.
• Stap 4: op smalle viewport valt de sluitknop rechtsboven buiten beeld.
• Stap 5: niet te beoordelen, want sluiten lukte alleen met de muis.

Je geeft dit door als een korte overdracht: welke pagina, welke trigger, welke stappen, wat je verwachtte (sluitknop bereikbaar met Tab, Escape sluit, focus keert terug naar 'Offerte aanvragen') en wat je zag. Voeg een schermafbeelding toe van de smalle viewport.

Na de aanpassing herhaal je dezelfde vijf stappen en vergelijk je met je eerste notities. Daar zit de kracht van de procedure: je ontwikkelaar kan het resultaat zelf nabootsen, en jij toetst het opnieuw zonder discussie over wat je 'voelt'. Er zijn in dit voorbeeld bewust geen cijfers over effect of herstel opgenomen: het gaat om gedrag dat je kunt waarnemen, niet om een belofte.

Een herstel is pas afgerond als je opnieuw hebt getest in omstandigheden die lijken op die van je bezoekers. Doe minimaal dit:

• Herhaal stap 1 tot 5 op desktop met toetsenbord.
• Test op een echte telefoon, niet alleen in de apparaatmodus van de browser.
• Test de modal opnieuw nadat je een nieuwe versie van het thema of de plugin installeert, want updates kunnen gedrag terugdraaien.
• Controleer of de modal de laadsnelheid van de pagina verslechtert: laad de pagina meerdere keren met en zonder modal-script, met dezelfde browser en netwerkomstandigheden, en vergelijk de meetwaarden in de ontwikkelaarstools van je browser.

Voor die laatste controle verwijst web.dev naar kernonderwerpen zoals renderblokkering en het kritieke renderpad (https://web.dev/learn/performance). Een modal die zwaar script of grote afbeeldingen vroeg inlaadt, kan het begin van de pagina vertragen. Of dat op jouw site een merkbaar effect heeft, onderzoek je met eigen metingen; een algemene tijdswinst of rankingeffect kunnen we niet voorspellen.

De grenzen van deze procedure: je test met één browser, één apparaat en je eigen invoer. Een schermlezer geeft nog andere signalen en vraagt een aparte controle. Wil je zeker weten dat de modal bruikbaar is voor mensen die hulpmiddelen gebruiken, laat dan een specialist testen met de hulpmiddelen die jouw doelgroep gebruikt.

Zet de vijf stappen als vaste check in je releaseproces: bij elke nieuwe modal, nieuwe campagnepagina of themawijziging. Schrijf op wie de modal beheert, waar de code vandaan komt en welke browsers je test. Dan hoef je bij een klacht niet opnieuw te beginnen.

Beperk het aantal modals tot wat een bezoeker echt nodig heeft. Elke extra modal is een extra plek waar het sluiten kan misgaan, en elke plek vraagt een eigen test.

Wil je ook een algemeen beeld van de zichtbare signalen van je website, bekijk ze dan via Marketing Scan. Een publieke scan meet wat van buitenaf zichtbaar is en bewijst niet dat een specifiek toetsenbordgedrag of focusherstel correct werkt; die controle blijft handwerk.