Archive for September, 2009

WebAIM Screen Reader survey

WebAIM (Web Accessibility in Mind) have released their second Screen Reader User Survey to help Web Professionals learn more about how to design for universal access.

It’s well worth keeping an eye on as it asks questions on how to write alt text to images that convey mood, questions about ARIA, Flash and the accessibility of some high-profile sites.

Last year’s survey provided the revelatory information that 12% of respondents use a screenreader on a mobile phone. (I had no idea such things existed!)

If you know any screenreader users, please pass it on.

Vodafone 360 Widgets

I was invited by some nice people at Vodafone to come along to the launch of Vodafone 360.

Amongst all the glitz and glam PR ladies that made me feel like I’d walked into a Bond film was a real product: a couple of new Samsung phones and a raft of applications and services provided by Vodafone. I’m not their marketing department, so you can read all about it on the 360 site.

After watching a sexy video about Nick (a “typical 360 customer”) who seemed to do nothing else other than take black cabs around the West End to hang out with glamourous 20 year olds, only one of whom ever did any work (and that was restricted to nodding her head and languidly sliding up a fader on a mixing desk), we looked at the tech.

The 360 services are applications pre-supplied by Vodafone. There was a live-demo (brave!) of an application made by Domino’s Pizza that allows the user to buy a pizza incredibly easily; the phone’s GPS told the nearest shop the user’s location, and the cost of the pizza is added to the user’s VF phone bill.

What’s interesting thing about the 360 applications is that they’re not built using Java, C++ or some vendor-specific language. Instead, they’re written using HTML, CSS, JavaScript and packaged up according to (draft) W3C spec called Widgets 1.0: Packaging and Configuration. The packaging is as simple as writing a config.xml file or using the Widget Packager wizard to do it for you, and zipping up your config, HTML, CSS, JavaScript and any images and renaming the resulting file with a .wgt extension. (Widget tutorial: Making a mobile Twitter client.)

For Widgets, read “applications”; I think the name does the spec and concept a disservice, as it implies trivilality or toys. What’s cool is the Vodafone implementation has “live” icons that can display info even when the application isn’t fully opened.

The advantage to using W3C widgets (and presumably the reason that Mr Vodafone invited me) is that if you know how to write standards-compliant web pages, you know how to make mobile phone applications. Vodafone are encouraging developers to write and sell through their app store which operates a 70/30 revenue split, favouring the developer. (There will be a €1million prize fund for the best new widgets, they said.)

The emphasis on standards continued in a surprising way; a venture capitalist lady on a Q&A panel talked of W3C standards being advantageous to both developer and customer. There was a VF suit with a whole slide listing standards and a W3C logo. This was all music to my ears, of course, given that I’ve been banging on about the benefits of standards for years, but it was odd to see so many suits repeating it.

The success of 360 remains to be seen; I think it’s launched to consumers in a month or so. Its DRM-free music is a plus, but the quality of the handsets will be the Christmas make-or-break, in my opinion. I’m no fan of the iPhone, but for user experience it’s without equal so the new Samsung hardware will need to be pretty special in a way that my Samsung Omnia isn’t.

The day was surprising in that I met three people I didn’t expect to see; the first was Opera’s CEO Jon von Tetzchner (=my boss) who was speaking on the expert panel as Opera is the 360 browser.

The second was ever-cheerful Cathy Ma who introduced me to people with an anecdote about nipples, and the Mobile Web Best Practices Working Group‘s answer to John Steed, Jo Rabin, who I’ve spoken to every Tuesday afternoon for many months but had never met.

And so to the party, where much beer was consumed and CSS Media Queries discussed.

God-botherers or Bible-bashers?

Last night, I got a few angry emails after I wrote on Twitter that some visiting relatives were “Bible-Bashers”. I’m happy to accept I’m wrong; they are “God-Botherers” who enjoy going to church but otherwise don’t mention it to people who don’t share their views. There’s a difference.

“Bible-bashers” are those who feel the need to spread their views to others. It’s a term that comes from the religious pamphlets of the English Civil War of the seventeenth century, describing aggressively religious people.

