Mobielvriendelijke website: waar moet uw site aan voldoen?

De basis is een responsief ontwerp: één URL en één codebase die de layout aanpast aan de schermbreedte. Kolommen stapelen, menu's klappen in, afbeeldingen schalen mee. Technisch begint dat bij de viewport-meta in de pagina. Ontbreekt die, dan toont de telefoon een uitgezoomde desktopsite waarop tekst onleesbaar klein is en knoppen onbereikbaar worden.

Daarbovenop komen de details die het verschil maken tussen werkbaar en prettig. Tekst die groot genoeg is om zonder zoomen te lezen (in de praktijk vaak minstens 16 CSS-pixels). Knoppen en links met voldoende ruimte eromheen. Formulieren die het juiste toetsenbord per veld openen, bijvoorbeeld cijfers bij een telefoonnummer. Geen content die breder is dan het scherm, zodat u niet horizontaal hoeft te scrollen.

Mobielvriendelijkheid is geen aparte 'mobiele site' meer. Een subdomein zoals m.voorbeeld.nl betekent dubbel onderhoud, doorverwijsrisico's en het gevaar dat content op telefoon afwijkt van desktop. Eén responsieve site is al jaren de standaard, en dat is precies wat zoekmachines en bezoekers verwachten.

Google gebruikt mobile-first indexing: de crawler bekijkt en indexeert primair de mobiele versie van uw pagina's. Content die op telefoon verborgen of weggelaten is, telt dus niet mee voor vindbaarheid. Een site die op desktop compleet oogt maar op mobiel uitgekleed is, concurreert in de zoekresultaten met zijn zwakste versie.

Snelheid weegt op mobiel zwaarder, omdat verbindingen wisselvalliger zijn en toestellen minder rekenkracht hebben. De Core Web Vitals worden gemeten bij echte bezoekers, en op de meeste sites zijn dat er meer op telefoon dan op desktop. Mobielvriendelijkheid en laadsnelheid zijn daarmee twee kanten van dezelfde opgave: wat traag of onbruikbaar is op een klein scherm, raakt zowel conversie als ranking.

Praktisch betekent dit: publiceer op mobiel dezelfde kerncontent, dezelfde metadata en dezelfde links als op desktop. Verberg geen belangrijke tekst achter tabs die alleen op telefoon dichtklappen zonder toegankelijke bediening. Test of uw productpagina's, checkout en contactformulier op een echt toestel werken, niet alleen in de desktop-emulator van uw browser.

De problemen die scans het vaakst vinden zijn zelden spectaculair, maar wel storend. Tap-targets die te dicht op elkaar staan, zodat u het verkeerde raakt: een navigatielink boven een knop, twee icoontjes tegen elkaar. Lettergroottes onder de 16 pixels die op een klein scherm onleesbaar worden. Tabellen of brede afbeeldingen die de pagina laten overlopen. Pop-ups die op desktop een hoekje innemen maar op mobiel het hele scherm blokkeren zonder bereikbare sluitknop.

Voor aanraakdoelen bestaat een concrete ondergrens in de toegankelijkheidsrichtlijnen. WCAG 2.2 hanteert minimaal 24 bij 24 CSS-pixels voor een aanraakdoel; in de praktijk mikken ontwerpers op zo'n 44 tot 48 pixels voor comfortabel duimgebruik. Hier raken mobiel en digitale toegankelijkheid elkaar: wat met een duim lastig te raken is, is dat met een tremor of beperkt zicht helemaal.

Andere klassiekers: sticky headers die te veel verticale ruimte innemen, cookie-banners die de CTA bedekken, en carrousels die alleen met een swipe werken zonder knoppen. Elk van die patronen faalt zowel de mobielpijler als vaak criteria uit WCAG. Wie alleen desktop ontwerpt en daarna 'responsive maakt', bouwt die fouten bijna altijd in.

Op een telefoon is iedereen even afhankelijk van duidelijke focus, voldoende contrast en bedienbare knoppen. Zoom, spraakbesturing en schermlezers werken beter wanneer de HTML semantisch is en knoppen echte knoppen zijn, geen klikbare divs. De European Accessibility Act (zie ook de uitleg van de Rijksoverheid) dwingt voor veel e-handelsdiensten af wat goede mobiele UX al eiste: niemand mag afhaken omdat een checkout alleen met een muis of alleen op een groot scherm werkt.

Voor webshops en boekingsflows is dat geen abstracte compliance. Als uw bestelknop te klein is, uw formulierlabels ontbreken of uw foutmeldingen onduidelijk zijn, verliest u conversie bij alle bezoekers, niet alleen bij mensen met een beperking. Mobielvriendelijkheid is daarmee ook een toegankelijkheidsinvestering: u lost meetbare drempels op die de scan in beide pijlers kan signaleren.

De snelste eerste check is uw eigen telefoon, niet alleen de ontwikkelaarsweergave. Open de site op een echt toestel, liefst een ouder model met een kleiner scherm, en probeer de drie belangrijkste taken: iets vinden via het menu, een formulier invullen, een pagina lezen. Waar u zelf inzoomt, misklikt of wacht, doet uw bezoeker dat ook.

Voor een systematische controle scant WebYes binnen de pijler mobiel de meetbare punten: viewport-configuratie, leesbare lettergroottes, tap-targets en content die buiten het scherm valt. De gratis scan (bèta) loopt over maximaal zes pagina's; een betaalde full audit tot vijftien, sitemap-geleid. De bevindingen staan per pagina in het rapport. Automatische WCAG 2.2 AA-checks vallen onder de pijler toegankelijkheid, maar overlappen vaak met mobiel (contrast, labels, targetgrootte).

Het WebYes-keurmerk vraagt een gemiddelde score van minstens 80 én minstens 60 per pijler. Een sterke desktopsite met een zwakke mobielscore komt dus niet door. Los eerst de blokkades op die bezoekers direct raken, herhaal de scan, en plan daarna de fijnere verbeteringen. Zo weet u of uw site echt mobielvriendelijk is, in plaats van alleen responsive te lijken in een mockup.

Open de site op een telefoon die u niet dagelijks voor development gebruikt. Doorloop drie taken: navigatie via het menu, een formulier of checkout-stap, en het lezen van een lange pagina. Noteer waar u inzoomt, horizontaal scrollt of per ongeluk het verkeerde raakt. Die notities zijn vaak waardevoller dan een abstracte responsive-preview.

Controleer sticky headers en cookie-banners: samen mogen ze niet meer dan een derde van het viewport innemen op een klein scherm. Test of knoppen nog bereikbaar zijn wanneer de soft keyboard openstaat. Als de primaire CTA dan verdwijnt achter de balk, faalt de flow in de praktijk, ook als de CSS 'responsive' heet.

Vergelijk daarna met het WebYes-rapport. Bevindingen over tap-targets, lettergrootte en overflow moeten aansluiten bij wat u op het toestel voelde. Wijkt lab af van uw ervaring, noteer de exacte URL en herhaal de scan na een fix; de full audit dekt tot vijftien pagina's zodat diepere templates meegenomen kunnen worden.