Archive for the 'accessibility web standards' Category

Reading List

Ten years of WHATWG

A little over ten years ago, on 4 June 2004, Opera employee Ian “Hixie” Hickson sent a mail titled WHAT open mailing list announcement announcing

a loose, unofficial, and open collaboration of Web browser manufacturers and interested parties. The group aims to develop specifications based on HTML and related technologies to ease the deployment of interoperable Web Applications

Ten years is a long time, especially so in software, but nevertheless, the achievements of WHATWG have been remarkable. Hixie wrote

The working group intends to ensure that all its specifications address backwards compatibility concerns, clearly provide reasonable transition strategies for authors, and specify error handling behavior to ensure interoperability even in the face of documents that do not comply to the letter of the specifications.

Core aspects of the web platform were never adequately specified. XMLHttpRequest, for example, was shipped in IE5 in March 1999, and reverse-engineered and shipped in Firefox, Opera, Safari and iCab, but never actually documented until Anne van Kesteren co-specified it in WHATWG in a Working Draft of 5 April 2006. Anne’s currently working on the Fetch Standard, which defines something as basic as “requests, responses, and the process that binds them” and the Encoding Standard:

While encodings have been defined to some extent, implementations have not always implemented them in the same way, have not always used the same labels, and often differ in dealing with undefined and former proprietary areas of encodings. This specification attempts to fill those gaps so that new implementations do not have to reverse engineer encoding implementations of the market leaders and existing implementations can converge.

Of course, the poster children of WHATWG are the slew of new APIs that “HTML5″ brings us – Web Workers, Web Sockets, native video and audio etc etc. There have been mistakes along the way (of course there have, in a decade!). Last year, Hixie told me

My biggest mistake…there are so many to choose from! pushState() is my favourite mistake, for the sheer silliness of ending up with an API that has a useless argument and being forced to keep it because the feature was so desired that people used it on major sites before we were ready to call it done, preventing us from changing lest we break it. postMessage()‘s security model is so poorly designed that it’s had academic papers written about how dumb I was, so that’s a pretty big mistake. (It’s possible to use postMessage() safely. It’s just that the easiest thing to do is not the safe way, so people get it wrong all the time.) The appcache API is another big mistake. It’s the best example of not understanding the problem before designing a solution, and I’m still trying to fix that mess.

But to me, the biggest triumph of WHATWG has been error-handling and interoperability (actually, two sides of the same coin). We’ve moved from a vision of the future where everything was supposed to be XML and browsers were to stop parsing if they met malformed markup, to a present where every browser knows how to construct an identical DOM from the most mangled/tangled HTML. We’re moving to a world where interoperability is paramount, and where specifications are made in the open, in constant consultation with developers (for example, Service Workers, Web Components) based on real use-cases.

I think the existence and the work of WHATWG has secured the viability of the web platform. Happy 10th birthday. And thanks.

Reading List

A small reading list this week, due to there having been a bank holiday this week, and my pre-occupation with being a snot factory.

Reading List

My artisan-curated organic bank holiday reading list. There will be a test on Tuesday.

Reading List

If you use Opera, we’d really appreciate if you could answer a few questions about how you use tabs.

Sexy video of the week

Browser performance panel at – Microsoft, Mozilla & “I’m Bruce from Opera, and my browser’s the fastest”.

Reading List


App Links

Facebook announced App Links, a “an open, cross-platform solution for app-to-app linking”.

Other standards ‘n’ stuff

And finally:

On October 4th 2013, YouTubers ‘Sophie Danze’ and ‘JilianlovestheBiebs’ had a conversation on the video ‘One Direction: That’s what makes you beautiful. The following is a reconstruction.”

Should you use HTML5 header and footer?

Matt Wilcox asked “I still don’t bother with <header> <footer> etc. I assume all widely used browsers support them now. But, do they do anything more than div?”.

It’s a good question. The answer I gave is “yes”. These two elements (and <nav> and <main>) give value to users of some assistive technologies on some browsers.

In the HTML5 spec, HTML elements are mapped to ARIA information. Some of those may be over-ridden by authors, but if they aren’t, they have default implicit ARIA semantics. A <header> element that is not a descendant of an article or section element maps to ARIA role=banner, for example. You don’t need to add any ARIA information; it’s included, free, in the HTML element.

These aren’t necessarily implemented everywhere; Steve Faulkner’s excellent keeps tabs of implementation. As an example, <footer> causes Chrome to expose the element with a footer role in IA2, and Firefox to exposes as ARIA landmark role=”contentinfo” (when not a child of article or section elements).

These are useful to people, as we can see in WebAIM’s 5th annual screenreader users’s survey (which encouragingly tells us “For the first time in 5 years of surveys, respondents are more positive about web accessibility progress than in the previous survey”).

When asked “How often do you navigate by landmarks/regions in your screen reader?” (such as “contentinfo”, “banner”, “main”, “navigation”), 26% said “whenever they are present”.

20% thought 1-3 landmarks/regions per page is optimal; 29% thought 4-6 is the right number.

So my advice is: yes, use them – especially the main <header>, <footer>, <nav> and (once per page) <main>. On browsers/ ATs that don’t support them they do no harm. But don’t use billions.


Added 13 May to clear up confusion:

  • Use <header>, <footer> as often as your content requires – only the main header and footer carry implicit banner and contentinfo roles. At a minimum, use them once (assuming you have a page header and footer, that is).
  • Always use <nav> for the primary navigation.
  • Use <main>, but only once per page.

Happy Birthday, BASIC

The programming language, BASIC, turned 50 years old yesterday. I started using it 33 years ago, when my physics teacher persuaded our school to buy an Ohio Scientific Challanger 2 microcomputer, with Microsoft BASIC as its 8K ROM operating system and chunky 8K of RAM, then set up a computer club. I went along after school, because my mate Matt’s older brother was in computers and he was cool. (He had a job and owned all the punk LPs we listened to at lunchtime.)

Surprising everyone (including myself), I found that programming simply came naturally to me. I was soon coding games that my friends wanted to play.

It taught me several important concepts – primarily, how to break problems into logical flows, and how to debug when regaled with “Syntax error in line 40″ (you may also enjoy my Old programmer war story tale of epic debugging.)

It taught me about abstraction; I soon learned 6502 assembler and disassembled the ROM to see how the computer interpreted the stuff I typed in. (The joys of finding the message “Microsoft BASIC written by Richard W Weiland” hidden in the memory!)

It taught me about cross-platform; later, I borrowed a Sinclair ZX Spectrum, learned Z80 assembler and realised that although the code I entered was the same as the code I’d written for the Challenger 2 (with some minor syntactical variations), what happened under the hood was wildly different.

BASIC changed the world for me, and on cheap widely-accessible machines like the Sinclair ZX series and the BBC micros, it changed the whole world.

What I love about BASIC is that it was designed for simplicity. As wikipedia writes, “It was intended specifically for less technical users who did not have or want the mathematical background previously expected.” It also prefigured the WWW: “The designers of the language decided to make the compiler available free of charge so that the language would become widespread.”

Even the name “Basic” was a statement of intent; no wonder “real” computer professionals sneered at the language. “Goto considered harmful”, they said. I understood that to mean “working class 14 year olds who do literature and humanities not welcome here.”

Today there are still those who try to make programmers a special priesthood. They can kiss my algorithms.

Reading List

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