Web accessibility

Accessibility in web interfaces is not a single feature to bolt on but a consequence of many smaller technical decisions. Two areas where it surfaces repeatedly in CSS and typography work are unit choices and the handling of user preferences.

Fluid typography is a useful example. Using clamp() to scale font sizes across viewport widths produces smoother layouts, but the choice of unit matters for accessibility. Adrian Bece’s breakdown of CSS clamp explains that viewport units in the preferred value of clamp() do not respond to the browser’s base font size setting. Users who increase their default font size in browser preferences to improve readability will see no effect if sizes are expressed purely in vw. Using rem-based calculations, or mixing rem into the fluid formula, preserves that user control. This is not a minor edge case; it is the mechanism by which fluid typography either respects or silently overrides a user’s explicit accessibility configuration.

At a layout level, Amit Sheen’s argument for breakpoint-free UIs reframes media queries as the appropriate tool for device capabilities and user preferences, such as prefers-reduced-motion or prefers-contrast, rather than for viewport widths. Reserving media queries for capability and preference queries makes accessibility accommodations more intentional and less likely to be accidentally overridden by layout breakpoints.

Progressive enhancement connects these concerns. Sunkanmi Fafowora’s comparison of custom dropdown checkmarks shows how JavaScript-heavy custom components often degrade badly when scripting is unavailable or slow, while the newer CSS ::checkmark pseudo-element keeps interactive semantics in the platform layer. The tradeoff is browser support gaps, which makes the case for progressive enhancement as a strategy: deliver accessible baseline behavior first and enhance where supported.