Web Components, accessibility and the Priority of Constituencies
Gosh, what a snappy title. I’m not expecting a job offer from Buzzfeed any time soon.
Today, Apple sent their consolidated feedback on Web Components to the webapps Working Group. The TL;DR: they like the concept, are “considering significant implementation effort”, but want lots of changes first including removal of subclassing, eg <button is=”my-button”>.
I think this is bad; this construct means existing HTML elements can be progressively enhanced – in the example above, browsers that don’t support components or don’t support JavaScript get a functional HTML <button> element. It also means that, by enhancing existing HTML elements, your components get the default browser behaviour for free – so, in this example, your snazzy my-button element inherits focussability and activation with return or spacebar withut you having to muck about with tabindex or keyboard listeners. (I wrote about this in more detail last year in On the accessibility of web components. Again.)
Apple raised a bug Remove the support for inherting from builtin subclasses of HTMLElement and SVGElement and notes “without this hack accessibility for trivial components is harder as more things have to be done by hand” (why “this hack”? A loaded term). However, it calls for removal because “Subclassing existing elements is hard as implementation-wise identity is both object-based and name / namespace based.”
Implementation is hard. Too hard for the developers at Apple, it appears. So Web developers must faff around adding ARIA and tabindex and keyboard listeners (so most won’t) and the inevitable consequence of making accessibility hard is that assistive technology users will suffer.
HTML has a series of design principles, co-edited by Maciej Stachowiak who sent Apple’s feedback. One of those is called “Priority of Constituencies” which says
In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more weight than costs to authors of the spec itself, which should be given more weight than those proposing changes for theoretical reasons alone.
Fine words. What changed?
Buy "Calling For The Moon", my debut album of songs I wrote while living in Thailand, India, Turkey. (Only £2, on Bandcamp.)
18 Responses to “ Web Components, accessibility and the Priority of Constituencies ”
Bruce –
but isn’t that an argument for better ability to re-style form controls rather than an argument against sub-classing?
Yes, and I am not convinced that a combination of both sub-classing and better styling is not a practical route. But smarter and more influential folk than I see sub-classing as a non starter and better styling capability as too hard, which leaves us with web components as shiny new packaging for a hoary bowl of <div> soup.
Then: bah.
Oh Brucey boy, I know you have more fight left in you than that 😉
Just to be nitpicky – the bug’s notes you quoted were pulled from Anne’s write-up on the WHATWG wiki. Seems safe to say that more than just Apple holds that opinion.
Love the “re-styling controls is too hard to spec and implement” thing. Web devs have been asking for that for more than a decade, and the best we got was an official blessing of appearance:none IN APRIL 2015, plus Web Components so that you can make your jQuery UI-like hacky components with a potentially less awful syntax (and probably worse accessibility for 99 percent of implementations than what jQuery UI does; but it’ll be Flat Design or even Material so who cares).
Oh well. Apologies for the rant. Had to get it out, after a decade of explaining to each designer and client that no, let’s avoid restyling form controls (or caving in, then spending days breaking performance and accessibility of the project \o/).
I’m most surprised to see Apple engaged in the discussion at all. Over the last few years it seems that having got what they need for Safari on IOS (and to a lesser extent the ITunes client) (video, viewport, etc.) they didn’t really care about the rest.
The design principles are sound. Of course, implementers will complain. And. of course, there will be mistakes. But if we’ve learnt anything from 10 years+ of W3C stasis by sitting on the HTML spec until a perfect replacement pops up, it’s that it’s better to have something rather than nothing.
The current pattern, which sees various prototypes in JS work out best practice which can then be hardcoded into the browsers, seems to be working quite well to me. And I’d rather it continued than more and more behaviour be JS framework specific: I’d much rather not download JSQuery-UI again and again and again.
Of course, most of all I’d like developers to rediscover how much you can do with the enhanced form controls of HTML 5 rather than reinventing the wheel.
All of this by way of saying that I don’t really understand the nuances of the subclassing argument except that it seems a red herring in relation to accessibility.
@charlie
But if we’ve learnt anything from 10 years+ of W3C stasis by sitting on the HTML spec until a perfect replacement pops up
Me thinks you have a misunderstanding of how spec development and implementation development work.
All of this by way of saying that I don’t really understand the nuances of the subclassing argument except that it seems a red herring in relation to accessibility.
may be helpful:
Custom Element Semantics
I’ve been involved with this discussion from the beginning and every day I am less confident that subclassing for accessibility purposes is actually a good idea. The problem is two fold. First, not having this removes nothing from the current accessibility picture – but it does add something in that it lowers the bar extremely, making it simple declarative thing for authors to get it right by simply choosing custom elements that are accessible. We have seen in the past, some popular libraries invest time and pull requests to help improve them – and they are comparatively much harder to use and lack the good abstractions that make HTML simple. In other words, I see a real opportunity by the simple fact that they are reusable for simple the ‘slang’ of the web to provide a net increase in accessibility even without this feature. Beyond that, and in many ways more importantly to me – the bolt-on nature actually seems to add confusion to me. One problem we’ve always had in HTML is that people author documents that aren’t ‘right’ – it’s a common thing to put elements in places they don’t belong, for example. The more bullet-proof you can make that the better and saying that you can inherit everything that it means to be something falls apart fast and leads to new potentials for misunderstanding… Take for example, an input or a select – how could you meaningfully attribute all of their behavior to some other structure ‘automatically’ – and then even enhance it? I wager you really can’t… It’s tough to say ‘this is a select’ but then have it contain rich content that gets a privilidged rendering that can overlay the window and traps keys correctly and participates in form input and so on – But you can with aria because it has all of the bits you’d need to approximate it well. It seems just as likely that you’d be more frustrated trying to understand what dark magic is afoot when it doesn’t do as you expect.
Discussions about extending native elements via Web Components highlight the fact that what we need most often is the ability to effectively style form controls, as mentioned. I suspect this would reduce the need for is="" in most cases, although I am in favor of it due to its declarative nature and progressive enhancement opportunities. There is obviously more to figure out with regards to Shadow DOM, which Alice Boxhall and others are researching at the moment, but I don’t think that should hold up progress on something that is already rolling.
Focusability is obviously a huge part of this–although we have tabindex and ARIA, the bolt-on nature of attributes make them easy to get wrong. Anything we can do to set developers up for success should be a priority. Having downstream developers in the room with spec writers and browser implementers at the Extensible Web Summit seemed productive, as user needs were floated up and heard (hopefully). There is a real opportunity to improve accessibility through these discussions, whether with lower-level primitives or extending native elements, but they completely depend on how this moves forward. Shouldn’t the whole point of extending the Web be to solve actual problems, not create (or ignore) them?
@brian
One problem we’ve always had in HTML is that people author documents that aren’t ‘right’ – it’s a common thing to put elements in places they don’t belong
This happens rarely with interactive HTML elements as they have stong interaction semantics.
First, not having this removes nothing from the current accessibility picture – but it does add something in that it lowers the bar extremely, making it simple declarative thing for authors to get it right by simply choosing custom elements that are accessible.
huh? how does it lower bar, when it raises bar for web component developers to make simple commonly used UI controls accessible?
Take Strand Web Components as an example, proudly states “We’ve built Strand atop Google’s Polymer framework.” oh good i think, polymer is doing good stuff accessibility wise “Why build on Polymer? Polymer provides essential sugar” it says. Then have a look at the Strand UI buttons, checkboxes, radio buttons and headers (sic) DOH!
There is nothing in the above <mm-div> soup that could not or should not be achievable with standard HTML features.
@steve
You’ve misinterpreted what I said, let me try to paraphrase: I said it lowers the bar for users of custom elements and changes nothing from today’s norm for custom element authors. It lowers the bar by saying you don’t need to memorize custom recipes of classnames and attributes and include javascript in the right bit of the lifecycle and potentially call ‘ready’ methods, etc as you do with a number of UI libraries out there today. Its a simple declarative tag <x-foo>. If a better (in terms of accessibility or anything else), but API surface compatible version of <x-foo> comes along, you can simply include that element instead and your code doesn’t change. This, in turn, allows authors and experts to focus on building (or improving) the state of custom elements – not 100 entirely disparate libraries with their own philosophies about everything… Thus, I argue, it is actually a net positive before you go any further. The simple fact is, those people are going to use custom things already, this helps us draw a box around the problem space.
re: interactive things have strong interaction semantics… Can you demonstrate how you can generate a truly new <x-select> or <x-input> out of div structures without aria and explain how they would work by just saying “oh, btw, this is a select”? I can’t understand how the browser could realistically know how to map those semantics to your new structure appropriately in all but the very very simplest of cases.
not 100 entirely disparate libraries with their own philosophies about everything…
Are we not already seeing this happening with web components? polymer, strand, x-tags, deliteful, to name a few.
Can you demonstrate how you can generate a truly new <x-select> or <x-input> out of div structures without aria and explain how they would work by just saying “oh, btw, this is a select”?
Why do I need to demonstrate this, I have never claimed it, suggest you have misunderstood me. What I was saying: for a non insignificant number of web components the semantics and interaction are the same/similar to existing native features, in those cases it would be useful to make the native features usable by web developers for what they were designed for, rather than encouraging the complete re-invention of the wheel.
Are we not already seeing this happening with web components? polymer, strand, x-tags, deliteful, to name a few.
Yes and no, there is a difference. Currently “How do you express an ” involves answering a ton of questions: how it gets into your page, what is its lifecycle, which library’s peculiar abstractions and way of the world is it built on for everything? It is all JavaScript? Does it use complex tag/class recipes? Consider for example tabs in extjs, dojo, jquery ui and any that you noted. They are racdically different at very fundamental levels. The problem is that there are 5 competing ideas, that’s actually kind of healthy – failure to become the standard *has* to be an option… Instead, I propose that the *real* problem is that they have no healthy way to compete and because they have to invent from 0 they can’t just compete on the surface, they’re competing at all levels. What I’m saying is that this lets them compete at a high level, there should be fundamentally less of them and they can even be interchangeable in some cases so you can trade up for better functionality/quality. A big part of the problem is that there is no way to do this in a lot of ‘answers’ today. By merely changing the parameters, we’re going a long way.
What I was saying: for a non insignificant number of web components the semantics and interaction are the same/similar to existing native features…
Ok, then let me rephrase – can you show me a non-trivial list and pick one that isn’t trivial and show me how they could simply say “I am that” and somehow the browser could appropriately understand it? I’m not saying you’re wrong, I just don’t see it and definitely need it to be illustrated.
I think my main issue with @is is that it doesn’t give me the ability to do most of the things I really need to do with native elements like button, input, select, etc.
The very elements for which accessibility is most critical and difficult are the very ones for which extension via @is is least useful to apply the the modifications I have needed to apply hundreds of times over the years.
For example, take a native/standard select. I can use @is to apply some specific styles using one technique or another. But the element isn’t in a shadow DOM with @is, so I get no scoping. And I still have the fundamental issue I had before with select, which is that I can barely style it. I can sort of style the initial closed appearance, but I can’t use flexbox layout to do it. Nor can I do anything about the dropdown part of the menu or the mobile full-screen pop-up selection list. I can’t add a material design style ripple to the highlight-selection.
Yet I want the keyboard focusing and navigation via arrow and letter of the alphabet. I want assistive technologies to know when stuff is opening and closing and all. I want to the selected option’s value to be submitted with the form. I want the full-screen pop-up selection list on mobile.
All these years, have we been begging for ways to add custom methods to select elements, or to be able to customize their appearance and behavior as interactive elements?
I know that people have been arguing over this for at least a decade. For accessibility, should we use platform controlled widgets or not? How much customization and styling should be allowed? If we give them too much freedom, they’ll eff it up and make it less accessible!
But, frankly, I think it’s well established now that consistency of UI across web apps on a Windows machine is not more important than consistency of UI within that web app. And that product and UX and visual designers are going to keep asking for these customizations. And that, if developeres can’t effectively customize the native elements and keep their accessibility, they’re going to recreate them from scratch with poor accessibility and eff it up anyway.
So why aren’t we standardizing that–I know people have tried, I’m just saying… Until there’s a proposal that allows useful customizations of the sort that we see constantly on nearly every web site and app ever while maintaining accessibility of the elements, arguing over @is seems like empty noise, because there’s no reason to use @is in the first place versus what we’ve been doing.
(Not, mind, that being able to extend the DOM interface of an element–or create one–isn’t useful, it IS, just not hugely so here.)
I think there are cogent arguments as to why sub-classing does not solve the problem. Primarily subclassing of a control that has UA styles that cannot be overriden, does not make it an attractive choice for developers (suggest UA imposed styling constraints are what make developers roll their own UI controls in first place). This problem is one that is continually punted by implementers, as it is too hard to fix. Web components as a technology does nothing to improve this, it only replaces <div> and <span> with <x-div> and <x-span> leaving the expression of semantics and behaviour to bolt-on, like it’s precursors, the now ubiquitous javascript UI frameworks.