You might already be aware of the CSS clamp() serve as. You might also be the usage of it to fluidly scale a font length in response to the browser viewport. Adrian Bece demonstrated the concept that in every other Smashing Mag article simply ultimate 12 months. It’s a suave CSS “trick” that has been floating round for some time.

However for those who’ve used the clamp()-based fluid kind methodology your self, then you could have additionally run into articles that provide a caution about it. As an example, Adrian mentions this in his article:

“It’s necessary to reiterate that the usage of rem values doesn’t automagically make fluid typography out there for all customers; it simplest permits the font sizes to answer consumer font personal tastes. The use of the CSS clamp serve as together with the viewport devices to reach fluid sizing introduces every other set of drawbacks that we want to believe.”

Right here’s Una Kravets with a couple of phrases about it on internet.dev:

“Restricting how huge textual content can get with max() or clamp() may cause a WCAG failure underneath 1.4.4 Resize textual content (AA), as a result of a consumer is also not able to scale the textual content to 200% of its authentic length. Make certain to check the effects with zoom.”

Trys Mudford additionally has one thing to mention about it within the Utopia weblog:

“Adrian Roselli fairly rightly warns that clamp could have a knock-on impact at the most font-size when the consumer explicitly units a browser textual content zoom choice. As with all characteristic affecting typography, make sure you check totally earlier than the usage of it in manufacturing.”

Mudford cites Adrian Roselli, who seems to be the core supply of the opposite warnings:

“While you use vw devices or prohibit how huge textual content can get with clamp(), there’s a likelihood a consumer is also not able to scale the textual content to 200% of its authentic length. If that occurs, it’s WCAG failure underneath 1.4.4 Resize textual content (AA) so ensure to check the effects with zoom.”

So, what’s happening right here? And the way are we able to cope with any accessibility problems so we will be able to stay fluidly scaling our textual content? This is precisely what I wish to talk about on this article. In combination, we can assessment what the WCAG pointers say to know the problem, then discover how we may be able to use clamp() in some way that clings to WCAG Luck Criterion (SC) 1.4.4.

WCAG Luck Criterion 1.4.4

Let’s first assessment what WCAG Luck Criterion 1.4.4 says about resizing textual content:

“Except for for captions and pictures of textual content, textual content will also be resized with out assistive era as much as 200 p.c with out lack of content material or capability.”

Typically, if we’re atmosphere CSS font-size to a non-fluid worth, e.g., font-size: 2rem, we by no means have to fret about resizing conduct. All trendy browsers can zoom as much as 500% with out further assistive era.

So, what’s the take care of sizing textual content with viewport devices like this:

h1 {
  font-size: 5vw;
}

Right here’s a easy instance demonstrating the issue. I recommend viewing it in both Chrome or Firefox as a result of zooming in Safari can behave another way.

In case you click on the zoom buttons within the demo’s backside toolbar, you’ll realize that even supposing the web page zoom degree adjustments, the textual content doesn’t get smaller. Not anything actually adjustments, actually.

The problem is that, not like rem and px values, browsers don’t scale viewport-based devices when zooming the web page. This is sensible when fascinated by it. The viewport itself doesn’t exchange when the consumer zooms in or out of a web page. The place we see font-size: 1rem show like font-size: 0.5rem at a 50% zoom, font-size: 5vw remains the similar length in any respect zoom ranges.

Herein lies the accessibility factor. Font sizes in response to vw — or any different viewport-based devices for that subject — may just probably fail to scale to 2 occasions their authentic length the best way WCAG SC 1.4.4 desires them to. That’s true even at 500%, which is the utmost zoom degree for many browsers. If a consumer must zoom in at that scale, then we want to recognize that for legibility.

Again To clamp()

The place does clamp() are compatible into all of this? In any case, many people don’t depend only on vw devices to length kind; we use any of the many gear that are succesful of producing a clamped serve as with a rem or px-based element. Right here’s one instance that scales textual content between 16px and 48px when the viewport is between 320px and 1280px. I’m the usage of px values for simplicity’s sake, however it’s higher to make use of rem in relation to accessibility.