To find out which you are, take this handy quiz:

  1. Do you believe you have an Invisible Friend In The Sky? (Yes=1 point, No= 0)
  2. After spending a few days creating the billions of stars in the billions of galaxies that fill the awe-inspiring majesty of the universe, does your Invisible Friend In The Sky now spend its time closely monitoring your daily actions and reading your thoughts? (Yes=2 point, No= 0)
  3. Does your Invisible Friend In The Sky care which adults you have consensual sexual intercourse with? (Yes=5 points, No= 0)
  4. Is your Invisible Friend In The Sky eternal, beyond the laws of causality and entropy and undetectable by science? (Yes=1 point, No= 0)
  5. Does your Invisible Friend In The Sky regularly intercede in the material world on your behalf (good grades, safe journeys, speedy recoveries) because you ask it to? (Yes=1 point, No= 0)
  6. Does your Invisible Friend In The Sky routinely neglect to help blameless people caught up in calamities like genocide, war, famine, earthquakes or tsunamis because it “works in mysterious ways” (or other manifestations of inscrutability)? (Yes=5 points, No= 0)
  7. Does your Invisible Friend In The Sky require subordinate behaviour from women such as covering their hair, wearing shapeless garments, not being allowed to teach in places of worship or hacking off each others’ external genitalia at puberty? (Yes=10 points, No= 0)
  8. Does your Invisible Friend In The Sky require you to tell people with a different Invisible Friend In The Sky (or no Invisible Friend In The Sky) that they are wrong? (Yes=10 points, No= 0)
  9. Does your Invisible Friend In The Sky think it legitimate or laudable to kill people with a different Invisible Friend In The Sky? (Yes=20 points, No=0)
  10. Are you angered/ offended by this quiz? (Yes=5 points, No=0)

If you scored zero, you are not a God-Botherer.

Between one and five, you might be but don’t know it; you probably tell people that you’re “a spiritual person”.

Between five and ten, you’re a God-Botherer.

More than 10 makes you a Bible-Basher. 20 or more and you’re a fundie.

Standards.Next: cognition and accessibility

When Henny and I dreamed up the format, we were privileged: we work for Opera, which really supports standards so we get allocated time to work on these day-long geekfests without having to aggressively pimp the company or worry about turning a profit.

However, when we decided to run what I think was the first ever event dedicated solely to cognition and accessibility, I expected only a dozen people or so to show up.

Wow! Over forty came, including one lady who flew from Madrid specially (thank you, Emmanuelle!)

I knew it would be a great day when, hopelessly lost at Angel tube, I asked a guy on a “no ID cards” stand for directions to City Uni. “Are you going to” he asked me, promising to show up 30 mins later (and he did).

I shan’t repeat what each of our excellent speakers said, as their slides and videos are available on their sites:

Here are some write-ups of the day:

On the styling of form fields

In Ian Pouncey‘s talk, Ian mentioned that people with cognitive needs (including older people, people new to the Web) need consistency of look and feel with controls. Don’t style form buttons, he suggested.

This resonated with me as lately I’ve been thinking a lot about the new features HTML 5 brings to forms. When I demo them, I’m always always asked if they can be styled. At the moment, they can only be styled up to a point: for super-specific styles to new sliders, calendar widgets, we’ll probably need new pseudo-elements from CSS Working Group, perhaps in the Basic User Interface module.

Ian’s comment led me to wonder should they be stylable at all, a question I asked of the meeting.

Antony Kennedy told me that they should:


1) If you don’t allow it, people will do it anyway. If HTML 5 does not support this we will have to create our own bastardised JavaScript replacements, which will be inaccessible, unusable, and unrecognisable by anything querying the DOM as what they actually represent.

2) Although we know they ought to and recommend that developers use the default OS styling, to take away the option is too strict. We are pushing standards, not limits.

3) Allowing developers and designers more flexibility allows them to come up with new more intuitive and surprising interfaces and uses for these elements that we would never have thought of.

4) It’s what the customer wants. And what they want, essentially, they get. The biggest complaint about the “select” tag is that we cannot style it. This led to on my very first day at BSkyB me blogging this because of this:

