By Cristiano Correia
a11y and the new Web Standards
The new Web Standards are evolving fast, and sometimes it’s hard to actually know the current state of a particular subject in a sea of subjects. I often realize that the vast majority of web projects start without having Accessibility (a11y) in mind and it becomes daunting to go back and fix it.
Since there are still many Web Components projects yet to be born, I decided to gather up the 101’s about those particular subjects and guide anyone sailing in these seas for the first time. So in this article, you will find:
- The basics about Accessibility
- The basics about Web Components
- What’s new regarding CSS
- How can you make your Web Components more accessible
Let’s sail.
Basics #1. What’s Web Accessibility?
“Accessibility is often viewed as making your site work on screen readers. In reality, web accessibility is a subset of User Experience (UX) focused on making your websites usable by the widest range of people possible, including those who have disabilities.”
The above quote (from Dave Ruppert on “Myth: Accessibility is ‘blind people’” for the a11y project) reflects the biggest challenge about Web Accessibility: knowing exactly what it is.
Web Accessibility is essentially a way of giving access your product to all your potential users.
The 5 categories of accessibility to take into account are:
- Visual (e.g. non-sighted, myopia, color blindness, etc.)
- Auditory
- Motor
- Cognitive
- Temporarily disabled users (e. g. one-handed phone users)
If we need to translate those into a product, it usually means being concerned about:
- Semantics
- Keyboard inputs
- Text alternatives
- Color Contrast
In order to take that into account while developing a product, you should:
- Make sure you convey meaning through not only color but also form
- Make sure your product is resizable
- Make sure your content subjects are distinguishable
- Make sure you follow the guidelines from the W3C in general
…and don’t forget about the Accessibility Tree! It is the
“structure produced by platform Accessibility APIs running parallel to the DOM, which exposes accessibility information to assistive technologies such as screen readers” (source).
Basics #2: A Brief History of Web Components
Web Components, in their essence, are actually “nothing”: Web Components are a set of new Web Standards that help us achieve a native way of making Components. In broad strokes, I would define Web Components as:
A native way to achieve a small and re-usable set of logic, behaviors and interface elements, through a series of browsers standards.
So, what are the building blocks of Web Components?
- HTML Templates
- Shadow DOM
- Custom Elements
- …and HTML Imports (-ish)
HTML Templates
HTML Templates are a form of re-using pieces of HTML without the original “template” being rendered on the page.
It works as follows:
Which will render something like this:
You can check how HTML Templates are currently being supported by browsers on this caniuse page.
Shadow DOM
Shadow DOM is a way to achieve CSS scoping, DOM encapsulation, and composition, making it easier to build isolated components.
There’s two modes of achieving Shadow DOM: “closed” and “open”. The difference is that when you instance element.shadowRoot, the “open” mode returns the HTML node and the “closed” mode returns null. Both modes return null when you try to query the DOM. Bear in mind that you have to set a mode to use Shadow DOM since there is no default value for it.
It works as follows:
Which will render something like this:
And the DOM tree will look something like this:
You can check how Shadow DOM is currently supported by browsers on this caniuse page.
Custom Elements
Custom Elements are the way to achieve full re-usable encapsulated pieces of logic and have the best from Shadow DOM and HTML Templates, including slots.
All this can be achieved by the following:
Which will render something like this:
You can see the Template “Slots” being replaced accordingly
You can check how Custom Elements are currently supported by browsers on this caniuse page.
…and the -ish: HTML Imports vs. ES Modules
HTML Imports were a big part of the Web Components standards, but they’ve stopped being supported and no longer are listed on the Web Components page (being replaced by ES Modules). They’re no more than a footnote at this point in Web Components history. As Wilson Page from the Firefox OS team puts it:
“We’ve been working with Web Components in Firefox OS for over a year and have found using existing module syntax (AMD or Common JS) to resolve a dependency tree, registering elements, loaded using a normal