h1 {
  font-size: clamp(16px, 5.33px + 3.33vw, 48px)
}

Check out zooming into the following demo to look how the textual content behaves with this means.

Is that this font length out there? In different phrases, if we zoom the web page to the browser’s 500% most, does the content material show a minimum of double its authentic length? If we open the demo in full-page view and resize the browser width to, say, 1500px, realize what occurs once we zoom in to 500%.

The textual content simplest scales as much as 55px, or 1.67 occasions its authentic length, even if we zoomed all the web page to 5 occasions its authentic length. And since WCAG SC 1.4.4 calls for that textual content can scale to a minimum of two occasions its authentic length, this straightforward instance would fail an accessibility audit, a minimum of in maximum browsers at positive viewport widths.

Without a doubt this may’t be an issue for all clamped font sizes with vw devices, proper? What about person who simplest will increase from 16px to 18px:

h1 {
  font-size: clamp(16px, 15.33px + 0.208vw, 18px);
}

The vw a part of that internal calc() serve as (clamp() helps calc() with out explicitly pointing out it) is so small that it couldn’t most likely reason the similar accessibility failure, proper?

Positive sufficient, even if it doesn’t get to fairly 500% of its authentic length when the web page is zoomed to 500%, the dimensions of the textual content no doubt passes the 200% zoom laid out in WCAG SC 1.4.4.

So, clamped viewport-based font sizes fail WCAG SC 1.4.4 in some circumstances however no longer in others. The one recommendation I’ve noticed for figuring out which scenarios go or fail is to test every of them manually, as Adrian Roselli firstly instructed. However that’s time-consuming and vague for the reason that purposes don’t scale intuitively.

There will have to be some dating between our inputs — i.e., the minimal font length, most font length, minimal breakpoint, and most breakpoint — that may lend a hand us resolve once they pose accessibility problems.

Pondering Mathematically

If we take into consideration this downside mathematically, we actually wish to be sure that z₅(v) ≥ 2z₁(v). Let’s spoil that down.

z₁(v) and z₅(v) are purposes that take the viewport width, v, as their enter and go back a font length at a 100% zoom degree and a 500% zoom degree, respectively. In different phrases, what we wish to know is at what vary of viewport widths will z₅(v) be much less than 2×z₁(v), which represents the minimal length defined in WCAG SC 1.4.4?

The use of the primary clamp() instance we checked out that failed WCAG SC 1.4.4, we all know that the z₁ serve as is the clamp() expression:

z₁(v) = clamp(16, 5.33 + 0.0333v, 48)

Understand: The vw devices are divided via 100 to translate from CSS the place 100vw equals the viewport width in pixels.

As for the z₅ serve as, it’s tempting to suppose that z₅ = 5z₁. However bear in mind what we realized from that first demo: viewport-based devices don’t scale up with the browser’s zoom degree. This implies z₅ is extra appropriately expressed like this:

z₅(v) = clamp(16*5, 5.33*5 + 0.0333v, 48*5)

Understand: This scales the whole thing up via 5 (or 500%), with the exception of for v. This simulates how the browser scales the web page when zooming.

Let’s constitute the clamp() serve as mathematically. We will convert it to a piecewise serve as, that means z₁(v) and z₅(v) would in the long run seem like the next determine:

We will graph those purposes to lend a hand visualize the issue. Right here’s the bottom serve as, z₁(v), with the viewport width, v, at the x-axis:

This seems about proper. The font length remains at 16px till the viewport is 320px broad, and it will increase linearly from there earlier than it hits 48px at a viewport width of 1280px. To this point, so just right.

Right here’s a extra attention-grabbing graph evaluating 2z₁(v) and z₅(v):

Are you able to spot the accessibility failure in this graph? When z₅(v) (in inexperienced) is lower than 2z₁(v) (in teal), the viewport-based font length fails WCAG SC 1.4.4.

