Die Anpassung von Abständen mit clamp(), um Mindest- und Maximalwerte festzulegen, ist heutzutage eine häufig verwendete Implementierung.
Als responsive Lösung ist dies sehr praktisch, aber bei Berücksichtigung von Accessibility-Zoomfunktion gibt es einige Fallstricke.
Häufige clamp()-Beispiele
Beispielsweise wird die Abstands-Anpassung mit clamp() häufig wie folgt geschrieben:
: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)
);
}
Ich verzichte auf eine detaillierte Erklärung, aber
- auf Mobilgeräten die Größe
--spacing-lg-min - auf dem PC die Größe
--spacing-lg-max - Flexibel und sanft dehnbar dazwischen
und dadurch ein sehr benutzerfreundliches Muster, nicht wahr?
Was sind die Fallstricke bei der Barrierefreiheit?
Das Problem tritt auf, wenn Sie versuchen, den WCAG 2.0 Erfolgskriterium 1.4.4 „Textgröße ändern" umzusetzen.
Dieser Standard wurde ursprünglich mit der Absicht festgelegt, dass Inhalte auf dem PC auch bei 200-prozentiger Vergrößerung lesbar sein sollten – dies war vor der Verbreitung von Smartphones der Fall. Heute wird die gleiche Bedingung jedoch auch auf Smartphone-Browser angewendet.
Wenn man auf dem Smartphone tatsächlich bis 200% vergrößert, treten häufig solche Phänomene auf.
- Wenn Text vergrößert wird (Zoom), werden die
rem-Einheiten als Basis verwendet und auch die Abstände werden zusammen vergrößert. - Dadurch wird der Leerraum um den ursprünglichen Inhalt unverhältnismäßig groß.
- Dies führt dazu, dass der Inhaltsbereich extrem schmal wird und das Layout zusammenbricht oder unleserlich wirkt.
*Anmerkung: In der Praxis zeigt sich allerdings, dass selbst bei ausländischen Behördenseiten, bei denen WCAG-Konformität vorgeschrieben ist, die Umsetzung oft mangelhaft ausfällt. Vermutlich liegt das daran, dass das Kosten-Nutzen-Verhältnis ungünstig erscheint und dass die Anforderung, Text auf dem Smartphone auf 200% zu vergrößern, ohnehin kaum vorkommt. Möglicherweise wird die Umsetzung auf praktischer Ebene daher als nicht kritisch angesehen – „es wird kein großes Problem, wenn man es nicht umsetzt".
Wie lässt sich dieses Problem beheben?
Wichtig ist, nicht auf rem, sondern auf Viewport-basierte Einheiten wie vw zu setzen, um auch beim Zoomen nicht unnötig große Abstände zu erzeugen.
Allerdings verliert man den Vorteil der Kontrolle über Mindest- und Maximalwerte, wenn man nur vw nutzt und clamp() nicht einsetzt.
Hier kommt die min()-Funktion ins Spiel!
min() wählt den kleinsten Wert aus den übergebenen Werten aus. Mit dieser Eigenschaft können wir je nach Zoomfaktor unterschiedliche Werte anwenden.
So schreibt man es:
--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)
)
);
Wenn dies bei 375 CSS px angezeigt wird, wird der erste Wert in min zur 6,4vw (der Wert von --spacing-lg-min, also 24 px, umgerechnet in vw).
Da der Mindestwert von clamp() 1,5 rem = 24 px ist, wird dieser bei 200%-Zoom zu 48 px. Der linke Wert von 6,4 vw ist dann kleiner und wird daher angewendet.
Das heißt,
- Bei normaler Anzeige (100%):
- Der Wert von
clamp()ist kleiner als der Wert basierend aufvw. - Da
min()den kleineren Wert auswählt, wirkt sichclamp()aus und die Anzeige variiert je nach Bildschirmbreite.
- Der Wert von
- Bei Vergrößerung (200% Anzeige):
- Das
reminclamp()wird durch die Vergrößerung größer, und der Wert basierend aufvwwird kleiner. - Der Wert basierend auf
vwwird angewendet, und da der Abstand als Verhältnis zur Bildschirmbreite festgelegt ist, lässt sich übermäßige Vergrößerung verhindern.
- Das
Auf diese Weise lassen sich sowohl "responsive Benutzerfreundlichkeit" und "Überlegungen zur Barrierefreiheit" vereinbaren!
* Übrigens wird auf PC-Displays das Design meist besser ausgewogen, wenn auch die Abstände durch die Vergrößerung skaliert werden. Daher verwenden wir --clamp-viewport-min als Referenz und wenden es nur auf Smartphones an.
Vergleich des tatsächlichen Verhaltens
Oben nur clamp, unten min+clamp.
Wenn Sie auf dem Smartphone auf 200% vergrößern, wird der Unterschied deutlich.
* Unter iOS Safari können Sie über das Symbol links in der Adressleiste vergrößern, unter Android Chrome über das Symbol oben rechts.
Fazit
- clamp() ist praktisch für responsive Abstände
- Bei Vergrößerung werden jedoch auch die Abstände vergrößert, was zu Layout-Problemen führen kann.
- In Kombination mit min() ermöglicht dies eine ausgewogene Lösung – normal variabel, bei Vergrößerung kontrolliert.
Wenn Sie WCAG-Konformität anstreben, ist die Integration solcher Implementierungen beruhigend. Eine Implementierung, die bis zu 200% Vergrößerung auf Smartphones berücksichtigt, ist selten, aber mit ihr lässt sich die normale Lesbarkeit bewahren und gleichzeitig Accessibility-Risiken minimieren.
Wenn Sie darüber hinaus feinere Anpassungen neben den Abständen vornehmen möchten, können Sie auch Media-Queries mit engen Breakpoints definieren.
@media (max-width: 239px) {
/* 拡大時に適用したいCSS */
}
Wenn beispielsweise ein 375px breiter Bildschirm zu 200% vergrößert wird, berechnet der Browser die Viewport-Breite als "die Hälfte der Größe (ca. 188px)". So können diese engen Bedingungen erfasst werden.
* Der Wert 239px ist nur ein Beispiel. Es ist ratsam, ihn so anzupassen, dass zukünftige Bildschirmvergrößerungen berücksichtigt werden und die normale Anzeige nicht beeinträchtigt wird.
Durch die Kombination von "clamp() + min()" und "Media-Queries mit engen Breakpoints" wird eine flexiblere und sicherere Accessibility-Unterstützung möglich!
Von DTP in die Web-Welt – und dann Markup, Frontend, Projektleitung und Accessibility alles gemeistert: ein "Technik-Weise". Seit den Anfangstagen von Liberogic vielseitig tätig und mittlerweile eine lebende Wissensquelle im Unternehmen. Derzeit fasziniert von der Frage "Können wir Accessibility-Umsetzung noch stärker mit KI unterstützen?" und erforscht Optimierungsmöglichkeiten durch gezieltes Prompt-Engineering. Technisch wie gedanklich immer noch in Entwicklung.
Futa
IAAP-zertifizierter Web Accessibility Specialist (WAS) / Markup Engineer / Frontend Engineer / Web Director