The dropdowns had to match the branding. There was no option otherwise. Because I could not “colour it in” we had to make our own bespoke dropdowns. Immediately, failures were made to recreate the OS’ behaviour. The selected content of the dropdown did not match what was displayed. No keyboard access. JavaScript only. If we had been able to style the dropdown then we would have been able to achieve all of this, and in far less time. Without being able to, yes, we were pushed along the path of using the OS default. Was that the chosen option? No. We ended up with a pretty (subjectively) but inaccessible solution, with no decent business case to improve upon it.

5) If we do not allow this, developers/designers will use the next available attribute that will let us do this with the least pain. Submit buttons become anchors, for example, and then we have dependencies on JavaScript, and the entire web become less accessible and less semantic.

I would love to know your views on the stylability of forms.

Jamie Knight’s screenreader and HTML5

Something else that made me think of HTML5 (because I’m heavily focussing on accessibility there) is Jamie Knight’s discussion of his screenreader use. He’s not blind, but sometimes finds it easier to listen to a page than read it. He made his own screenreader that listens out for certain ids or class names like “navigation”, “menu”, “sidebar” so that his screenreader can skip the peripheral information on repeated views.

With the “baked-in” elements like nav, footer etc, this would be achievable with much greater precision.

What did the day achieve?

Personally, the after-conference chats are as important to me as the “official” talks. I was delighted that conversation and debate continued into the night, with people who hadn’t met each other swapping ideas, insights and business cards. That’s one of the results I’d hoped for: connecting people who might have been working in isolation.

I also met one of the accessibility good guys, Matt May from Adobe. I’ve known him for ages on-line; most recently he’s been helping Lachlan Hunt and I understand the kind of things that will be needed to make canvas accessible—the kind of things that got added to Flash in version 5 to retrofit it for accessibility.

I was clutching my battered copy of the excellent book Universal Design for Web Applications that he wrote with Wendy Chisholm so he could sign it for me:

Mr Blorsensen: thank you for your support. Sorry, no refunds

So, in conclusion: thank you to all our speakers and all who attended. I wholeheartedly agree with a tweet from isolani:

Today reminded me again what a marvelous accessibility community we have within the UK.

(A few more photos)

(Last Updated on 7 October 2009)

Opera Mini: what, why and how

Speaking to a few hundred developers this week at Future of Web Design Bristol and Glasgow, some attendees were surprised to learn that Opera passed the iPhone to lead the mobile-browser market. This seemed counter-intuitive as “everybody” in the web development world has an iPhone, just like “everyone” uses a Mac.

Of course, we know that in the real world, most people do not have an iPhone and don’t use a Mac. This is a demonstration of the potentially dangerous belief that “my customers are the same as me”. As everyone wants to make their sites mobile-friendly, and as today sees the release of Opera Mini 5 beta, now is a good time to explain what Opera Mini is and how you design for it and test it.

What is Opera Mini?

Web browsers are hugely complex beasts. Working out the interaction between HTML, CSS, SVG, JavaScript and rendering it all is highly processor-intensive. They rely heavily on Operating Systems (which is why making cross-OS browsers like Opera and Firefox is hard).

World-wide there are 100 million or so smartphones, each of which has an Operating System that can run a full web browser such as Opera Mobile or Safari.

But there is an estimated 1 billion lower-specced phones around the globe, many of them in the developing world (but by no means exclusively so; how many people do you know with featurephones rather than smartphones? A lot, I’ll bet).

Because it’s a world-wide web, and not just a wealthy Western web, we developed Opera Mini, which works on all phones—even on the lower-end ones, as long as they support Java.

There often isn’t enough processing power to render the page on these phones, so the requests are pre-rendered on servers running Opera’s layout engine and the result is sent to the phones from the server as a heavily compressed “snapshot” of the page. It’s by no means uncommon for this to be as small as 10% of the size of the original page.

Because of this heavy compression, displaying pages on the user’s device occurs much faster than if it had processed the page itself, and for those who pay by the amount of data downloaded it’s also a huge cost saving. This compression and data saving also explains why many Western users of smartphones use Opera Mini to reduce bankruptcy-inducing data-roaming charges when they travel to a neighbouring country.

How to ensure your site works in Opera Mini

The same way that you ensure your site works in every other browser: design using Web Standards and make sure your code validates.

