Responsive webdesign: een praktische handleiding
Responsive ontwerp betekent één site die op elke breedte werkt, niet een aparte mobiele versie. In de praktijk zijn de meeste sites op papier responsive en op specifieke plekken kapot: een tabel die horizontaal scrollen afdwingt, een navigatie die een derde van het scherm opslokt, een formulier dat op iOS onvoorspelbaar inzoomt.
Deze gids behandelt hoe je het aanpakt, waar de echte fouten zitten, en hoe je erop test.
Ontwerp vanaf de smalle kant#
Smal beginnen dwingt de prioriteitskeuzes af. Op 320 pixels is er ruimte voor één ding tegelijk, dus moet je bepalen wat dat ene ding is; een ontwerp daarna verbreden is vooral een kwestie van meer lucht geven.
Andersom werken — ontwerpen op 1440 en dan dingen weghalen — levert mobiele opmaak op die het bureaublad is met stukken verborgen, en zo belandt belangrijke content op display:none op het apparaat dat de meeste bezoekers gebruiken.
- Begin opmaak bij 320–360 px, de smalste echte apparaten die algemeen in gebruik zijn.
- Verberg op mobiel nooit content die een mobiele bezoeker nodig heeft; verplaats of vouw haar in.
- Laat content de breekpunten bepalen — zet er een waar de opmaak breekt, niet bij apparaatnamen.
- Test met de tekstgrootte van de browser op 200 %: dat is een veelgebruikte toegankelijkheidsinstelling en breekt meer opmaak dan welke telefoon ook.
Breekpunten met apparaatnamen verouderen slecht. «Tablet» heeft in tien jaar zes verschillende breedtes betekend; «het punt waarop het kaartenraster lelijk wordt» verandert niet.
De elementen die echt breken#
Een handvol componenten verklaart de meeste responsive-fouten, en ze zijn voorspelbaar genoeg om bewust te controleren.
| Element | Fout | Oplossing |
|---|---|---|
| Tabellen | Horizontaal scrollen van de hele pagina | Scrollcontainer, of herstapelen als kaarten met gegevenslabels |
| Lange woorden of URL's | De pagina scrolt zijwaarts | overflow-wrap en min-width:0 op flex- en grid-kinderen |
| Afbeeldingen | Lopen over of verschuiven de opmaak | max-width:100 %, expliciete width- en height-attributen |
| Navigatie | Neemt een derde van het scherm in | Inklappen, of hoofditems naar een balk onderaan |
| Formulieren | iOS zoomt in en zoomt niet meer uit | Lettergrootte minstens 16 px op invoervelden |
| Vaste elementen | Bedekken de content waaraan ze verankerd zijn | Ze meerekenen in scroll-padding en de padding van de body |
| Modale vensters | Zijn op een klein scherm niet te sluiten | Schermvullend op mobiel met een zichtbare sluitknop |
Afbeeldingen en media#
Afbeeldingen zijn meestal het zwaarste onderdeel van een pagina en de meest voorkomende bron van verschuivende opmaak. Drie attributen lossen het meeste op en kosten niets.
- Stel altijd de width- en height-attributen in, zodat de browser de ruimte reserveert voordat het bestand binnenkomt.
- Serveer moderne formaten — WebP of AVIF — met een terugval waar die nog nodig is.
- Gebruik srcset en sizes zodat een telefoon een bestand op telefoonformaat downloadt, geen koptafbeelding van 2000 px.
- Laad afbeeldingen onder de vouw uitgesteld, en nooit de grootste zichtbare: dat is je LCP-element.
- Geef de hoofdafbeelding fetchpriority="high" zodat ze niet achter decoratieve bestanden in de wachtrij belandt.
- Stel bij achtergrondafbeeldingen een beeldverhouding in zodat de container vóór het laden niet inklapt.
Aanraking, niet alleen breedte#
Responsive gaat niet alleen over opmaak. Een smal venster betekent meestal een vinger in plaats van een muis, en aanraakinvoer heeft andere eisen die mediaquery's op breedte alleen niet dekken.
- Aanraakdoelen van minstens 44 × 44 px met ruimte ertussen; naast elkaar liggende links van 30 px worden voortdurend misgetikt.
- Niets belangrijks achter hover — een menu dat alleen op hover werkt is met aanraking onbereikbaar.
- Gebruik pointer:coarse-mediaquery's om hover-effecten te verwijderen die na een tik blijven hangen.
- Houd primaire acties binnen duimbereik op hoge telefoons; de rechterbovenhoek is met één hand het lastigst.
- Respecteer prefers-reduced-motion: parallax en grote overgangen veroorzaken bij sommige mensen echt ongemak.
Veelgestelde vragen
Hoeveel breekpunten heb ik nodig?
Meestal drie tot vijf, en ze horen uit je content te komen in plaats van uit een apparatenlijst. Zet er een waar de opmaak er bij het verbreden van het venster verkeerd uit begint te zien, niet omdat een bepaalde telefoon bestaat. Sites met een dozijn breekpunten compenseren vrijwel altijd een opmaak die van meet af aan niet vloeiend was.
Is een aparte mobiele site ooit juist?
Zelden. Het betekent twee codebases, twee sets URL's, twee deployments en een canonieke relatie om te onderhouden, en het eindigt meestal met een van de twee die stilletjes achterop raakt. De gevallen waarin het nog gebeurt zijn oude systemen die niet responsive te maken zijn, en zelfs dan is het een noodgreep en geen plan.
Hoe test ik responsive ontwerp goed?
Apparaatemulatie in de browser vindt opmaakproblemen maar geen aanraak-, netwerk- of platformgedrag. Test op minstens één echte Android uit de lagere middenklasse en één iPhone, op mobiele data in plaats van kantoorwifi. Herhaal daarna de belangrijkste pagina's met de tekstgrootte van de browser op 200 %, want daar valt de meeste opmaak echt uit elkaar.
En gegevenstabellen op telefoons?
Twee werkbare opties: de tabel in een horizontaal scrollende container zetten met een zichtbare aanwijzing en een vastgezette eerste kolom, of elke rij herstapelen als een kaart waarin elke cel zijn eigen kolomlabel draagt. De scrollcontainer houdt vergelijken mogelijk; de kaartenstapel leest makkelijker. Kies op basis van of bezoekers rijen vergelijken of ze één voor één lezen.
responsive webdesignmobielvriendelijke websitebreekpuntenmobile first ontwerpresponsive afbeeldingenaanraakdoelen
