Web Components: concerns and opportunities

Warning This article was written over six months ago, and may contain outdated information.

On the 21st of March I had the pleasure of participating in the Web Components panel at Edge Conf, and the privilege of giving the introduction to the panel. I’m a strong advocate of Web Components and it was great to be able to provide my opinion on them, alongside some real experts in the field, as well as hear questions and feedback from the community. The main concern which was raised is that, as developers create their own elements, some important considerations – accessibility not least – could get forgotten about.

If you want to see the panel in full – or, if you’re not sure what I’m talking about and just want to watch my ten-minute introduction – the video has been made freely available:

[youtube=http://youtu.be/e29D1daRYrQ&w=580]

The discussion continued after the conference, on Twitter and blogs. Jeremy Keith looked at the accessibility angle, saying:

Just adding more and more predefined ARIA roles won’t cut it—we need some kind of extensible accessibility that matches the expressive power of Web Components.

Paul Lewis took a broader view, and echoed a potential pitfall I mentioned in my introduction, which I dubbed the proliferation of crap:

Since by default there is very little that enforces good accessibility, security and performance, we’ll end up with a load of components that are terrible, with no way for developers to sort the wheat from the chaff.

My co-panellist Soledad Penadés perfectly summed up what I believe is the key to the whole issue:

Web components are just a tool that will enable you to write better and encapsulated front end code. They are not a silver bullet that automagically makes everything work.

This, I think, is the message that needs to be drummed in. Web Components are a way that we, the web developers, get access to lower level APIs, allowing us to create our own elements, bypassing the implementation and standardisation process. It gives us much more freedom – and much more responsibility. While standardisation can be slow, it means that UI elements implemented in browsers have the benefit of long consideration of usability and accessibility; as we move more rapidly to create our own, the burden (and I don’t mean that to have a negative connotation) of creating usable, accessible elements is placed onto our shoulders.

The problem with that is, as Bruce Lawson said:

The primary impediment to accessibility on the Web isn’t technical, it’s social. It’s that many (most?) developers don’t give a toss.

Mairead Buchan has done some thinking about that:

The problem, as I see it, is we have no mechanism for quality control and no platform for promoting the best we have to offer. This is a perennial problem with our development stack.

Her proposed solution is this: a community upvoting platform that lets us collaborate on best practise in front end code. I think that’s definitely an idea that’s worth looking into, and the team at webcomponents.org are already on the case. The idea is that the platform could act as a filter for the proliferation of crap, promoting best practices until we arrive at a set of community-made components that can be submitted back to browsers for native implementation. And that’s what makes me most excited about Web Components: the things we make can define the future of the things we make.

I also want to say that I’m delighted that the Edge Conf panel has provoked the debate around this subject. If we’re going to assume this great responsibility, we need to hear everyone’s opinions.

Update: A round-up by the conference organisers, which tells me that our panel was one of the most enjoyed, and I was voted fourth in the list of stand-out contributors! Thanks to all who voted.

Comments are closed.