Archive for the 'accessibility web standards' Category

Reading List

The <picture> element

I proposed it 2.5 years ago. Loads of cleverer people worked hard on it. The RICG is holding a fundraiser to pay developer Yoav Weiss to code it in Blink and WebKit. Opera (my employer) contributed $1000, dozens of individual developers – people like you – pledged money as well.

The inital target of $10,000 has been reached, but don’t let that deter you from contributing – it means Yoav can work for longer, and maybe even have a break for a coffee and a piss now and then. (Coders, eh?)

Standards ‘n’ Shiz

Industry n Stuff


Notes on accessibility of Web Components

At Edge Conference on Friday, Peter Gasston unmasked me as a secret accessibility wanker by saying “For a proper in-depth look at a11y in web components, see @brucel – he’s just spent weeks researching it for a talk next week.”

Well, not weeks, but I confess to reading around the subject (A lesson on rendering trees, emerging technologies and tacos), and had some chats with the ever-helpful Addy Osmani and The Mighty Steve Faulkner as well as (gasp) thinking a bit.

(If you plan to attend my talk at Funka conference in Stockholm on April 8, please stop reading now. Or read on, and go to someone else’s talk.)

If you don’t know what Web Components are, I recommend starting with Peter Gasston’s A Detailed Introduction To Custom Elements or his excellent introduction to web components at Edge Conference.

Very, very crudely: Web Components will allow us to extend existing HTML elements, and create our very own not-HTML-but-they-look-like-it elements with JavaScript.

“Real” HTML elements have built-in behaviours. Something like a <button>, for example, can be focussed; it can be activated by the keyboard, and when it’s activated it does something. Developers don’t need to add anything to the button element to get these behaviours; they’re given to us.

However, some developers love wheel-reinvention (it can make a diverting break from yak-shaving). So we get vile messes like this, that emulate <button> but which aren’t <button>. Therefore, to make it accessible, it requires tabIndex to make it focussable, JavaScript to listen for clicks and needs ARIA roles to let assistive technology know what this tag bukkake is supposed to be:

<DIV id=:rk class="J-K-I J-J5-Ji L3 J-K-I-JO" tabIndex=0
unselectable="on" closure_hashCode_l16mgm="182" act="">
<DIV class="J-J5-Ji J-K-I-Kv-H" unselectable="on">
<DIV class="J-J5-Ji J-K-I-J6-H" unselectable="on">
<DIV class=J-K-I-KC unselectable="on">
<DIV class=J-K-I-K9-KP unselectable="on">&nbsp;</DIV>
<DIV class=J-K-I-Jz unselectable="on">Search Mail</DIV>

(The example is from Steve Faulkner’s 2010 article HTML5 and the myth of WAI-ARIA redundance. “Tag bukkake” is defined as “nastier than tag soup, and far more in your face”.)

In The Future™, you’d be able to extend <button>, so add all kinds of extra <div>s for hanging styles off etc, but without having to reinvent the base element. You’d need JavaScript, to define and register your omg-look-at-my-sexy-button element of course, but your basic markup would be

<button is="omg-look-at-my-sexy-button">

and User Agents that didn’t support JavaScript would fallback to showing a <button>.

You can also make your own custom elements with no fallback, too. But whichever way you choose, you need to add all the ARIA information and tabindex yourself. I don’t think this is misuse of ARIA; the ARIA spec says

WAI-ARIA is intended to augment semantics in supporting languages like HTML and SVG… It clarifies semantics to assistive technologies when authors create new types of objects, via style and script, that are not yet directly supported by the language of the page, because the invention of new types of objects is faster than standardized support for them appears in web languages.

Given that the whole point of Web Components is to add “new types of objects, via style and script, that are not yet directly supported by the language of the page”, this seems to me a pretty good fit.

But enough theorising – how well are Web Components supported in assistive technology?

