Voor het instellen van witruimte wordt tegenwoordig vaak een implementatie gebruikt waarbij clamp() een variabele waarde geeft tussen een minimum- en maximumwaarde.
Dit is erg handig voor responsive design, maar houd er rekening mee dat het vergroten van de weergave (zoomen) voor toegankelijkheid een valkuil kan opleveren.
Veelvoorkomende clamp()-voorbeelden
Bij het instellen van witruimte met clamp() wordt vaak het volgende geschreven.
:root {
--clamp-base: 16;
--clamp-viewport-min: 375;
--clamp-viewport-max: 1440;
--spacing-lg-min: 24;
--spacing-lg-max: 48;
--spacing-lg-slope: calc(
(var(--spacing-lg-max) - var(--spacing-lg-min)) / (var(--clamp-viewport-max) - var(--clamp-viewport-min))
);
--spacing-lg-intersection: calc(
(var(--spacing-lg-max) - var(--clamp-viewport-max) * var(--spacing-lg-slope)) / var(--clamp-base)
);
--spacing-lg: clamp(
calc(var(--spacing-lg-min) / var(--clamp-base) * 1rem),
calc(var(--spacing-lg-intersection) * 1rem + 100 * var(--spacing-lg-slope) * 1vw),
calc(var(--spacing-lg-max) / var(--clamp-base) * 1rem)
);
}
We laten de details hier achterwege, maar
- Op smartphones: de grootte van
--spacing-lg-min - Op pc: de grootte van
--spacing-lg-max - en blijft variabel en schaalt soepel
en dat is een patroon dat erg handig in het gebruik is.
Waar moet je op letten bij toegankelijkheid?
Het probleem doet zich voor wanneer je probeert te voldoen aan WCAG 2.0 succescriterium 1.4.4 "Tekstgrootte aanpassen".
Dit criterium is oorspronkelijk opgesteld voor de tijd dat smartphones nog niet gangbaar waren, met als doel dat inhoud leesbaar blijft bij 200% vergroting op een pc. Toch geldt dezelfde eis ook voor browsers op smartphones.
Wanneer je op een smartphone tot 200% inzoomt, zie je in de praktijk vaak het volgende.
- Bij tekstvergroting (zoom) worden ook de marges mee vergroot die op
rem-eenheden zijn gebaseerd. - Hierdoor worden de marges rond de eigenlijke inhoud onnodig groot.
- Het gevolg is dat het zichtbare inhoudsgebied extreem smal wordt, waardoor de lay-out verschuift en de pagina slecht leesbaar is.
Note: In de praktijk zien we dat ook overheidssites in landen waar WCAG-conformiteit verplicht is, hier vaak weinig aandacht aan besteden. Waarschijnlijk speelt de kosten-batenafweging een rol, en omdat zoomen tot 200% op een smartphone in de praktijk weinig wordt gebruikt, wordt dit op operationeel niveau mogelijk als "geen groot probleem" beschouwd.
Hoe los je dit op?
Het is belangrijk om viewportgebaseerde eenheden zoals vw te gebruiken in plaats van rem, omdat die niet beïnvloed worden door tekstvergroting, en de witruimte bij zoomen niet onnodig groot te maken.
Maar als je alleen vw gebruikt, benut je het voordeel van clamp() niet, namelijk dat je de minimum- en maximumwaarde kunt bepalen.
Hier komt de functie min() van pas!
min() neemt van de opgegeven waarden de kleinste waarde over. Hiervan maken we gebruik om de waarde die wordt toegepast bij normale weergave en bij vergroting te wisselen.
De schrijfwijze ziet er zo uit.
--spacing-lg: min(
calc(var(--spacing-lg-min) / var(--clamp-viewport-min) * 100vw),
clamp(
calc(var(--spacing-lg-min) / var(--clamp-base) * 1rem),
calc(var(--spacing-lg-intersection) * 1rem + 100 * var(--spacing-lg-slope) * 1vw),
calc(var(--spacing-lg-max) / var(--clamp-base) * 1rem)
)
);
Wanneer dit wordt weergegeven op 375 CSS px, is de eerste min-waarde de waarde van --spacing-lg-min, namelijk 24px, omgerekend naar 6.4vw.
De minimumwaarde van clamp() is 1.5rem = 24px, maar bij 200% vergroting wordt dat 48px. Daarom is de waarde links, 6.4vw, kleiner en wordt die toegepast.
Met andere woorden:
- Normale weergave (100%):
- De waarde van
clamp()wordt kleiner dan de waarde op basis vanvw. min()kiest de kleinere waarde, waardoorclamp()werkt en de weergave zich aanpast aan de schermbreedte.
- De waarde van
- Bij vergroting (weergave op 200%):
- Bij vergroting wordt de
rem-waarde inclamp()groter, waardoor de waarde op basis vanvwkleiner wordt. - Doordat de waarde op basis van
vwwordt toegepast en de marges een vaste verhouding tot de schermbreedte houden, wordt overmatige vergroting voorkomen.
- Bij vergroting wordt de
Zo kunnen "responsieve gebruiksvriendelijkheid" en "aandacht voor toegankelijkheid" hand in hand gaan!
Opmerking: Op pc blijft het ontwerp vaak beter in balans wanneer ook de marges mee vergroten. Daarom is --clamp-viewport-min als basis gebruikt en wordt deze alleen op smartphones toegepast.
Vergelijking van het werkelijke gedrag
Boven: alleen clamp, onder: min + clamp.
Bij 200% vergroting op een smartphone zijn de verschillen duidelijk zichtbaar.
Opmerking: In iOS Safari kunt u inzoomen via het pictogram links in de adresbalk, en in Android Chrome via het pictogram rechtsboven.
Conclusie
- clamp() is handig voor responsieve aanpassing van witruimte
- Bij inzoomen wordt de witruimte echter ook vergroot, wat kan leiden tot een verstoorde lay-out
- Door clamp() te combineren met min() ontstaat een evenwichtige oplossing: variabel bij de standaardweergave en beheerst bij vergroting
Als u WCAG-conformiteit belangrijk vindt, is het verstandig om deze aanpak te overwegen. Het is nog niet gebruikelijk om rekening te houden met 200% vergroting op smartphones, maar zo blijft de weergave in het dagelijks gebruik prettig leesbaar en worden de risico's voor toegankelijkheid beperkt.
Als u andere fijnafstemming dan witruimte wilt doorvoeren, kunt u ook een mediaquery met een smal breekpunt gebruiken.
@media (max-width: 239px) {
/* 拡大時に適用したいCSS */
}
Wanneer een scherm van 375px breed tot 200% wordt vergroot, berekent de browser de viewportbreedte als de helft van de oorspronkelijke grootte (ongeveer 188px). Daardoor kan de mediaquery precies op deze smalle situatie worden afgestemd.
Opmerking: 239px is slechts een voorbeeldwaarde. Kies een waarde die ruimte laat voor toekomstige grotere schermen, maar die de standaardweergave niet beïnvloedt.
Door clamp() + min() te combineren met een mediaquery voor smalle breekpunten, bereikt u een flexibelere en betrouwbaardere toegankelijkheid!
Van DTP naar het web: al snel werkte hij aan markup, frontend, projectregie en accessibility, en beheerst hij alles. Actief bij Liberogic sinds de beginjaren en nu een levende encyclopedie binnen het bedrijf. Recentelijk verdiept hij zich, met prompts als hulpmiddel, in de vraag: "Kunnen we voor accessibility niet meer op AI leunen?" Technologie en denkwijze blijven zich ontwikkelen.
Ayumu Futamata
IAAP-gecertificeerd webaccessibility-specialist (WAS) / Markup-engineer / Frontend-engineer / Webdirecteur