Een sticky balk bedekt je contactformulier

Een vaste balk blijft op dezelfde plek van het scherm staan terwijl de pagina eronder scrolt. Hij neemt dus altijd een deel van het zichtbare vlak in, ook op het moment dat iemand een veld invult. Problemen ontstaan meestal als drie dingen samenkomen: een laag scherm, een balk die hoger is dan je dacht en een formulier dat net achter die balk valt.

Let op deze veroorzakers: de adresbalk of het schermtoetsenbord die de beschikbare hoogte verkleinen, tekst die bij vergroting over meer regels loopt waardoor de balk hoger wordt, en een balk die pas laat verschijnt en de pagina verschuift. Dat laatste raakt ook de prestaties. MDN over webperformance beschrijft performance niet alleen als laadtijd, maar ook als hoe soepel de inhoud zich gedraagt tijdens interactie. Die bron gaat niet specifiek over sticky balken. Het is wel een redelijke eigen controle om te kijken of een balk die na het laden inschuift het formulier bedekt of verplaatst.

Doe de test op de pagina waar het formulier echt staat, niet op de startpagina. Werk deze stappen af en noteer per stap geslaagd of mislukt.

1. Meet de hoogte van de balk bij normale tekst. De ontwikkeltools van je browser tonen die waarde.
2. Maak het browservenster bewust laag en smal, en kies zelf een vaste testhoogte die je in je notitie vermeldt, zodat een collega dezelfde test kan herhalen.
3. Draai een echte telefoon naar liggende stand en open het formulier.
4. Vergroot de tekst via de browserzoom en via de tekstgrootte-instelling van het toestel. Meet de balk opnieuw, want die kan hoger worden.
5. Tab met het toetsenbord door elk veld. Controleer of het veld met focus volledig zichtbaar blijft en niet achter de balk verdwijnt.
6. Verstuur het formulier leeg om foutmeldingen op te roepen. Zijn die meldingen en de verzendknop nog bereikbaar?
7. Laat op een echt toestel het schermtoetsenbord openen en kijk wat er van veld, balk en knop overblijft.

Emulatie in de ontwikkeltools helpt bij stap 1 tot 3, maar vervangt geen test op een echt toestel.

Een balk die je niet kunt sluiten, kan een formulier voor sommige bezoekers onbruikbaar maken. Behandel de sluitknop daarom als volwaardig onderdeel van het ontwerp. De toegankelijkheidstutorials van W3C bundelen praktische richtlijnen en vermelden per pagina welke WCAG-succescriteria en technieken gebruikt worden. De tutorials gaan niet specifiek over sticky balken. Gebruik ze als algemene referentie en neem de onderstaande controlelijst als eigen redactionele suggestie, niet als norm.

Controleer minstens het volgende:

• De sluitknop is een echt bedienbaar element en geen alleen visueel icoon.
• Hij is met het toetsenbord bereikbaar en heeft een duidelijke naam voor een schermlezer.
• Hij is ook zichtbaar bij vergrote tekst en niet buiten het scherm geduwd.
• Het raakvlak is groot genoeg om op een telefoon te raken.
• Na het sluiten komt de focus op een logische plek terug, niet bovenaan de pagina.
• Het sluiten werkt zonder muis en zonder hover.

Of je de keuze van de bezoeker onthoudt, is een aparte beslissing. Spreek met je ontwikkelaar af wat er gebeurt bij de volgende pagina en leg dat vast. Een test van jezelf bewijst geen volledige naleving.

Stel je een contactpagina voor met een vaste balk onderaan die een actie aankondigt. De invoer voor je testnotitie, als voorbeeld bedacht: balkhoogte bij normale tekst 72 px, bij sterk vergrote tekst 160 px, testvenster 400 px hoog. De verzendknop staat onderaan het formulier.

Verwachte technische controles: bij 400 px hoogte en vergrote tekst blijft de verzendknop zonder extra scrollen buiten de balk te bereiken. Het laatste veld met focus verdwijnt niet achter de balk. Een lege verzending toont de foutmeldingen volledig. De sluitknop is bereikbaar met Tab en heeft een herkenbare naam. Zie je bij deze controles overlap, dan kies je in het beslisblad een passende aanpak, bijvoorbeeld de balk op deze pagina niet vastzetten.

Noteer ook de omstandigheden: browser, toestel, tekstgrootte en pagina. Zonder die gegevens kan niemand je bevinding later herhalen. Dit scenario toont alleen hoe je invoer en controle beschrijft, en voorspelt geen uitkomst voor jouw site.

Na de aanpassing herhaal je de volledige testopstelling, niet alleen de stap die faalde. Een correctie voor één scherm kan elders overlap veroorzaken. Controleer ook of de balk nog laat of schokkerig verschijnt. De cursus Learn Performance van web.dev behandelt onder meer hoe resources en scripts het laden beïnvloeden. Die cursus is algemeen over laadprestaties en behandelt geen balken specifiek. Laat zo nodig meten of het script van de balk het eerste renderen vertraagt in jouw eigen opstelling.

Voor de overdracht aan je ontwikkelaar of bureau schrijf je een korte notitie met:

• de pagina's waarop de balk wel en niet mag staan;
• de testhoogtes, tekstgroottes en toestellen die je gebruikte;
• de gekozen oplossing en wie die heeft doorgevoerd;
• wat er nog niet getest is, bijvoorbeeld een schermlezer.

Wil je ook bekijken welke publieke signalen je website uitstuurt, dan kun je starten via Marketing Scan. Een publieke scan meet zichtbare signalen en bewijst geen volledige technische implementatie. De overlapcontrole op echte toestellen blijft dus je eigen werk.