A useful technique for cross-browser and cross-device development are to use the Hijax methodology for adding Ajax interactions.

Don’t be immediately tempted to start building a special mobile-only verson of your site (see my ZDNet article Forget the mobile web: One site should work for all). Using CSS Media Queries, you can send reformatted screen layouts to devices according to their display properties.

Leverage those accessibility synergies!

Another secret of developing with mobile devices in mind is to consider accessibility. If you think about it, having a small screen with no keyboard is somewhat like browsing with assistive technologies.

Many people on expensive data plans browse with images turned off, so sensible alternate text gets the content to them. Many older mobile devices have limited fonts and colours, so by not using those as the sole way of giving information makes your sites both accessible and available to mobile devices.

The W3C produced a useful cross-reference that rejoices in the title Relationship between Mobile Web Best Practices (MWBP) and Web Content Accessibility Guidelines (WCAG) which explains this in more detail.

Further resources

Future of Web Design, Glasgow

Here’s the talk I gave at Glasgow (which was the afternoon talk I gave in in Bristol).

Sorry, Glaswegians, for the lack of demos—the projector had problems with Windows machines.

Future of HTML5 (.odp format, 3MB.), Future of HTML5 (.pdf format, 600K.)

Forms demo

One of the cool things in HTML5 is intelligent forms, which are implemented most thoroughly in Opera (so try them there) and which are apparently “coming soon” in Google Chrome.

In legacy browsers, the intelligent forms just fall back to text input fields.

Safari displays input type="range" as a slider, and also the once-proprietary, now standardised placeholder attribute. Watch what happens in Safari when you click in and out of the email field.

And don’t forget to view source for that “Look, no JavaScript!” moment.

HTML5 forms demo.

Canvas demos

Want to learn more? Opera has some excellent beginner canvas tutorials:

  1. HTML 5 canvas – the basics
  2. Creating an HTML 5 canvas painting application
  3. Creating pseudo 3D games with HTML 5 canvas and raycasting
  4. Creating pseudo 3D games with HTML 5 canvas and raycasting: Part 2

Video demos

You’ll need Firefox 3.5 for these (I was demoing using an Opera Labs build, but it’s not publicly available yet).

Remember – there are no browser plugins running here, so the video element is completely available for manipulating with script. That’s the killer feature.

A couple of links I mentioned:

Thanks to all who came to watch, ask some questions, share their thoughts, drink a beer with me, or buy me a deep-fried Mars Bar!

Future of Web Design, Bristol

On Wednesday I presented on HTML5 in Bristol as part of the Future of Web Design Tour.

The hour-long workshop “How to build a HTML5 Web site” involved me coding in real time (with hilarious typo consequences like “Dictype” instead of “doctype”; frankly, I’d be better typing with my dic than my hands).

Consequently there are no slides to publish, but I have an article called Designing a blog with HTML that covers the same ground. (Two articles on this blog cover it in much more detail: Redesigning with HTML 5 and WAI-ARIA and Marking up a blog with HTML 5 (part 2).)

Some other useful resources:

You can also download Opera 10 which I was using to demo.

There will be a video available, and the Carson types have promised that they’ll publish a transcript simultaneously. It’s nice to see them taking accessibility seriously, and I was pleased to see that they had someone signing the sessions for hearing-impaired.

You can grab the slides and notes for my second session, The Future of HTML5, which I tweaked slightly to deliver on Monday in Glasgow.)

(Last Updated on 16 September 2009)

This millenium in HTML 5 (politics)

OK, so it’s not quite a millenium but the flame wars, bitch fests on the mailing list make it feel that way.

Microdata/ RDFa

According to the W3C‘s RDFa primer, it is “a few simple XHTML attributes … [to] mark up human-readable data with machine-readable indicators for browsers and other programs to interpret. A web page can include markup for items as simple as the title of an article, or as complex as a user’s complete social network.”

HTML 5 had the temerity not to care about the RDFa for three reasons (as far as I can tell):

  1. It’s too hard for most markup monkeys to code
  2. It requires XML namespaces and HTML 5 doesn’t do namespaces
  3. If you copy and paste RDFa annotations, it won’t work in the destination page unless you also copy the RDFa definitions, which can be separated in the code.

