I have seen compelling examples of ways to code that work with browser zoom that help make a site look nicer when high levels of zoom are applied. But they don’t fight against it.

You might say: but I zoomed my site in to 500% and it looks bad! It might, it’s true. But that’s just, like, your opinion, man. Zoom works consistently. People that use it know what it does. They know what to expect. They aren’t you, they might have a different approach an expectation than you do.

I wanted to write all that before I share this snippet. This is a variation of what someone sent me the other day as a way to size type that scales with the window:

html {
  --size-factor: (0.00188323 * 100vw);
  font-size: calc(12 * var(--size-factor));
}

Their version was a bit more exotic, incorporating different scaling numbers for pages in landscape vs. portrait and such. This has the effect of “fluid type” on a website, the bigger the window, the bigger the type, and vice versa. The magic number you see above there is essentially so that that you can multiply against it with reasonable numbers that maybe feel something close to pixel (px) numbers, 12px in this case. In that way, it’s a lot like the font-size: 62.5%; thing we used to see a lot such that the math works out that 1.2rem would be 12px (you can do it in your head easier). I’d suggest scrapping that thinking. Don’t think about font sizing in pixels at all — it isn’t useful.

What is ultimately going on here though is that the font-size is being set in viewpoint units only. This is what “fights” the browser zoom. I could have done html { font-size: 3vw; } and the effect would have been basically the same.

Bad news bears.

The advice: any time you are setting a font-size, it cannot only be viewport units. It has to factor in some other kind of unit. Heck, even px works to maintain some scaling. Even this freaks me out a little bit because it affects that rate of scaling and if you speed that up or slow that down too much, that’s also messing up with the natural exceptions of how zoom works.

The best approach that I know of is to use clamp() so that font-size can’t get too big or too small based on window size alone, then include a rem value (that’s somewhere in the vicinity of 1) in the calculation such that zooming still works normally.

See the Fluid Type Scale website for easy to generate snippets.

And this goes for using container units too!

The relevant parts of an image aren’t limited to the cold hard facts. Images can make you feel a particular way, and that’s something that should be made available to a screen reader user.

If necessary, that is. Some images just aren’t particularly emotional, like a screenshot of a banking dashboard. I think what Scott Vandehey says is a more broadly useful way to think about it:

Write alternative text as if you’re describing the image to a friend.

That’s helpful to me. Scott’s article has a bunch more practical advice and links about this topic from the community. Also good to remember: alt text shows when images are broken and different browsers handle that differently depending on how much of it there is.

Do not remove a fence until you know why it was put up in the first place.

In the case of interactive form controls (inputs, textareas, buttons, etc.), those pesky borders were put there because they have an accessibility benefit when using High Contrast Mode, a feature used by 30.6% of low-vision users. Usually when we’re talking about High Contrast Mode in web development we’re specifically referencing Windows High Contrast Mode, but nearly every desktop and mobile operating system has contrast settings, each behaving a little differently. Windows High Contrast flattens all colors to black on white with blue accents (or white on black with yellow accents) and remove all background images from the document.

If we look at some thing more interactive like the comment form on the Boost blog, we can see how the “Post Comment” button loses a bit of punch in High Contrast Mode and might be mistaken as text floating on the page.

To make that button look more like a button in high-contrast mode, we remove the border: 0 and instead use border-color: transparent we get a control that looks like a button for low-vision users as well.

Sighted users will never know the difference! So instead of removing the border, try setting border-color to transparent instead:

border-color: transparent;

The same trick works for overriding outline , set outline-color to transparent:

outline-color: transparent;

Oops! I’ve already nuked my borders

If you’ve already removed borders everywhere and want to support High Contrast Mode (you do) but don’t want to re-architect your entire CSS, you can use the forced-colors media query to detect High Contrast Mode and layer in styling as necessary:

/* Example code, do not use */
@media (forced-colors: active) {
  input, textarea, button {
    border: 1px solid transparent!important;
  }
}

There are other places (e.g. text on images) where the forced-colors media query can get you out of a jam.

Testing forced-colors

To test forced-colors the easiest way is to emulate forced-colors inside Chrome DevTools. There are two easy ways in any version of Chromium browser and an even easier way in Microsoft Edge.

1. Chrome DevTools > Three Dots Menu > More Tools > Rendering > Emulate CSS media feature forced-colors
2. Chrome DevTools > Open Command Palette (CMD + Shift + P) > Search for “Emulate CSS forced-colors: active”

Edge DevTools has an easy way to access color emulation from the Device Emulation Screen as well.

• Edge DevTools > Device Emulation > Open Eye Droppers dropdown in top toolbar > forced-colors: active

One other aspect to consider is that folks using high-contrast mode are often using it with a screen magnifier or 200%~400% browser zoom as well. So be sure to test those situations as well.

High-Contrast Mode keeps you honest about color usage

Testing in High-Contrast Mode is probably something you’re not doing, but that’s okay because you can start today. While it’s worthwhile to test High-Contrast Mode just to support low-vision users, because it aggressively flattens and removes colors it has a knock-on effect of showing places where you’ve over-relied on color to make elements or states distinct, which is another accessibility error in itself (§1.4.1).

High-Contrast Mode may seem like a far out edge case, but it’s not. Lots of folks depend on it. Understanding High-Contrast Mode and its limitations are a step on the pathway to becoming a better front-end developer.

Thanks Melanie Sumner for the inspiration for this post and check out her work on Continuous Accessibility.

The multiple attribute on <select> should pretty much never be used. It’s like the polar opposite of single <select>, where instead of universal familiarity, it has universal unfamiliarity. Perhaps its only saving grace is that I have yet to encounter this attribute in any codebase.

HTML: The Bad Parts

It’s pretty fair to say that everyone knows how to use a native select element. But add that one little attribute, <select multiple>, and now hardly anyone knows how it works. It turns into a weird box UI that you rarely see, and you just need to know how it works. I had to test, and it seems on my machine holding the shift or command key will allow you turn on/off multiple options, but I wouldn’t be surprised if that varied from machine to machine and keyboard to keyboard, and it’s a totally different look/experience on mobile OSs.