There’s a whole lot of accessibility in this week’s news, from the nuances of using :focus-visible
and input placeholders, to accessible typefaces and a Safari bug with :display: contents
. Plus, a snippet for a bare-bones web component that supports style encapsulation.
Now may be a good time to start using :focus-visible
The CSS :focus-visible
pseudo-class replaces :focus
as the new way to create custom focus indicators for keyboard users. Chrome recently switched from :focus
to :focus-visible
in the user agent stylesheet and, as a result of that change, the default focus ring is no longer shown when the user clicks or taps a button.
When switching from :focus
to :focus-visible
, consider backwards compatibility. Your keyboard focus indicators should be clearly visible in all browsers, not just the ones that support :focus-visible
. If you only style :focus-visible
, non-supporting browsers will show the default focus ring which, depending on your design, “may not be sufficiently clear or visible at all.”
button {
background: white;
}
button:focus-visible {
outline: none;
background: #ffdd00; /* gold */
}
A good way to start using :focus-visible
today is to define the focus styles in a :focus
rule and then immediately undo these same styles in a :focus:not(:focus-visible)
rule. This is admittedly not the most elegant and intuitive pattern, but it works well in all browsers:
- Browsers that don’t support
:focus-visible
use the focus styles defined in the:focus
rule and ignore the second style rule completely (because:focus-visible
is unknown to them). - In browsers that do support
:focus-visible
, the second style rule reverts the focus styles defined in the:focus
rule if the:focus-visible
state isn’t active as well. In other words, the focus styles defined in the:focus
rule are only in effect when:focus-visible
is also active.
button:focus {
outline: none;
background: #ffdd00; /* gold */
}
button:focus:not(:focus-visible) {
background: white; /* undo gold */
}
The BBC created a more accessible typeface
The BBC created their own custom typeface called Reith (named after the BBC’s founder Sir John Reith). Their goal was to create a font that supports multiple languages and is easier to read, especially on small devices. The font was tested with mixed-ability user groups (dyslexia and vision impairment) and across different screen sizes.
We [the BBC] were using Helvetica or Arial. We also had Gill Sans as the corporate typeface. These typefaces were designed a hundred years ago for the printed page [and] don’t perform well on today’s modern digital screens.
Note: If you’d like to inspect Reith Sans and Reith Serif in Wakamai Fondue, you can quickly access the URLs of the WOFF2 files in the “All fonts on page” section of the Fonts pane in Firefox’s DOM inspector on BBC’s website.
display: contents
is still not accessible in Safari
The CSS display: contents
value has been supported in browsers since 2018. An element with this value “does not generate any boxes” and is effectively replaced by its children. This is especially useful in flex and grid layouts, where the contents
value can be used to “promote” more deeply nested elements to flex/grid items while retaining a semantic document structure.
Unfortunately, this feature originally shipped with an implementation bug that removed the element from the browser’s accessibility tree. For example, applying display: contents
to a <ul>
element resulted in that element no longer mentioned by screen readers. Since then, this bug has been fixed in Firefox and Chrome (in the latest version).
In Chrome and Firefox, the screen reader informs the user that the “Main, navigation” contains a “list, 2 items.” In Safari, the latter part is missing because the <ul>
and <li>
elements are not present in the accessibility tree. Until Apple fixes this bug in Safari, be careful when using the contents
value on semantic elements and test in screen readers to confirm that your pages are accessible in Safari as well.
opacity
when overriding the color of placeholder text
Set Accessibility experts recommend avoiding placeholders if possible because they can be confused for pre-populated text and disappear when the user starts entering a value. However, many websites (including Wikipedia and GOV.UK) use placeholders in simple web forms that contain only a single input field, such as a search field.
Placeholders can be styled via the widely supported ::placeholder
pseudo-element. If your design calls for a custom color for placeholder text, make sure to specify both color
and opacity
. The latter is needed for Firefox, which applies opacity: 0.54
to ::placeholder
by default. If you don’t override this value, your placeholder text may have insufficient contrast in Firefox.
.search-field::placeholder {
color: #727272;
opacity: 1; /* needed for Firefox */
}
Declarative shadow DOM could help popularize style encapsulation
One of the key features of shadow DOM is style encapsulation, wherein the outer page’s style rules don’t match elements inside the shadow tree, and vice versa. In order to use this feature, you need to attach a shadow DOM tree to an element (usually a custom element, like <my-element>
) and copy the element’s template (usually from a <template>
element in the DOM) to the element’s newly created shadow DOM.
These steps can only be performed in JavaScript. If you’re only interested in style encapsulation and don’t need any dynamic functionality for your element, here is the minimum amount of JavaScript required to create a custom element with a shadow DOM:
customElements.define(
"my-element",
class extends HTMLElement {
constructor() {
super();
// find <template id="my-template"> in the DOM
let template = document.getElementById("my-template");
// make a copy of the template contents…
let content = template.content.cloneNode(true);
// …and inject it into <my-element>’s shadow DOM
this.attachShadow({ mode: "open" }).appendChild(content);
}
}
);
For an example of style encapsulation, see Miriam Suzanne’s <media-object>
element on CodePen. The scoped styles are located in the <template>
element in the HTML pane. Notice how this CSS code can use simple selectors, such as article
, that only match elements inside <media-object>
’s shadow DOM.
JavaScript may soon no longer be required to create this type of style encapsulation in modern browsers. Earlier this week, Chrome became the first browser to ship Google’s Declarative Shadow DOM proposal. If it becomes a standard, this feature will also make it possible to use Shadow DOM in combination with server-side rendering.
So cool that the BBC created their own font, but did anyone tell them they didn’t need 20 different variations of it? It looks like they have light, light italic, regular, medium, medium italic, italic, bold, bold italic, extra bold, extra bold italic versions for both serif and sans-serif fonts.
This takes 20 requests and loads 1.3MB of fonts.
I see where you are coming from, but perhaps they needed to have exacting control over their font because just adding italics or bold tags to text doesn’t get the desired effect. Personally, I use a font-set that has a light, regular, and semibold variation, because the CSS weight simply doesn’t cut it. I am satisfied with the CSS italics on this particular font, but the weight property doesn’t work. When I want a large font-size, I don’t want the scaled up weight/width that in inherent to raising font-size on “regular” fonts. And since the weight property doesn’t affect this font, I also embed a Light version which I use for headings. I detest rail-thin so I use a font that is just leaner on the Light version. So my headings don’t bulk up and wrap off the line. For the semibold version, it’s perfect for the key-words that need a slight increase weight – since the weight values don’t really work on the regular font-face. My site loads 4 fonts, which I am okay with. I don’t have 20, but then I am not the BBC News outlet. It would be GREAT if CSS would include a percentage or degree attribute that the user could control weight and italics better, then we wouldn’t need so many font sets.
When using focus-visible, it’s also important to keep your focus and hover styles in separate declarations for the sake of backwards-compatibility. If you wanted to do, say,
button:hover, button:focus-visible{ color: red; }
both the focus AND hover declarations would break on browsers where focus-visible isn’t supported.So cool that people are starting to considered visual impairments like dyslexia. I have both dyslexia AND several variants of scotopic sensitivity. I am a web developer – LOL. These are very common, affecting an estimated 40 or higher percent of the population. Dyslexia alone is over 25%. And digital text is a nightmare for those with scotopic sensitivities. I also have a convergence in my right eye that they cannot seem to pin-down a reason since my retina is intact. Yet I have better than 20/20 Vision.
Whenever When I look at colored text on my Android, it appears to pop forward or recede backward depending on the color, which creates a weird 3D affect when I look at text or graphics on mobile screens (not on PC). And colored text on colored background (like buttons) is even worse. Also having a dark background intensifies the 3D effect even more. Red and Electric or Royal blue are very very tiring on the eyes, but most news outlets use those colors. I also experience “rivers” and pick up shapes in the text or images and I experience waving lines and “marching” letters. Serif text like Times is a nightmare to read. And regular bolded text is bad. And aligning text to “justified: is horrible. centered text is also bad if you have a paragraph of wrapping lines.
So I appreciate when people consider visual aspects when developing their fonts. It makes a difference when people find your content easy to read. This is a matter that many web developers take for granted. I don’t torture myself to read content from a site that uses ridiculous fonts for body text or don’t use a font-set that has inbuilt weights – or if needed italics. People who don’t experience this think 99% of users have perfect vision. When you add presbyopia, myopia, hyperopia, retinopathies, macular issues, to dyslexia, scotopic sensitivity and weak vision, well-over half of the human population has at least one, if not multiple visual challenges.