So instead, HTML 5 introduces microdata which does the same thing in a different way. To some, this has caused grave anguish. Shelley Powers is anguished because it competes with RDFa, Ian Hickson wrote it on his own, the HTML 5 spec is too big already and microdata isn’t as “good” as RDFa.

Jeni Tennison seems unanguished. While microdata isn’t as good as RDFa, she acknowledges, it’s easier to use.

Meanwhile, Philip Jägenstedt (who implements video for Opera but indulges his pash for the Semantic Web at weekends) goes crazy and, rather than philosophising, implements the microdata API in JavaScript to see how it compares. (His feedback to the Working Group.) He concludes:

  • Microformats, you’re a class attribute kludge
  • RDFa, HTML is not your triplestore
  • Microdata, I like you but you need more review

Anyway, this crazy mindset of Philip’s in which things are tested and the best one wins regardless of ideology seems to have infected others. Ian Hickson writes

I am going to try some tweaks to the Microdata syntax. Google has kindly offered to provide usability testing resources so that we can try a variety of different syntaxes and see which one is easiest for authors to understand.

As someone only tangentally concerned with machine-parsable data (I’ve used one microformat in my life, once) I’d love to see the three options compared by someone like Tantek, Jeremy Keith or Ben Ward. (Wish granted in Ben’s comment.)


Summary lovin’ had me a-blast

The decision to deprecate the summary attribute of table caused what we lucky denizens of W3C Working Groups officially term a right shitstorm.

From a barely-used accessibility add-on, it became a talisman whereby the mature accessibility experts with real experience beat up the juvenile upstarts who are all clever ideas and no practical knowledge, while the brave young pioneers with the courage to boldly forge new paths attacked the silly old farts who are afraid of change.

It’s settled down now, with summary remaining in the spec but advised against (a sensible compromise, in my opinion; I think summary is superfluous).

A highly condensed partisan history of Oh, those summary nights is available from Google’s Mark Pilgrim, who memorably did his bit for inter-generational bonding by calling some accessibility practioners “charlatans and fools”.

ARIA integration

This is vital work. ARIA is a bolt-on spec that extends HTML 4 to cover the accessibility of Web Applications, which stretch HTML 4 to breaking point because it was designed for static documents, not apps.

That stretch is one reason that HTML 5 was invented; its original name was “Web Applications 1.0”. Because HTML 5 is a new spec, it’s better to have accessibility built-in rather than bolted-on.

Also, the ARIA spec is complex and puts a lot of work on the developer, so it’s in everyone’s interests that ARIA be folded into HTML 5’s existing structures as far as possible.

Fortunately (and surprisingly, given the summary fracas) no-one seems to be disagreeing on the need for the HTML 5/ ARIA integration process which appears to be going smoothly and without horses’ heads being left in beds.

canvas accessibility

canvas is the immediate drawing mode available in HTML 5. It’s fast, and therefore sexy, because it doesn’t have a “DOM”, but which means there is nothing for assistive technologies to hook into.

Some have suggested that canvas be removed from the main spec, but that would make little difference except to confuse authors who already have too many specs to cross-reference.

Because the spec retrospectively codified what was already working in the browsers, we just have to accept that those implementations are inaccessible for now and not use canvas where a more accessible method exists.

However, the first part step towards solving a problem is acknowledging that there is a problem, and it’s acknowledged that the original use-cases anticipated for canvas don’t match what people are trying to do now (further discussion of this in my standards suck video interview).

I know that cabal member and fellow Operative Lachlan Hunt has been investigating how my old chum Bob Regan of Adobe went about retrofitting Flash for accessibility, way back in version 5. That’s a promising sign.

New chairs

Chris Wilson of Microsoft resigned as co-chair, and two people replace him: Maciej Stachowiak of Apple, a cabal member through and through, and Paul Cotton of Microsoft. I don’t know Paul, but it’s good to see Microsoft continuing its involvement, and certainly we’re seeing lots of specific feedback from Internet Explorer Program Manager Adrian Bateman.

Super Friends

Zeldman and a group of celebs including Eric Meyer, Tantek Çelik, Dan Cederholm adopted the moniker HTML5 Super Friends and endorsed the direction the spec’s going, thereby immediately making it primetime.