Let’s zoom into the bottom-left area for a more in-depth glance:

This determine signifies that failure happens when the browser width is roughly between 1050px and 2100px. You’ll be able to test this via opening the unique demo once more and zooming into it at other viewport widths. When the viewport is lower than 1050px or more than 2100px, the textual content will have to scale as much as a minimum of two occasions its authentic length at a 500% zoom. But if it’s in between 1050px and 2100px, it doesn’t.

Trace: We need to manually measure the textual content — e.g., take a screenshot — as a result of browsers don’t display zoomed values in DevTools.

Normal Answers

For simplicity’s sake, we’ve simplest all for one clamp() expression to this point. Are we able to generalize those findings someway to make sure any clamped expression passes WCAG SC 1.4.4?

Let’s take a more in-depth take a look at what’s taking place within the failure above. Understand that the issue is brought about as a result of 2z₁(v) — the SC 1.4.4 requirement — reaches its height earlier than z₅(v) begins expanding.

When would that be the case? The whole thing in 2z₁(v) is scaled via 200%, together with the slope of the road (v). The serve as reaches its height worth on the identical viewport width the place z₁(v) reaches its height worth (the utmost 1280px breakpoint). That height worth is 2 occasions the utmost font length we would like which, on this case, is 2*48, or 96px.

On the other hand, the slope of z₅(v) is equal to z₁(v). In different phrases, the serve as doesn’t get started expanding from its lowest clamped level — 5 occasions the minimal font length we would like — till the viewport width is 5 occasions the minimal breakpoint. On this case, this is 5*320, or 1600px.

Fascinated about this most often, we will be able to say that if 2z₁(v) peaks earlier than z₅(v) begins expanding, or if the utmost breakpoint is lower than 5 occasions the minimal breakpoint, then the height worth of 2z₁(v) will have to be lower than or equivalent to the height worth of z₅(v), or two occasions the utmost worth this is lower than or equivalent to 5 occasions the minimal worth.

Or more effective nonetheless: The utmost worth will have to be lower than or equivalent to two.5 occasions the minimal worth.

What about when the utmost breakpoint is greater than 5 occasions the minimal breakpoint? Let’s see what our graph seems like once we exchange the utmost breakpoint from 1280px to 1664px and the utmost font length to 40px:

Technically, shall we escape with a fairly upper most font length. To determine simply how a lot upper, we’d have to unravel for z₅(v) ≥ 2z₁(v) on the level when 2z₁(v) reaches its height, which is when v equals the utmost breakpoint. (Hat tip to my brother, Zach Barvian, whose very good math talents helped me with this.)

To save lots of you the mathematics, you’ll be able to mess around with this calculator to look which combos go WCAG SC 1.4.4.

Conclusion

Summing up what we’ve coated:

• If the utmost font length is much less than or equivalent to two.5 occasions the minimal font length, then the textual content will all the time go WCAG SC 1.4.4, a minimum of on all trendy browsers.
• If the utmost breakpoint is higher than 5 occasions the minimal breakpoint, it’s imaginable to escape with a fairly upper most font length. That stated, the rise is negligible, and that could be a huge breakpoint vary to make use of in follow.

Importantly, that first rule is right for non-fluid responsive kind as neatly. In case you open this pen, for instance, realize that it makes use of common media queries to extend the h1 component’s length from an preliminary worth of 1rem to 3rem (which violates our first rule), with an in-between forestall for 2rem.

In case you zoom in at 500% with a browser width of roughly 1000px, you’re going to see that the textual content doesn’t achieve 200% of its preliminary length. This is sensible as a result of for those who have been to explain 2z₁(v) and z₅(v) mathematically, they’d be even more effective piecewise purposes with the similar most and minimal boundaries. This tenet would cling for any serve as describing a font length with a identified minimal and most.

At some point, after all, we would possibly get extra gear from browsers to deal with those problems and accommodate even better most font sizes. Within the intervening time, even though, I am hoping you in finding this newsletter useful when construction responsive frontends.

(gg, yk)