Topics

Veelvoorkomend accessibility-probleem bij clamp() spacing en oplossingen

  • column

Voor spacing-aanpassingen wordt clamp() tegenwoordig vaak gebruikt om de minimale tot maximale waarden variabel in te stellen.

Hoewel dit erg handig is voor responsive design, is er een subtiele valkuil wanneer je accessibility-zoom (vergroting) in aanmerking neemt.

Veelvoorkomende voorbeelden van clamp()-instelling

Als je spacing aanpast met clamp(), schrijf je dit meestal als volgt:

: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)
  );
}

De gedetailleerde uitleg laat ik achterwege, maar:

  • Op smartphone is het formaat --spacing-lg-min
  • Op desktop is het formaat --spacing-lg-max
  • Ondertussen schaalt het soepel en flexibel mee

en dat is een erg handig patroon.

Wat zijn valkuilen in accessibility?

Het probleem doet zich voor wanneer u probeert te voldoen aan WCAG 2.0 Succeskriterium 1.4.4 'Tekstvergroting'.

Dit criterium was oorspronkelijk bedoeld voordat smartphones algemeen waren – namelijk 'inhoud moet leesbaar blijven bij 200% vergroting op een pc' – maar dezelfde voorwaarde geldt ook voor smartphonebrowsers.

Wanneer u een smartphone werkelijk tot 200% vergroot, ontstaan vaak deze problemen.

  1. Door tekstvergroting (zoom) worden niet alleen tekst, maar ook rem-gebaseerde witruimte tegelijk vergroot.
  2. Hierdoor wordt de witruimte rond de inhoud buitensporig groot.
  3. Als gevolg daarvan wordt het inhoudsweergavegebied extreem smal, wat leidt tot layoutproblemen en slechtere leesbaarheid.

* In de praktijk is echter opvallend dat veel overheidswebsites in het buitenland, waar WCAG-naleving verplicht is, hier niet veel aan hebben gedaan. Het is waarschijnlijk een kwestie van kosteneffectiviteit, en omdat er in werkelijkheid nauwelijks vraag naar 200%-zoom op smartphones is. Misschien wordt dit op uitvoeringsniveau beschouwd als 'niet nodig om te implementeren, omdat het geen groot probleem veroorzaakt'.

Hoe los je dit probleem op?

Het is belangrijk om viewport-gebaseerde eenheden te gebruiken, zoals vw, in plaats van rem, die worden beïnvloed door tekstvergroting, en ervoor te zorgen dat witruimte niet onnodig groter wordt bij inzoomen.

Maar als je alleen vw gebruikt, kun je niet profiteren van het voordeel van clamp() dat je minimale en maximale waarden kunt controleren.

Dit is waar de min() functie van pas komt!

min() selecteert de kleinste waarde uit de doorgegeven waarden. Met deze eigenschap kunnen we de waarden die in normale en vergrote modus worden toegepast, omwisselen.

Zo schrijf je het op.

--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 bij 375 CSS px, wordt de eerste waarde van min --spacing-lg-min, wat 24px is, omgezet naar 6.4vw.

De minimumwaarde van clamp() is 1.5rem = 24px, maar bij 200% vergroting wordt dit 48px, dus 6.4vw aan de linkerkant is kleiner en wordt toegepast.

Met andere woorden:

  • Normaal (100% weergave):
    • De waarde van clamp() wordt kleiner dan de vw-gebaseerde waarde.
    • min() selecteert de kleinste waarde, dus clamp() werkt en wordt weergegeven op basis van de schermgrootte.
  • Bij vergroting (200% weergave):
    • De rem in clamp() wordt groter door de vergroting, en de vw-gebaseerde waarde wordt kleiner.
    • De vw-gebaseerde waarde wordt toegepast, waardoor de marge in een vaste verhouding tot de schermgrootte blijft en overmatige vergroting wordt voorkomen.

Op deze manier bereiken we zowel "responsieve gebruiksvriendelijkheid" als "aandacht voor accessibility"!

* Overigens behouden marges op desktopweergave meestal het ontwerpevenwicht beter wanneer ze samen met de rest worden vergroot. Daarom passen we --clamp-viewport-min alleen toe op smartphones.

Werkelijk gedrag vergelijken

Boven: alleen clamp, onder: min + clamp.

Het verschil wordt duidelijk zichtbaar wanneer u het op een smartphone tot 200% vergroot.

* Op iOS Safari kunt u inzoomen via het pictogram links van de adresbalk, op Android Chrome via het pictogram rechtsboven.

Samenvatting

  • clamp() is handig voor responsieve witruimte-aanpassingen
  • Echter, bij inzoomen wordt ook de witruimte vergroot, wat kan leiden tot layoutbreuk
  • Door min() te combineren, wordt normale flexibiliteit met beheerde vergroting mogelijk

Als u WCAG-compliance nastreeft, is het goed om deze implementatie op te nemen. De aanpak van "200% inzoomen op mobiel" is nog zeldzaam, maar handhaaft de leesbaarheid zonder accessibility-risico's.

Voor fijnere aanpassingen buiten witruimte kunt u ook mediaquery's met smalle breakpoints gebruiken.

@media (max-width: 239px) {
  /* 拡大時に適用したいCSS */
}

Bijvoorbeeld: wanneer een scherm van 375px breed 200% wordt vergroot, berekent de browser de viewportbreedte als "half (ongeveer 188px)". Daardoor kunt u deze smalle omstandigheid aanpassen.

* De waarde 239px is een voorbeeld; stel deze in met ruimte voor toekomstige schermgroei, zonder normale weergave te beïnvloeden.

Door "clamp() + min()" met "smalle breakpoint mediaquery's" te combineren, bereikt u flexibeler en betrouwbaarder accessibility-ondersteuning!

Auteur van dit artikel

Vanuit DTP de wereld van het web in gestapt en merkte al snel dat hij markering, frontend, directie en accessibility allemaal beheerst — een echte 'meester van techniek'. Sinds de oprichting van Liberogic een multitalent en inmiddels een levend naslagwerk in het bedrijf. Tegenwoordig is hij geïnteresseerd in de vraag "Kunnen we accessibility-implementatie meer aan AI overlaten?" en experimenteert hij graag met efficiëntie via prompts. Zowel technisch als mentaal nog volop in ontwikkeling.

Futa

IAAP-gecertificeerd webtoegankelijkheidsspecialist (WAS) / Opmaakingenieur / Frontend-ingenieur / Webdirecteur

Artikelen van deze medewerker bekijken

Ons sterke punt is ons betrouwbare teamstructuur en snelle responsiviteit

Bij Liberogic worden ervaren teamleden actief ingezet voor projectvoering, wat door klanten zeer wordt gewaardeerd.
We wijzen vakbekwaam projectmanagers en directors aan en streven ernaar projecten soepel te laten verlopen. We voorkomen onnodig kostenverhogingen door volledig inzet te vermijden en wijzen middelen toe waar ze het meest geschikt zijn. Onze snelheid bij taakanalyse en bij het opmaken en indienen van offertes is goed bekend.

* Wij voeren niet actief SES-achtige permanente werkzaamheden uit, dus graag van tevoren dank voor uw begrip.

U kunt vrijwel alle grote projectmanagementtools en chattoolsgebruiken, zoals Slack, Teams, Redmine, Backlog, Asana, Jira, Notion, Google Workspace, Zoom en Webex.

Heeft u hulp nodig met web accessibility compliance?

Casestudies