A<\/code>, AA<\/code> and AAA<\/code>. To be at the AA<\/code> level, among other requirements, we have to provide a way to increase the site’s font size:<\/p>\n1.4.4<\/a> Resize text:<\/strong> Except for captions<\/a> and images of text<\/a>, text<\/a> can be resized without assistive technology<\/a> up to 200 percent without loss of content or functionality. (Level AA)<\/p><\/blockquote>\nLet’s look at solutions for this and try to find the best one we can.<\/p>\n
Update(09\/25\/17):<\/strong> It turns out that WCAG doesn’t require a text resizing custom solution in addition to what user-agents provide. We just have to make sure a website looks OK as a result of resizing. Yet if we still want to scale elements for any reason, below is a thorough analysis of different methods for doing that.<\/p>\n<\/p>\n
Incomplete Solution\u200a: \u200aCSS zoom<\/code><\/h3>\nThe first word which comes up when we talk about size changing is zoom<\/em>. CSS has a zoom<\/code> property and it does exactly what we want\u200a\u2014\u200aincreases size. <\/p>\nLet’s take a look at a common design pattern (that we’ll use for the rest of this article): a horizontal bar of navigation that turns into a menu icon at a certain breakpoint:<\/p>\n![\"\"](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2017\/08\/1-RNslcYJZjmPXgv4M_enFYw.gif?ssl=1\")
This is what we want to happen. No wrapping and the entire menu turns into a menu icon at a specified breakpoint.<\/figcaption><\/figure>\nThe GIF below shows what we get with zoom<\/code> approach applied to the menu element. I created a switcher which allows selecting different sizes and applies an appropriate zoom level: <\/p>\n![\"\"](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2017\/08\/1-y39NlrZDeYXR0KTPnSCL_Q.gif?ssl=1\")
Check out the Pen here<\/a> if you want to play with it.<\/figcaption><\/figure>\nThe menu goes outside visible area because we cannot programmatically increase viewport width with zoom nor we can wrap the menu because of the requirement. The menu icon doesn’t appear either, because the screen size hasn’t actually changed, it’s the same as before we clicked the switcher.<\/p>\n
All these problems, plus, zoom<\/code> is not supported by Firefox at all anyway.<\/p>\nWrong Solution: Scale Transforms<\/h3>\n
We can get largely the same effect with transform: scale<\/code> as we got with zoom<\/code>. Except, transform<\/code> is more widely supported by browsers<\/a>. Still, we get the exact same problems as we got with zoom<\/code>: the menu doesn’t fit into the visible area, and worse, it goes beyond the vertical visible area as well because page layout is calculated based on an initial 1-factor scale.<\/p>\nSee the Pen Font-switcher–wrong-scale<\/a> by Mikhail Romanov (@romanovma<\/a>) on CodePen<\/a>.<\/p>\nAnother Incomplete Solution\u200a: \u200arem<\/code> and html<\/code> font-size<\/code><\/h3>\nInstead of zooming or scaling, we could use rem<\/code> as the sizing unit for all elements on the page. We can then change their size by altering html<\/code> element’s font-size<\/code> property, because by its definition 1rem<\/code> equals to html<\/code>‘s font-size<\/code> value.<\/p>\nThis is a fairly good solution, but not quite perfect. As you can see in the following demo, it has the same issues as previous examples: at one point it doesn’t fit horizontally because required space is increased but the viewport width stays intact.<\/p>\n
See the Pen Font-switcher–wrong-rem<\/a> by Mikhail Romanov (@romanovma<\/a>) on CodePen<\/a>.<\/p>\nThe trouble, in a sense, is that the media queries don’t adjust to the change in size. When we go up in size, the media queries should adjust accordingly so that the effect at the same place would happen before the size change, relative to the content.<\/p>\n
Working Solution: \u200aEmulate Browser Zoom with Sass mixin<\/code><\/h3>\nTo find inspiration, let’s see how the native<\/em> browser zoom feature handles the problem:<\/p>\n![\"\"](\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2017\/08\/browser-zoom.gif?ssl=1\")
<\/figure>\nWow! Chrome understands that zooming actually does change the viewport. The larger the zoom, the narrower the viewport. Meaning that our media queries will actually take effect like we expect and need them to.<\/p>\n
One way to achieve this (without relying on native zoom, because there is no way for us to access that for our on on-page controls as required by AA) is to somehow update the media query values every time we switch the font size. <\/p>\n
For example, say we have a media query breakpoint at 1024px<\/code> and we perform a 200%<\/code> zoom. We should update that breakpoint to 2048px<\/code> to compensate for the new size.<\/p>\nShouldn’t this be easy? Can’t we just set the media queries with rem<\/code> units so that when we increase the font-size<\/code> the media queries automatically adjust? Sadly no, that approach doesn’t work. Try to update media query from px<\/code> to rem<\/code> in this Pen<\/a> and see that nothing changes. The \u200alayout doesn’t switch breakpoints after increasing the size. That is because, according to standard<\/a>s, both rem<\/code> and em<\/code> units in media queries are calculated based on the initial value of html<\/code> element font-size<\/code> which is normally 16px<\/code> (and can vary). <\/p>\nRelative units in media queries are based on the initial value, which means that units are never based on results of declarations. For example, in HTML, the em<\/code> unit is relative to the initial value of ‘font-size<\/code>.<\/p><\/blockquote>\nWe can use power of Sass mixin<\/code>s to get around this though! Here is how we’ll do it:<\/p>\n\n- we’ll use a special class on
html<\/code> element for each size(font-size--s<\/code>, font-size<\/code>\u200a--<\/code>\u200am<\/code>, font-size--l<\/code>, font-size<\/code>\u200a--<\/code>\u200axl<\/code>, etc.)<\/li>\n- we’ll use a special
mixin<\/code>, which creates a media query rule for every combination of breakpoint and size and which takes into account both screen width and modifier class applied to html<\/code> element<\/li>\n- we’ll wrap code with this
mixin<\/code> everywhere we want to apply a media-query.<\/li>\n<\/ul>\nHere is how this mixin<\/code> looks:<\/p>\n$desktop: 640px;\r\n$m: 1.5;\r\n$l: 2;\r\n$xl: 4;\r\n\r\n\/\/ the main trick is here. We increase the min-width if we increase the font-size\r\n@mixin media-desktop {\r\n html.font-size--s & {\r\n @media (min-width: $desktop) {\r\n @content;\r\n }\r\n }\r\n\r\n html.font-size--m & {\r\n @media (min-width: $desktop * $m) {\r\n @content;\r\n }\r\n }\r\n\r\n html.font-size--l & {\r\n @media (min-width: $desktop * $l) {\r\n @content;\r\n }\r\n }\r\n\r\n html.font-size--xl & {\r\n @media (min-width: $desktop * $xl) {\r\n @content;\r\n }\r\n }\r\n}\r\n.menu {\r\n @include media-desktop {\r\n &__mobile {\r\n display: none;\r\n }\r\n }\r\n}<\/code><\/pre>\nAnd an example of the CSS it generates:<\/p>\n
@media (min-width: 640px) {\r\n html.font-size--s .menu__mobile {\r\n display: none;\r\n }\r\n}\r\n@media (min-width: 960px) {\r\n html.font-size--m .menu__mobile {\r\n display: none;\r\n }\r\n}\r\n@media (min-width: 1280px) {\r\n html.font-size--l .menu__mobile {\r\n display: none;\r\n }\r\n}\r\n@media (min-width: 2560px) {\r\n html.font-size--xl .menu__mobile {\r\n display: none;\r\n }\r\n}<\/code><\/pre>\nSo if we have n breakpoints and m sizes, we will generate n times m media query rules, and that will cover all possible cases and will give us desired ability to use increased media queries when the font size is increased.<\/p>\n
Check out the Pen below to see how it works:<\/p>\n
See the Pen Font-switcher–right<\/a> by Mikhail Romanov (@romanovma<\/a>) on CodePen<\/a>.<\/p>\nDrawbacks<\/h3>\n
There are some drawbacks though. Let’s see how we can handle them.<\/p>\n
Increased specificity on media-query selectors.<\/h4>\n
All code inside the media query gets additional level of specificity because it goes inside html.font-size\u200a\u2014\u200ax<\/code> selector. So if we go with the mobile first approach and use, for example, .no-margin<\/code> modifier on an element then desktop normal style can win over the modifier and desktop margins will be applied.<\/p>\nTo avoid this we can create the same mixin<\/code> for mobile and wrap with our mixins<\/code> not only desktop but also mobile CSS code. That will balance specificity. <\/p>\nOther ways are to handle every special case with an individual approach by artificially increasing specificity, or creating mixin<\/code> with desired functionality(no margin in our example) and putting it not for mobile only but also into every breakpoint code.<\/p>\nIncreased amount of generated CSS.<\/h4>\n
Amount of generated CSS will be higher because we generate same CSS code for every size.<\/p>\n
This shouldn’t be an issue if files are compressed with gzip (and that is usually the case) because it handles repeated code very well.<\/p>\n
Some front-end frameworks like Zurb Foundation use built-in breakpoints in JavaScript utilities and CSS media queries.<\/h4>\n