The answer is, pretty well (although Some stuff that doesn’t work between the DOM and Shadow DOM).

That’s actually not too surprising; although Web Components and Shadow DOM can hide things from the “real” DOM of the page (by design), the browser mashes them all together to render them, and assistive technologies sit on top of browsers. Of course, if the developer couldn’t be bothered to add ARIA information etcetera, they may not be accessible – but the fact they’re encapsulated in a component doesn’t make it better or worse than if they’re in the page in the traditional way.

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. One aspect of Web Components is that they can be shared and imported into the HTML – think of server-side includes, but client-side.

  <link rel="import" href="/path/to/imports/stuff.html">

(More at HTML Imports #include for the web.)

I had a vision of a big CDN (like Google’s Web Fonts or hosting of jQuery) but Addy Osmani told me that including from third party CDNs could be a performance problem. Nevertheless, we can expect lots of Web Component libraries to spring up, and people saving them locally, using their build processes to check they have the latest versions in their directories for inclusion at run time.

I don’t think it’s necessary for me to urge developers to put the source code of the Web Components they write onto Github for forking and collaboration. Please do that, and make it easy for people to contribute, so that people who notice accessibility holes can send pull requests.

A while ago, on this blog, I got an email from a screenreader user telling me that the live comment preview below the comments box needed an ARIA live region to be accessible. It was a WordPress plugin, with the source code on Github. I sent a pull request and, a couple of days later, the developer merged my one-line change latest version of the plugin. That’s my site, and 43,410 others, made more accessible through one pull request.

Christian Heilmann recently wrote that we need more “passion” in accessibility, “Not another library to add ARIA to badly thought-out HTML“.

I disagree. If passionate evangelism were enough, the web would be perfectly accessible now. My message to accessibility advocates is “passion – great. But with pull requests, please.”


  • Web Components and the Three Unsexy Pillars by Paul “it’s not my round” Lewis. “I believe we need some open and community-driven way of vetting and ensuring Web Components are accessible, secure and performant. While we figure out what that means, let’s not be fooled into thinking that Web Components can fix bad development”
  • “document[s] web components best practices so that others can follow the same path”
  • The golden path announcing “A community upvoting platform that lets us collaborate on best practise in front end code” by Mairead Buchan
  • Plans for repo of good web components: “Section for peer-reviewed Custom Elements” by Addy Osmani

Reading List

Reading List

Monday meh: Android “fragmentation”

Welcome to the first in an occasional series called “Monday meh”, in which I briefly fulminate about something that made me a bit grumpy.

Occasionally, web pundits complain about Android fragmentation. “Fragmentation” is Punditese for “oh dear me, I hate diversity because it makes my job so hard”.

If there were only iPhones, the job of web developers would be much easier. But, of course, most people in the world would then have no access to the Web. Call me “Captain Priority of Constituencies” if you want, but denying most of the world access to the Web in order to make a few people’s lives easier is what computer scientists term “getting it wrong” and “missing the point”.

It’s like being a bartender and complaining that your job would be so much easier if no customers ever bothered you while you’re polishing glasses and reading your Mixology books.

Disagree? Please meh my meh.

Reading List

Bridging the gap between native and web

  • Installable web apps by PPK: “The mobile browser “bookmark” function should become “install” and place an icon on the home screen. This icon starts up the web page or web app; likely from local memory.” Good article, though I disagree with the idea that the web app is a local copy – that’s re-inventing Widgets. It should be the live, instantly-updatable web site, “offlinerificated” with Service Workers.
  • Meanwhile, Google’s Paul Kinlan disagrees: Add to Home Screen Is Not What the Web Needs. Is It?
  • Manifest for bookmarking web applications draft spec
  • A Review of apps that use network information – research by @marcosc on whether such API on Web is needed (or possible)
  • The state of standalone apps on iOS – “we examined 360 web applications that claim to be capable of running “standalone” in iOS (i.e., the web application asserts that it’s usable outside the context of iOS’s default browser). We put those claims to the test by manually checking if the apps could, in fact, be used as standalone.”
  • Service Worker + Push API – “outlines an API which integrates with the Service Worker to enable delivery of push messages to applications which do not have visible tabs”
  • Media playback restrictions in Blink – “Blink and WebKit have a setting for requiring a “user gesture” to play or pause an audio or video element … this gets in the way of reasonable use cases like games or playlists, and developers are not impressed … as an experiment we’ve removed the restrictions in Opera beta for Android. However, I’ve also found a workaround for current browsers.”



Reading List

Regions to be cheerful?

The Web has been buzzing with the news that Blink has said “nope” to Adobe’s CSS Regions spec. Here some hand-picked links about that, and the general state of CSS Regions spec.

Other suggestions for text fragmentation are available, such as CSS Overflow Module Level 3, CSS Fragmentation Module Level 3 and (related) CSS Figures.


  • HTML is too complex – “unless there is an immediate visual or behavioural benefit to using an element, most people will ignore it”. Some real food for thought in this sentence.
  • A World Managed By Apps Is Closed For Those Without A Smartphone – “Every time you make a service or device that can only be managed from an app, you are basically adding to a systematic poor tax. You make it easier for those comfortable, with great smartphones in their hand, to get shit done, while not spreading that benefit to those without the magic box. You deepen economic entrenchment.”
  • Why is Progressive Enhancement so unpopular? by fellow old-timer, Drew McLellan
  • [HTML Imports]: Sync, async, -ish?. If you’re importing a web component (you hypercool ninja, you) should the whole render be blocked until the component can be drawn? Of course not, argues Jank Archibald persuasively. Elsewhere he writes, “Instead, we should follow the default behaviour of <img>. An <img> doesn’t block parsing or rendering, the image appears when it is loaded. The developer can reserve an area for the image to change the reflowing behaviour.” Not as daft as he looks, that Jake.
  • Why does this spec replicate HTML features? – Imagine we have a manifest file for web apps, that pretty much duplicates what HTML can do with <meta> elements already. If both are present, which should “win”?
  • Nine Things to Expect from HTTP/2 by Mark Nottingham, chair of the IETF HTTPbis Working Group. So he knows.
  • will-change: a CSS hint to browser that you know its appearance will change, so it can make any optimisations, eg paint it to another layer immediately for faster animation. Replaces hacks like translateZ(0) and -webkit-backface-visibility: hidden.
  • Pointer Events Progress: Mozilla and Blink Communities Reach a Significant Engineering Milestone – synergies between Microsoft, Blink and Mozilla. Who’s missing, I wonder?

Scampi Bug Yeti

As Mike Taylr points out, “Scampi Bug Yeti” is an anagram of “Spec Ambiguity”. Sometimes, people moan that the specification process of web standards is grindingly slow and laborious with too much detail etc. But the reality is that specs that are amibiguous or not tightly defined cause problems with interoperability. For example,

Reading List

Articles that I’ve tweeted this week. Not necessarily fact-checked, or endorsed.


Browsers, techniques, resources

I’m taking a break to get some sun and even a bit of culture. Blog comments are disabled to stop comment spam. See you in a little while. XXX

I met the TAG

Last night I dragged my carcass down to London in order to meet the W3C Technical Architecture Group (TAG). This is the group that advises other W3C working groups on architectural matters – most notably (for Web developers) API design.

Co-chair Dan Appelquist blamed me for this event; after the inauguaral Meet the TAG last June, I suggested that follow-up events be more structured and have a public Q&A, if only so the TAG Team didn’t have to answer the same questions repeatedly as they mingled.

On stage, but not expecting the Spanish Inquisition, were Anne van Kesteren (Mozilla), Sir Tim Berners-Lee (W3C Director and Olympics opening ceremony eyecandy), Alex Russell (Google), Yehuda Katz (Ember.js, Ruby on Rails and jQuery Core Teams) and Dan Appelquist (Telefonica). Other taggers in the audience were Peter Linss, Dame Jeni Tennison, Henry Thompson and Sergey Konstantinov.

Anne introduced the TAG as saying that it attempts to ensure that W3C APIs are designed in adherence with some core principles. I asked what those principles actually are. The reply (mostly from from Alex Russell, Tim BL and Yehuda Katz) was that many older APIs don’t feel particularly webby; that’s because they were generally designed by those who code browsers in C++, and C++ isn’t the same as JavaScript. As we’ve progressed, we’ve generally got better but there are still inconsistencies and weirdnesses from time to time.

We have lots of high-level APIs but we need to get to what’s underneath. For example, every browser has image decoders (that turn PNG, JPG, GIFs into bitmaps) but how can we access them? We can’t. Where is the API that allows us to tell an <img> element to defer loading? There isn’t one.

So we need to do what Alex Russell called “archeology” – define each layer in terms of a lower layer. Yehuda used HTML5 appcache as an example; it does a whole bunch of things but, if those turn out not to be what you want, you’re stuffed. This is why Service Workers were invented, and it’s important to note that it’s possible to write AppCache’s higher-level functionality in ServiceWorkers. This layering is described in the Extensible Web Manifesto (which isn’t a TAG document, but which is signed by many TAG members as well as the glitterati of the standards world).

Tim BL pointed out that access to very low level was common in native app programming languages, and becoming so on the web but more parity is needed. The fact that we’re now calling it “Web Platform” is more than a marketing-led rebrand.

Then followed an unedifying discussion about DRM – Digital Rights Management – or Encrypted Media Extensions as the extension to HTML is delicately called. (Contrary to unpopular belief, it’s not part of Core HTML.)

I say it was unedifying because it has nothing to do with TAG. But as few people have opportunity to ask Tim BL questions, it was a chance for them to ask the director of W3C about it. Trouble is, it’s a discussion that goes nowhere. If TAG’s disapproval of EME could abolish DRM from the world, I’d be all for discussing it (although I’d prefer they focus their new superpowers of abolition on hunger and war). But whether TAG likes it or not, Big Hollywood will implement DRM anyway.

Then I went for a pee and missed a bit about making up your own tags with XML (and/ or RDFa) is evil, but making up your own elements with Web Components is great. Anyone else catch the detail of that part? (Update: Jeremy Keith did.)

Jo Rabin suggested that it was incorrect to see the web as being for browsers only (for Web Component require JavaScript). Alex (from Google) countered that even inside Google, the search engineers aspire to make the Googlebots see the web as we humans do – that is, through browsers – because web pages are written by people, for people.

One thing everyone agreed on was the we all love URLs (or URIs, as Tim called them; is there a difference?).

All in all, it’s good to see TAG becoming a proxy for web developers, ensuring that APIs are sane for JavaScripters. It’s refreshing that they’re open for Q&A, too. Thanks to them, and Google Campus for hosting.

Reading List

Closing the gap between web and native


  • The picture Element Editor’s Draft, 2 January 2013. Lo, <picture> rises from the flames like a phoenix. This re-written spec combines the best bits of srcset and src-n in a webby markup syntax. The most important difference from “old” <picture> is that the <source> elements control the src of the <img> element; thus, <img> is an integral part of the construct rather than simply fallback (and thus is unlikely to be omitted by authors, so “old” browsers won’t be left out.)
  • Input Method Editor API – interacting with virtual keyboards, handwriting pads etc. Particularly useful for Chinese/ Japanese/ Korean.
  • What is the DOM? – a beginner’s guide from Chris Coyier
  • We’re About to Lose Net Neutrality — And the Internet as We Know It by A Lawyer
  • REMs, fallback and support by Stu Robson. TL;DR – add one line of CSS and make sure your font-sizes work everywhere