On the accessibility of web components. Again.
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">and you click on the label, the focus goes into the associated input. There’s no need for JavaScript, there’s no fancy stuff extra for a developer (except setting up the association with the 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 in the Safari screenshot, the second column of sexy checkboxes don’t work at all – there is no checkbox. That’s because Safari doesn’t support web components. You’ll see the same in IE, or browsers without JavaScript.
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.
Buy "Calling For The Moon", my debut album of songs I wrote while living in Thailand, India, Turkey. (Only £2, on Bandcamp.)
16 Responses to “ On the accessibility of web components. Again. ”
The issue of not extending existing HTML elements is exactly the same that we’ve seen all this time, even before web components: developers who are tip-top JavaScripters, who already plan on doing all the visual feedback/interactions (for mouse users like themselves) in script anyway themselves, so they just opt for the most neutral starting point…a div or a span. Web components now simply gives the option of then sweeping all that non-semantic junk under a nice, self-contained rug.
Why aren’t web components required to be created with is=”some-component” on an existing HTML element? This seems like an obvious approach; sure, someone who wants to make something meaningless will just do <div is=my-thing> or (worse) <body is=my-thing> but it would provide a pretty heavy hint that you’re supposed to be doing things The Right Way, and you’d get basic accessibility stuff thrown in for free.
Since this ship has probably sailed, it might be worth pursuing HTML linters, code checkers, and so on to treat <my-thing> as a thing to be warned about and recommend using is to extend a real element instead?
Thanks for this, Bruce.
This is how I see it: Web components aren’t new HTML, they’re just new packaging for old HTML. That being the case, I agree that the problem is entirely in the message (or marketing).When it comes to end user accessibility, web components are Coke Original; the same old thing but branded to seem new. All the old challenges are there. There’s no more an “opportunity” to make things accessible than there ever was.
The accessibility boon with web components – if any – is that they make HTML easier for the less technical to author. All the fearsome guts are tucked away neatly inside the slender torso. But if we (read: the Polymer team et al) are creating web components _for_ content authors and time-poor devs that are (to stretch my analogy) gutless, then we’re back to square one.
I think there are *a lot* of people out there stressing the right way to build web components – perhaps, according to my anecdotal evidence, as many if not more than are *not* stressing the right way. I refer you to the estimable Steve Faulkner’s Web Components Punch List (http://www.paciellogroup.com/blog/2014/09/web-components-punch-list/), Addy Osmani’s FIRST principles (http://addyosmani.com/first/), and, if I may toot my own bugle, my own recent talks (https://speakerdeck.com/stopsatgreen/web-components-what-why-how-when). And your own good self, of course.
Hi Bruce,
Google also has an Angular Material effort to provide material design components for web developers who use AngularJS 1.3 and later. We’re still in pre-release state (we have a list of about 20 things still to get to under the accessibility aria tag for the components we’ve built, and more components on the way), but you can see a demo at http://material.angularjs.org and Marcy Sutton recently blogged about our overall approach in Angular here: on the AngularJS blog. Our approach is to build as much of the ARIA complexity into the framework as possible, so that developers find it as easy as possible to just build things that work.
I’d welcome comments on our approach as well. Our mailing list is ngmaterial on googlegroups or you can file issues on github.
Bruce, this is a well thought out article. I completely agree that componentizing shouldn’t mean we should brush poor accessibility and bad code under the carpet.
However, it is unfair to point out Google’s evaluation when really it’s just a team of 10 – 15 people working on this project. The Polymer gmail app is a work in progress as the first line in their readme claims. While they should have responded more appropriately to the issue, its not fair to review it as you would a final product / demo.
Of course, it’s just a demo…but, just once, it would be nice to see the absolute basic level of accessibility consideration being given at the start of a project, rather than much later trying to retrofit accessibility back in (which usually makes matters far more difficult, resource intensive and time consuming, ironically enough). We’re not asking for perfection…just if the very first button you encounter in the demo can’t even be activated with the keyboard, you know you can simply not bother checking out the rest…
There is a significant “accessibility risk” for [io-checkbox][/io-checkbox] in the markup of a landing page, since it depends on all the following:
1. Browser scripting being enabled
2. The polymer script loading
3. The polymer script not breaking in the browser
4. The custom-element definition loading
5. The custom-element definition not breaking
6. The custom-element being coded for accessibility
However, for HTML generated in the browser you could detect the failure of 2-5 and either
– generate HTML without the custom-element(s), or
– not generate anything (assuming the web-site gracefully degrades)
IMO this is the place for web-components (at least for now). Generate POSH pages on the server and then – if your web-components environment configures correctly – enhance, stitch, transform, spindle, mutilate your server generated content into submission in the browser.
Well, yes, no surprise. If accessibility isn’t automatically part of the system, then people won’t implement it as additional work. This was always going to happen when the IE6 de facto standard died.
To repeat: accessibility is not a general concern for content developers/coders. If The Standard Way You Do Things produces accessible output, all is well – INPUT, TEXTAREA, etc. As soon as The Standard Way You Do Things doesn’t produce accessible output, it won’t happen.
HTML “1” was text only – all accessible. The IMG element came along – inaccessible. But the alt attribute comes along to fix it! And how many images use alt correctly? Twenty years later? Whoops! That’s the absolutely simplest example: inaccessible output by default doesn’t get fixed.
That’s why WAI-ARIA won’t work. It’ll be a constant round of lobbying content creators to implement WAI-ARIA on their inaccessible websites, which they’ll maybe do, until their next upgrade with the latest widgets and we’re back to square one.
It’s the same situation as the UIA/MSAA standards on Windows. Microsoft can’t even get Office to comply. If your WinForms/Win32 application works with UIA/MSAA when you compile it, that’s just about usable. Anything else for accessibility needs work, and that never happens. The new toolkit comes along, its output is inaccessible, it maybe gets fixed after a while, everything is stuffed in the meantime, and next upgrade – broken again.
(NB Implicit accessible == blind/screenreader in the above.)
The main message I get from the the Google/polymer devs is that
(a) accessibility can’t be built into the dev life cycle from the start, it has to be added.(Reasons unknown)
(b) components on the polymer site (such as paper are only previews and it should not be expected that they are fully or even partially accessible yet.
I don’t understand (a) and no actual reasons for this have been provided, though Alex Russell has threatened to provide details. (b) is understandable to an extent, but if so the current and intended support state for each component should be documented and developers should be made aware that the components are not fit to re-use or use as examples of how to code.
web components can be done right, even by industry behemoths:
IBM(market cap 162 billion $$) are doing web components with accessibility documented, integrated 0.5.0-alpha
Anyone ever talked about a JavaScript conspiracy? Informational websites should be accessible with JS disabled. It feels like it’s going the wrong way.
Let’s put this discussion in a wider context, beyond ARIA.
We all know the industry makes more money with users having JS enabled, so I think we all agree there is non-technical incentive to push JS.
But JS has a (hidden) cost for the user. Security, privacy and economical (battery usage/more KB´s).
And I still wonder why I cannot install/run a program on my computer without accepting their terms of service before use, while myriads of companies run programs/scripts daily on my computer/phone/device without even asking me, and WITHOUT me visiting there sites (which could be implied consent).
We have cookie legislation in the EU, (which is a disaster BTW), but scripts (tracking/fingerprinting/logging) are more dangerous (security/privacy) than cookies.
Why is Facebook running scripts on my devices daily, I have no deal with them, and I don’t want it.
There is something fishy with the push for scripting on the internet. There are not just accessibility-, but also economical and legal issues involved.
Companies push JS, the only places where you can watch HTML5 video with JS disabled, are textbook examples. JS makes more money then HTML.
“… silly old useless HTML element …” Indeed I can only warn of jumping on ever the next band-wagon just for the sake of “being modern”. I often see such presentations on “new” functionality and when I think a while and hard enough (we have to set aside time for that – plain and simple!) I “remember” that the same functionality could well be mapped into “old” HTML and be done with it and may even work in some legacy browser some kid uses in some rural African “backwater” because he/she can’t afford any new computer to run bulky software.
C’mon Bruce, there’s one of Patrick who probably has plenty of spare time to volunteer, and there’s only a dozen people being paid by one of the richest companies in the world who are trying to promote this as a great new way to do things.
Seems fair to me that they insist he do the work of showing how their wonderful new technology could meet the real working requirements of millions of developers, so they can continue focusing on adding shiny unicorns.
“why do so few people talk about extending existing HTML elements with web components? Why’s all the talk about brand new custom elements?”
answered by
“There’s plenty that can be done in the convenience of unlimited time and resources.”
See that word “convenience”? It’s not convenient to have to actually think of annoying things like web standards or, you know, actual humans using your stuff.
That’s my take. Drop shadows and gradients? Those are necessary things, taking zero time and resources! Keyboard functionality? No convenience.