Een chatwidget blokkeert je mobiele menu

Een botsing tussen widget en menu heeft meestal één van vier oorzaken. Zoek eerst welke het is voordat je iets aanpast.

• Gelaagdheid: de widget heeft een hogere stapelvolgorde (z-index) dan je menu en ligt dus over de menu-items, vaak precies bij het contactitem onderaan.
• Schermruimte: de chatknop of het geopende chatvenster bedekt het sluitkruisje of de onderste menulinks.
• Scrollvergrendeling: het menu blokkeert het scrollen van de pagina, de widget doet dat ook, en samen laten ze de pagina vastlopen.
• Scripts: de widget laadt zwaar of laat, waardoor een tik op het menu even niets doet.

Die laatste oorzaak kun je vergelijken met en zonder widget. MDN noemt 50 tot 200 milliseconden als richtlijn voor reageren op gebruikersinvoer, zie de uitleg over webprestaties van MDN. Dat is een richtlijn, geen harde grens voor jouw site. Gebruik het als referentie om te beoordelen of een vertraagd menu aan de widget ligt of aan iets anders.

Test op een echt toestel als dat kan en niet alleen in een verkleinde browser. Op een echte telefoon spelen adresbalk, schermtoetsenbord en schermrand mee. Noteer vooraf het toestel, de browser en of je in staand of liggend formaat test.

1. Open de pagina in een privévenster, zodat je geen cache of opgeslagen chatgeschiedenis hebt.
2. Wacht tot de chatknop zichtbaar is en tik dan meteen op het menu. Doe dit ook als de widget nog laadt.
3. Open het menu volledig en controleer of elk item zichtbaar en tikbaar is, ook het laatste.
4. Sluit het menu met het sluitkruisje en met een tik naast het menu, als jouw ontwerp dat toelaat.
5. Open nu eerst de chat en daarna het menu. Kijk welke van de twee bovenaan komt.
6. Open eerst het menu en tik dan op de chatknop. Kijk of de chat achter het menu verdwijnt of er juist doorheen steekt.
7. Draai het toestel en herhaal stap 3 en 4.
8. Scroll met open menu en met open chat. Noteer of de pagina erachter beweegt.

Schrijf bij elke stap kort op wat je zag. Zo kan iemand anders het probleem herhalen.

Een menu dat met de vinger werkt, kan nog steeds stuk zijn voor toetsenbord- en schermlezergebruikers. De toegankelijkheidstutorials van W3C leggen uit hoe je componenten inclusief opbouwt en verwijzen per pagina naar de relevante WCAG-criteria. Gebruik ze als algemene referentie en zoek zelf de pagina's op die bij jouw menu of dialoogvenster passen; ze zijn geen bewijs dat jouw implementatie voldoet. Ook deze controlelijst bewijst geen volledige WCAG-conformiteit.

Koppel een toetsenbord aan je telefoon of tablet, of test op desktop met een smal venster, en controleer:

• Gaat de focus bij het openen van het menu naar binnen en blijft hij daar tot je het sluit?
• Komt de focus na het sluiten terug op de menuknop?
• Kun je met Tab de chatknop bereiken terwijl het menu open is, terwijl die visueel bedekt zou moeten zijn?
• Is bij elke knop zichtbaar dat hij focus heeft?
• Werkt Escape om het menu of de chat te sluiten?

Een focus die achter een overlay blijft rondlopen, wijst vaak op een widget die buiten de normale pagina-opbouw wordt ingeladen.

Als het menu traag of onbetrouwbaar reageert, test dan de widget als losse variabele. De cursus Learn Performance van web.dev beschrijft hoe render-blokkerende en parser-blokkerende resources het eerste beeld van een pagina beïnvloeden en hoe je laden van niet-kritieke resources kunt uitstellen. Pas dat denkkader hier toe op het chatscript.

1. Open de ontwikkelaarstools van je browser en bekijk het netwerkoverzicht bij het laden van de pagina. Zoek het domein van de chatleverancier en noteer wanneer het begint en eindigt.
2. Laad dezelfde pagina met dat script geblokkeerd, via de blokkeermogelijkheden van je browser of liefst via een testomgeving zonder de widget. Doe dit niet op de live site met echte bezoekers.
3. Vergelijk in beide gevallen hoe snel het menu reageert op de eerste tik.
4. Controleer in de instellingen van de chatleverancier of de widget pas na een interactie of vertraging kan laden. Wat daar precies mogelijk is, verschilt per leverancier. Lees dat na in de documentatie van jouw tool.

Blijft het menu ook zonder widget traag, dan ligt de oorzaak elders en is de chat een onschuldige verdachte.

Gebruik dit blad om van waarneming naar actie te gaan.

Fictief scenario (alleen invoer en controles): een kmo-site toont op een telefoon van 360 pixels breed een chatknop rechtsonder. Het menu heeft als laatste item Contact. Invoer: toestel, browser, stap 5 en 6 van het stappenplan. Te controleren: ligt de chatknop op hetzelfde punt als Contact, blijft de knop tikbaar bij open menu, en keert de focus na sluiten terug op de menuknop. De uitkomst weet je pas na de test.

Na elke aanpassing herhaal je het volledige stappenplan, niet alleen de stap die faalde. Een gewijzigde stapelvolgorde kan de focus of scrollvergrendeling beïnvloeden. Test ook na een update van de chatwidget, want de leverancier kan zijn script wijzigen zonder dat jij iets aanpast.

Maak voor een collega of externe ontwikkelaar een overdracht van vijf regels: toestel en browser, de stap waar het misging, wat je zag, wat je verwachtte en welke oorzaak je vermoedt. Voeg een korte schermopname toe als dat kan.

Let op de grenzen: deze procedure toont zichtbaar gedrag op de toestellen die jij test. Ze bewijst niet dat elke combinatie van toestel en browser werkt. Wil je weten welke publieke signalen je site nu al toont, bekijk dan je eigen website via Marketing Scan. Daarmee krijg je een eerste beeld, geen volledige technische controle van menu, focus en scripts.