I enjoyed watching Dimitri Glazkov’s introduction to Web Components Easy composition and reuse with Web Components, given at the Chrome Developer Summit. It’s an excellently-constructed talk that builds on the use-cases that web components address to make a compelling argument for the technology.
At 11 min 55 seconds, after a slide reading “Make HTML useful”, Dimitri says
Custom elements is really neat. It basically says, “HTML it’s been a pleasure”.
There we are. Bye-bye HTML; you weren’t useful enough. Hello, brave new world of custom elements. Of course, this isn’t the full messaging; a 20 minute video can’t go into the nuances. But it’s what a lot of people are hearing.
Let’s straighten that out.
One of the advantages of oh-so-boring HTML was that certain elements carried default behaviours in browsers and assistive technology. Like, when you use this mark-up
<label for="form-name">What's yer name?<label> <input id="form-name">
for="" attribute), and there’s a significant usability and accessibility advantage for the end-user.
A recent HTML5 Rocks article by Addy Osmani and Alice Boxhall called Accessible Web Components begins with the words
Custom Elements present a fantastic opportunity for us to improve accessibility on the web.
Yes. Yes. Yes. (Thanks Addy and Alice!) It’s perfectly possible to make web components and custom elements accessible. Alice has an example which I’ve screenshotted in Opera (top) and Safari (bottom).
Note that the first column does render in Safari, but it’s just normal checkboxes; they aren’t sexy web component-ised as they are in Opera. But – crucially – you can still interact with them, as they’re web components progressively enhancing silly old “useless” HTML. It works like this:
<input type="checkbox" is="io-checkbox">
Simple, huh? You have a silly old useless HTML element, and a new attribute that says “this is extended via web components into a special element I’m calling ‘io-checkbox'”. The web component inherits all the silly old useless behaviour like associating labels with form fields, activation with keyboard for free.
Compare with the sexy but not progressively-enhanced way that doesn’t work in older browsers (the second column):
<io-custom-checkbox tabindex="0" role="checkbox"></io-custom-checkbox>
There’s a super-whizzo-fabbo-megalicious UltraShiny custom element there, which has no graceful degradation. It needs a tabindex and a role there because who wants that silly old useless HTML behaviour? Not us! We’re post-HTML. Yay!
Snarking aside, why do so few people talk about extending existing HTML elements with web components? Why’s all the talk about brand new custom elements? I don’t know.
Of course, not every new element you’ll want to make can extend an existing HTML element. In this case, you can still make your custom element accessible. Just because you’re in the super-whizzo-fabbo-megalicious UltraShiny world of web components, you can – and should – still add ARIA information to make your code accessible. Just because you’re hiding nasty code behind the Shadow DOM, it doesn’t mean that you can brush proper coding under the web components carpet.
You’d hope that those who are assiduously pushing components into the platform would ensure that their demos did this – after all, those demos are meant to be studied, copied and adapted by developers, right?
Wrong. Take a look at Polymer gmail, a “Polymer version of New Gmail app”. Patrick Lauke points out
Google has expertise in-house to create functional, beautiful, web-component stuff that is also accessible. It would be great if high-profile demos like these would actually take advantage of those resources to create things that work not just for sighted mouse/touchscreen users…
To which he received the reply
There’s plenty that can be done in the convenience of unlimited time and resources. If you’d like to help, please submit a PR.
A big demo of a Google cutting-edge technology, made by Google, and there’s no resources simply to make it accessible.
At Paris Web, Karl Groves and I talked about Web Components – the right way, we talked of extending existing elements, adding ARIA and suggested that web accessibility advocates actively fix issues on Open-Source projects. But I meant fixing small projects that you’re using in your own sites – like the WordPress Live Comment Preview plugin, which I tweaked, thereby making 44,837 sites accessible.
I wasn’t talking about fixing demos by a company with a $362.48 Billion market capitalisation. As Patrick Lauke so eloquently puts it:
My resources are currently a bit more stretched than Google’s…but I’ll put it on my to-do list 😉
I’m a fan of web components. But I’m increasingly worried about the messaging surrounding them.