Snippets

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".

I thought this was an excellent talk on the hard questions we should be asking ourselves as developers. Why do most people use closed, proprietary systems and devices, if the open web is so wonderful? Even as developers, we still use them ourselves, and depend on them. How can we be more empathetic to what the average user needs and wants? How can we lock open the web, so the future isn’t entirely dependent on huge corporations and services, which is where we seem to be heading?

The principle of feature detection is really simple. Before you use a particular API you test if it is actually available. If it is not, you can provide an alternative or fail gracefully. Why is this necessary? Well, unlike HTML and CSS, JavaScript can be very unforgiving. If you would use an API without actually testing for its existence and assume it just works you risk that your script will simply throw an error and die when it tries to call the API.

Take the following example:

Before we call the getCurrentPosition() function, we actually check if the Geolocation API is available. This is a pattern we see again and again with feature detection.

If you look carefully you will notice that we don’t actually test if the getCurrentPosition() function is available. We assume it is, because navigator.geolocation exists. But is there actually a guarantee? No.

[…]

Cutting the mustard

There is another principle that has gotten very popular lately. By using some very specific feature tests you can make a distinction between old legacy browsers and modern browsers.

In itself it is a perfectly valid way make sure the browser has a certain level of standards support. But at the same time also dangerous, because supporting querySelector, localStorage and addEventListener doesn’t say anything about supporting other standards.

Even if the browser passes the test, you really still need to do proper feature detection for each and every API you are depending on.

[…]

There are features where the whole premise of feature detection just fails horribly. Some browsers ship features that are so broken that they do not work at all. Sometimes it is a bug, and sometimes it is just pure laziness or incompetence. That may sound harsh, but I’m sure you agree with me at the end of this article.

The most benign variants are simply bugs. Everybody ships bugs. And the good browsers quickly fix them. Take for example Opera 18 which did have the API for Web Notifications, but crashed when you tried to use it. Blink, the rendering engine, actually supported the API, but Opera did not have a proper back-end implementation. And unfortunately this feature got enabled by mistake. I reported it and it was fixed in Opera 19. These things happen.