Snippets

@supports may be very useful, but it can only tell you so much, especially in the case of browsers that will return true, technically supporting the feature, but having a buggy implementation. This is a case where we can often assume too much about a browser based on a reductive test that isn’t guaranteed to tell us what we think it does. PPK explains:

If a mobile browser doesn’t support background-attachment: fixed in practice, what happens when you do this?

Does it return false because the mobile browser doesn’t support it? Or does it return true because its desktop version supports it? With my background-attachment test data in hand I could now answer this question.

All mobile browsers return true for both fixed and local. Only 3 out of 23 browsers speak the truth here. See the test case and the inevitable table for more details.

[…]

What’s clear from these tests is that @supports is only useful when you’re detecting entire CSS modules such as flexbox. So the check below makes sense.

This example is likely safe. If a browser decides to support flexbox, display: flex is the first item on the agenda, so detecting it makes perfect sense. (It’s theoretically possible, though, that a browser fakes display: flex support in order to end up on the right side of some support detects. But as far as I know this is not the case today.)

On the other hand, if a browser has flaky support for, I don’t know, justify-content, a more precise check like this may or may not work, depending on how the CSS parser is written:

So this example is unsafe. Don’t use @supports for such detailed compatibility questions.

I’ve been thinking a lot lately about our biases and their influence on what we build and how. We’re all biased in some way—it’s an inevitable side-effect of living. We experience certain things, we live in a certain environment, we have certain interactions and over time all of these experiences and factors add up to impact the way we view ourselves and the way we view others.

These biases come into play over and over again in our work, and can have devastating consequences.

There was an interesting post on The Coral Project about anonymity and its impact—or rather, non-impact—on online behavior. A frequent refrain heard when we try to understand why online behavior is so frequently so poor is that the ability to be anonymous is one of the primary reasons for the problem. J. Nathan Matias argues differently, though:

Not only would removing anonymity fail to consistently improve online community behavior – forcing real names in online communities could also increase discrimination and worsen harassment.

We need to change our entire approach to the question. Our concerns about anonymity are overly-simplistic; system design can’t solve social problems without actual social change.

While the article cites a little bit of research questioning our assumptions about anonymity online, the bulk of the article is focused on reframing our perspective of the discussion. We often consider the question of bad behavior online from the perspective of the people misbehaving. What is it that makes them feel free to be so much more vindictive in an online setting? Matias instead builds his case by focusing on the victims of this behavior.

Revealing personal information exposes people to greater levels of harassment and discrimination. While there is no conclusive evidence that displaying names and identities will reliably reduce social problems, many studies have documented the problems it creates. When people’s names and photos are shown on a platform, people who provide a service to them – drivers, hosts, buyers – reject transactions from people of color and charge them more. Revealing marital status on DonorsChoose caused donors give less to students with women teachers, in fields where women were a minority. Gender- and race-based harassment are only possible if people know a person’s gender and/or race, and real names often give strong indications around both of these categories. Requiring people to disclose that information forces those risks upon them.

[…]

[O]ne thing we can state about removing anonymity is that it increases the risk for people on the receiving end of online harassment.

Removing anonymity online, then, is yet another example of how we reflect our own biases in the decisions we make and the things we build.

It is our biases that lead us to overlook accessibility or how an application performs on a low-powered device or spotty network.

It is our biases that lead us to develop algorithms that struggle to recognize women’s voices or show more high-paying executive jobs to men than women.

And it is our biases that lead us to frame the problem of online behavior from that of the attacker, leading to solutions that are dangerous for the people on the receiving end of that harassment.

In each of these situations, our biases don’t just lead us to build something that is hard to use; they cause us to actively, if unintentionally, exclude entire groups of people.

When I was first styling Resilient Web Design, I made heavy use of vh units. The vertical spacing between elements—headings, paragraphs, images—was all proportional to the overall viewport height. It looked great!

Then I tested it on real devices.

Here’s the problem: when a page loads up in a mobile browser—like, say, Chrome on an Android device—the URL bar is at the top of the screen. The height of that piece of the browser interface isn’t taken into account for the viewport height. That makes sense: the viewport height is the amount of screen real estate available for the content. The content doesn’t extend into the URL bar, therefore the height of the URL bar shouldn’t be part of the viewport height.

But then if you start scrolling down, the URL bar scrolls away off the top of the screen. So now it’s behaving as though it is part of the content rather than part of the browser interface. At this point, the value of the viewport height changes: now it’s the previous value plus the height of the URL bar that was previously there but which has now disappeared.

[…]

In my initial implementation of Resilient Web Design, the one where I was styling almost everything with vh, the site was unusable. Every time you started scrolling, things would jump around. I had to go back to the drawing board and remove almost all instances of vh from the styles.

This is an incredibly thorough guide to web font loading strategies, and their pros and cons.

If you’re looking for a specific approach, I’ve prepared some handy links that will take you to the section you need. Let’s say you want an approach that:

• is the most well rounded approach that will be good enough for most use cases: FOUT with a Class.

• is the easiest possible thing to implement: I’ve learned a lot about web fonts and at time of writing this article the current browser support is lacking for the easiest methods for effective/robust web font implementation. It is with that in mind that I will admit—if you’re looking for the easy way out already, you should consider not using web fonts. If you don’t know what web fonts are doing to improve your design, they may not be right for you. Don’t get me wrong, web fonts are great. But educate yourself on the benefit first. (In Defense of Web Fonts, The Value of a Web Font by Robin Rendle is a good start. If you have others, please leave a comment below!)

• is the best performance-oriented approach: Use one of the Critical FOFT approaches. Personally, at time of writing my preference is Critical FOFT with Data URI but will shift toward Critical FOFT with preload as browser support for preload increases.

• will work well with a large number of web fonts: If you’re web font obsessed (anything more than 4 or 5 web fonts or a total file size of more than 100KB) this one is kind of tricky. I’d first recommend trying to pare your web font usage down, but if that isn’t possible stick with a standard FOFT, or FOUT with Two Stage Render approach. Use separate FOFT approaches for each typeface (grouping of Roman, Bold, Italic, et cetera).

• will work with my existing cloud/web font hosting solution: FOFT approaches generally require self hosting, so stick with the tried and true FOUT with a Class approach.

The Service Worker Cookbook is a collection of working, practical examples of using service workers in modern web apps.

Setting the tabindex of the focused element to “0” ensures that if the user tabs away from the widget and then returns, the selected item within the group retains focus. Note that updating the tabindex to “0” requires also updating the previously selected item to tabindex="-1". This technique involves programmatically moving focus in response to key events and updating the tabindex to reflect the currently focused item. To do this:

Bind a key down handler to each element in the group, and when an arrow key is used to move to another element:

1. programmatically apply focus to the new element,
2. update the tabindex of the focused element to “0”, and
3. update the tabindex of the previously focused element to “-1”.

Here’s an example of a WAI-ARIA tree view using this technique.

For a more visual explanation, see the following video by Rob Dodson:

This document explains the various ways of hiding things and the implications that come with that.

When we say an element is hidden, we usually mean it is not visible. However, the screen is not the only output mechanism we may need to hide content from. Systems like screen readers and braille displays rely on a document’s representation in the accessibility tree. For disambiguation we’ll use the following terms:

Completely hidden

The element is not rendered on screen, not exposed in the accessibility tree, not accessible to keyboard navigation.

Semantically hidden

The element is rendered on screen, but not exposed in the accessibility tree, and still accessible to keyboard navigation.

Visually hidden

The element is not rendered on screen, but exposed in the accessibility tree, and still accessible to keyboard navigation.

[…]

How to hide elements completely

Completely hiding elements can be done in 3 ways:

• via the CSS property display, e.g. display: none;
• via the CSS property visibility, e.g. visibility: hidden;
• via the HTML5 attribute hidden, e.g. <span hidden>

While each of these techniques has the same end result, i.e. content is not rendered and not exposed in the accessibility tree, they have different behaviors.

[…]

How to hide elements semantically

To hide content from the accessibility tree but retain the content on screen, we may use the attribute aria-hidden="true".

[…]

2016 edition of .visuallyhidden

[…]

• It works in all modern browsers including Internet Explorer 9 - 11.
• It side-steps the need to re-style everything for focusable elements such as skip-links.
• It accounts for the deprecated clip property.

Keyboard navigation

The techniques to hide elements only visually or semantically come with a caveat. Focusable elements like <a href="…"> remain keyboard navigatable, even though the element is not visible on screen or not exposed in the accessibility tree.

To make sure sighted keyboard users do not end up focusing elements they can’t see, and screen reader users not focusing element’s that don’t exist for them, we need to make sure that partially hidden content is not accessible to keyboard navigation using the Tab and Shift Tab keys. To accomplish this, we can add tabindex="-1" to the elements we want to hide from the keyboard.

Recap

• Use the hidden attribute to completely hide an element.
• Use the aria-hidden attribute to hide an element from the accessibility tree.
• Use the .visuallyhidden class to hide an element from the screen.
• Use visibility: inherit; instead of visibility: visible; to avoid accidentally showing content.
• Do not attach any CSS styles to the aria-hidden attribute.
• Take care of keyboard focusable content that is partially hidden by adding tabindex="-1".