They have a useful list of concerns. Regular readers (hello Mum!) may recall that I’ve previously submitted concrete proposals to the Working Group about the content model for small, the problem of legend in new elements, and the unnecessary restrictions to the time element, so I’ll not reprise those, but here are my thoughts on the Super Friends’ hiccups.


I agree that hgroup is clumsy and likely to be misused. Rather than wrap an h1 and its h2 subtitle in hgroup to keep the subtitle out of the outlining algorithm, I would prefer to use

<h1>My blog</h1>
<subtitle>My wit and wisdom</subtitle>

as I think that’s easier to understand than a heading-that’s-not-a-heading, and it removes a wrapping element.

The footer content model

I agree that it’s daft that you can have nav, headings and sections in a header but not a footer, and this contradicts what many people already do—see Webcamp BKK for an example taken at random from

Update 4 September: and, lo!, it is done:

Contexts in which this element may be used: Flow content, but with no header or footer element descendants.

The dialog element

I’ve said before that

is an abomination. It perpetuates the HTML 4 use of dd and dt for dialogues, which are better marked up with blockquote and cite.

That better option is no longer available in HTML 5 which unnecessarily restricts the cite element to only marking up the title of a work (in HTML 4 you can use it to mark up a name).

In my opinion, the HTML 5 spec is overly restrictive, as I’d like to continue using the blockquote/cite pattern, as dialog has no mechanism for marking up stage directions such as “Exit, pursued by a bear“.

Frankly, I’m not even certain that dialog merits its own element. If no-one is convinced that marking up ancient or fuzzy dates has a use-case, what is the use case for dialog? Adrian Bateman of Microsoft agrees with me:

We also don’t think dialog adds sufficient value to justify the spec,implementation, and test cost.

Learn more

If you’re looking to read the HTML 5 spec from a markup author’s perspective (that is, ignoring all the stuff for implementors), you can find the huge single-page Author spec and multipage Author version.

Stack Overflow’s What improvements to accessibility are offered by HTML5? is an unbiased overview.

There’s a 10 min video interview on Standards Suck talking about some of the issues above, and an interview with Government Computer News in which I talk about HTML 5 development and its relationship to the US accessibility standards section 508.

And, by the way, if you’re interested in HTML 5, please vote for my South By Southwest HTML 5 panel.

Opera 10

Today saw the first major release Opera since I’ve worked there, when Opera released version 10. As Molly says,

Opera 10 marks a new time for our browser, with its sexy new UI, cherry-red restyled “O” logo, standards support including many advanced features not found elsewhere, and improved developer tools. Not only that, but to coin a silly Carpenter’s song…”we’ve only just begun.”

What is particularly exciting for me is the amount of features it offers for the consumer. (There’s lots for developers, like Web Fonts, increased standards support and an enhanced Opera Dragonfly debugging tool.)

Opera has always had a reputation of being a browser for the “power user” as it’s so customisable, but that can often be off-putting for non-geeky customers (I’m thinking of my Dad here).

So Opera 10 adds spell-checking and auto-updates, as well as a much sleeker user interface in which you can move the tabs where you want them by hovering over the tabs, right clicking and choosing “Tab bar placement” (see my 45 second amateur YouTube tutorial).

Speed dial is now easily customisable (before you had to edit a config file—never much fun for a user) and you can add a background image too.

These make all the pre-existing features (sessions, mouse gestures, excellent keyboard support) all the more usable to the mass market.

One feature outshines all the others, though, for people using Opera 10 desktop outside of the industrialised world (or in crowded WiFi hotspots), and that is Opera Turbo. This speeds up browsing dramatically over slow connections, by compressing images —on the assumption that mostly you want to read the content rather than look at the pictures; if picture quality is important, you just turn Turbo off. (This works on slow connections, when compressing the images is faster than sending them down a slow line. On broadband, it’s faster to send them down the line than it is to compress them on a proxy.)

I’m proud to see this release, which strives to bring an excellent browsing experience to all, regardless of geography or infrastructure.

But enough seriousness. Check out this fun video about Norwegians’ love for compression and flat-packing: