Archive for the 'ARIA' Category

JavaScript and screenreaders

For three years Jared Smith and his lovable chums at WebAIM have conducted a survey of screenreader users, analysed the result and posted them. This year’s results are out. Let’s take a moment to give them a round of applause.

There is much to digest, but one figure really caught my attention: only 1.6% of respondents had JavaScript disabled. Turning that round, 98.4% of screenreader users had JavaScript enabled.

Hopefully this will finally bury the WCAG1-era myth that JavaScript is automatically bad for accessibility or that pages that depend on scripting are inaccessible to assistive technologies.

This myth came about from the early days of screenreaders, which took a snapshot of the rendered page into a buffer and, when a user was navigating a page, he was really navigating that snapshot. If a page was changed with script the user wouldn’t know because another snapshot wasn’t triggered. (Even in this model, some JavaScript was fine. If, for example, your page contained lots of document.writes that executed immediately, and wrote HTML to the page, that would be available.)

As the Web made more use of “Ajax”, screenreaders became more sophisticated and now can handle most scripted interactions. This doesn’t mean that JavaScript is always fine to use; just as you can write inaccessible HTML and CSS, it’s possible to script away accessibility. An understanding of WAI ARIA is vital to professional JavaScripters.

(It’s also important to understand that not all accessibility needs are assistive technology needs. Christian Heilmann and Antonia Hyde showed that some scripting can be empowering for people with cognitive problems with their Easy YouTube and Easy Flickr.)

So we know that script doesn’t scare off assistive technologies, and we know from Yahoo! developer Nicholas C. Zakas’ report How many users have JavaScript disabled? that only 1% of visitors to Yahoo! have turned off JavaScript. Does this mean that we can safely forget about those who can’t use JavaScript.

Well, no. But JavaScript-required is not an accessibility problem, it’s a usability problem. As Zakas says

While the percentage of visitors with JavaScript disabled seems like a low number, keep in mind that small percentages of big numbers are also big numbers.

We spend a lot of time making our sites work with old browsers, using JavaScript shivs and polyfills but we don’t talk much about users without JavaScript. The Opera mini browser, for example, is the most-widespread mobile browser out there but, because it renders on a server, interactivity is limited (See Opera Mini: web content authoring guidelines for more information.)

How far can an application that requires Web Sockets, local storage, cross-domain messaging, canvas be expected to degrade gracefully?

HTML5: bolt-on or built-in accessibility?

Parallel with the discussion in the comments to my post HTML5 details element, built-in and bolt-on accessibility, some cleverer minds than mine (Edward O’Connor, John Foliot, Tab Atkins, Jonas Sicking) have been working on a proposal Retain several newly-introduced semantic elements, attributes, and controls to retain structures that some have proposed be scrapped, such as aside, details, figure, meter, progress and the hidden attribute.

It’s a short but must-read if you’re interested in the debates between bolt-on and built-in accessibility in HTML5.

I had no hand in its authoring, but fully support the proposal and arguments. (I tried to add my name to the end of the proposal to demonstrate immoral support, but am so crap I couldn’t even remember my W3C password.)

See also this interesting and impassioned email from John Foliot.

jQuery accessible HTML5 video captioning plugin

Last month, I wrote an article on Accessible HTML5 Video with JavaScripted captions and dreamed that some clever JavaScripters would take it up and improve it, making it more generic so that a developer could mark up a transcript with timestamps, call in a library and -hey presto!- there would be captions.

Those nice chaps at 360innovate have started work on a jQuery plugin called jCaps.

As it’s all open licensed, if anyone fancies participating, it would be jolly. Here’s a wishlist that I’d love to see, and would write if I were not so scripting-challenged:

  1. It would be useful to point to the transcriptions via the aria-describedby attribute on the video element, the values of which point to the id of an element containing the transcript (which could therefore be an article, a div or whatever). You can have multiple values on aria-describedby (like you can with class) so that allows you to point to different translations.

    This allows you to have transcripts anywhere in the source, so greater flexibility for laying out the page.

  2. If there are multiple transcripts for a single video, they need to have a lang attribute, and the script should construct a select element so the user can choose the language they wish to see transcripts in. (The first one offered should be the transcript that matches the lang attribute on the html element; if there isn’t one, the default should be the first in source order.

  3. I’d love to see a sexy (and stylable) skin around the video element that had a YouTube-stylee user interface that houses all the buttons for turning on captions, transcripts and the language picker.

Anyone up for the challenge, and generous enough to release it as a BSD-licensed library/plug-in?

Note that this technique will have a limited shelf-life. The HTML Accessibility Working Group have two specifications that will enable captioning etc to be done natively once the spec is agreed and (of course) implemented.

See my related post: Some accessibility today or full accessibility jam tomorrow?

Meffys, @media,

Corblimey what a week and no mistake guv. (Sorry, still getting the last Lahndahn molecules out of my system.)

The Meffys

Firstly, on Tuesday, I attended a formal event on behalf of Opera as our Opera Mini mobile web browser was up for Best Mobile Application at the Mobile Entertainment Forum‘s Meffys awards. I’m not really a suit-and-tie business dinner type person, but duty called so I went along in my wedding-and-funeral suit for the onerous task of drinking free mojitos while listening to the host Hardeep Singh Kohli. (Lots of people said they found him too abrasive, but I thought he was a good choice.)

Lo and behold – we won! Feeling very proud and, forgetting my acceptance speech that our PR types had prepared, I clambered onto the stage and made an impromptu thankyou speech which would have the PR team having palpitations were it recorded anywhere, did a quick video interview for a journalist and took the coveted award home back for a couple of relaxed tie-less beers with David Storey and Chris Mills in the hotel bar.


At media was primarily a great gathering of the clans—I thought that the line up was playing it safe (entirely understandable in the current climate). I [particularly enjoyed persuading 30 people away from some poncey overpriced South Bank bistro in favour of a Waterloo greasy spoon where they stayed open especially to serve us snake and pygmy pie with beans and chips and a pint of lager for under a tenner.

The best speech for me was Robin Christopherson’s, in which he discussed ARIA and CAPTCHA as well as phone accessibility. I made an unscheduled appearance on stage as the HTML 5 cowboy during Molly’s presentation and donated the backless faux-leather chaps to Chris Wilson of Microsoft who’s the co-chair of the W3C‘s HTML 5 working group. He said that he would pass them onto Ian Hickson. I hope that they do the rounds of HTML 5 movers-and-shakers.

On Saturday the first informal emerging tech bootcamp took place. I was delighted how it went, having co-organised it with Henny Swan. We cajoled a stellar line-up of speakers to sit in a friendly (but very hot and sticky) atmosphere and really get under the skin of HTML 5. I humbly thank every one of them.


I over-ran on time without finishing my slides, discussing some myths that are causing unnecessary FUD and doing a basic demo of markup for a blog.

Remy Sharp

Remy demoed the state of play with the new JavaScript APIs. You can check out his HTML 5 JavaScript APIs slides and try his HTML 5 JavaScript demoes, or watch the HTML JavaScript: video of his presentation.

Dean Edwards

For the first half of Dean Edwards’ HTML5.js talk, most people couldn’t grasp the magnitude of what they were seeing. Dean was showing his new JavaScript library that plugs the holes in browsers’ HTML 5 implementations. If a browser does do something natively, ther library does nothing; otherwise it fills that gap—so now you can have Web Forms with all browsers, canvas in IE. As a bonus, it’s all keyboard accessible, everything looks like native UI controls and it even inherits the native Windows themes. I’m looking forward to helping beta test this baby.

Martin Kliehm

Martin showed several demoes of the new canvas element that blew my mind. I’d rather assumed that it was just for wiggly graphics and maybe on-the-fly graphing but Martin showed some combinations of canvas interacting with video (because once everything is in the browser rather than plugins, they can all talk to each other).

There is real potential for new interaction models for people with learning disabilities, older people and kids.

Steve Faulkner

Steve discussed the accessibility issues of the HTML 5 spec and its relationship with ARIA. I came away from Steve and Martins’ talks convinced that the biggest barrier will be the lack of real support for canvas accessibility and commend Steve for fighting this in the Working Group. I shall be standing with him in future.

I want to thank all the speakers who volunteered to share their knowledge, passion and expertise with us, and thanks to all who attended, and interacted with all the speakers to help us firm up our knowledge.

Although there were some problems (heat, pillars in the way), the event went exactly as Henny and I hoped: a relaxed pub (£1.95 a pint of bitter and you can take your own sandwiches in!), short focussed speeches of 30 minutes so speakers don’t feel the need to pad and a genuinely interested crowd who participated rather than passively absorbed the information. This lady is an excellent example:

Stephanie (?) have a riveting time at

HTML 5 Doctor

I plugged it at @media and (and forgot to give out the moo cards), and we’ve launched the bare bones of it today – HTML 5 Doctor (named in homage to an early Zeldman feature called “Ask Dr. Web”).

High Standards t-shirts

If you got a freebie High Standards t-shirt from us at, please post a picture of you wearing it to Flickr and tag it highstandards, because I want to remember how lovely you are.

The accessibility of HTML 5 autofocus

Last week, I published an HTML 5 contact form WordPress plugin that used the HTML autofocus attribute to put the focus into the first form field.

Marc Aplet commented about the accessibility of doing that, for which I am very grateful as it made me think more deeply about it. Thanks to those on twitter who helped me further with my thinking.

Note that potential accessibility problems are not restricted to the HTML 5 use of autofocus; current JavaScript ways of doing it cause the same problems.

I believe that autofocussing into a form is a usability win for most people if the purpose of the page is that form—for example, the Google hompage. So, I wouldn’t autofocus into the search box or comment field on this page because the primary purpose of this page is discussing this article which requires prior reading. Most people are lurkers, not commenters, so it’s against usability to autofocus into the comment form. But a contact form is the primary purpose of a contact page, and it saves users a keystroke to put the caret into the first field—particularly usable for mobile phone users.

However, screenreader users find themselves dumped in the middle of a form, potentially without context (athough it’s always possible to tell the screenreader to repeat the title of the page, and we all give our pages useful titles, don’t we?).

Moreover, many forms have explanatory or introductory information preceeding them. My contact form does, although that’s somewhat flippant. A better example is Salford University’s Online Staff Directory Quick Search Page. The explanatory information is correctly outside the form element, as JAWS and (I think) Windows-Eye ignore any text that’s not inside legend and label elements when they’re in Forms mode.

What we need, then, is a way to associate some explanatory descriptive text that’s outside the form with the form itself (in a similar way that label and input are explicitly associated). Then a screenreader user could be alerted to the presence of this descriptive material by this programmatic association, and optionally choose to have it read out to them.

Enter aria-describedby. The ARIA spec says

An accessible description may be computed by concatenating the text equivalents for nodes pointed to by an aria-describedby attribute on the current node.

So, I recoded the plugin (download it; it’s at your own risk etc) so that the descriptive matter is enclosed in a div id="form-description". The form element has the attribute aria-describedby="form-description" (because the description is for the whole form).

I don’t know if any screenreaders offer a keystroke to query this information yet (it’s over a year since I’ve been near a screenreader), but as the vendors have worked closely with the WAI-ARIA authors I imagine it won’t be long.

I also amended the plugin so that it has a belt-and-braces approach to the form fields that are required. In addition to the HTML 5 required attribute, I’ve added aria-required="true" as this is probably closer to implementation by screenreader vendors.

Because there are already two programmatic methods of indicating that a field is required, I’ve removed the traditional method of including an asterisk in the markup, as it’s possible to style the form fields with CSS—I’ve used a thick black border. (I tried to use attribute selectors to generate the string “required” immediately after the form field, but that gets surrounded by the field border rather than living outside it. The result is minging, even by this site’s low design standards.)

Welcome Molly, free HTML 5 talk on Saturday

I’m delighted that my old mate Molly Holzschlag is joining the Web Evangelist team at Opera.

I’ve known Molly since 2001. She was a journalist covering a Wrox XML conference I was helping run in Las Vegas. A colleague of mine, Karli Watson had a quickie, tacky Vegas wedding and Molly and I attended.

Two years later, I was searching for someone to co-author a book with me about usability, and found Molly. We were both unaware that we’d met before until halfway through our collaboration. Usability: the site speaks for itself sold poorly (and taught me some vital lessons about web developers and how they differ from programmers) but it cemented my friendship with Molly. She’s been to my house, eaten my evil chicken, charmed my children (“a real American!”) and helped me drink a bottle of vodka.

It’s great to work with old friends like Molly, Millsy and Jon Hicks, and new friends like “Zip Pin” Zi Bin, Shwetank, David-not-Dave, Andreas “Frisky” Bovens and Henny “Henry” Swan. One of the comments on Molly’s blog is “That’s some team Opera are building.” Fuck, yeah. And I’m delighted to be a part of it.

Why the mobile web must mirror the desktop

A long interview with me about One Web and the importance of web standards for device-independent development, which will presumably get Luca all foamy at the mouth again. Originally published in .net magazine a month ago.

Free talks on HTML 5, ARIA and JavaScript, Birmingham 21 February

I’ll be presenting “Confessions of a mad scientist: my HTML 5 experiments” on Saturday at 4pm in Birimingham (meet at 2pm for beers).

Also on the bill is Stuart Langridge on JavaScript and another old friend, Matt Machell, discussing ARIA. It’s free, so see you there? (More details)

HTML 5 Flash embedding and other validation errors

When I completed the first round of my HTML 5 redesign, some validation errors remained.

Most were due to WAI-ARIA roles being applied to new HTML 5 structural elements, which isn’t currently allowed (both specs are in draft, remmeber). I’m not worried about those; accessibility trumps validity for me, and ARIA doesn’t validate in HTML 4, either.

I was also getting an odd error with Remy Sharp’s groovy HTML 5 enabling script, which I’d surrounded by a conditional comment as only Internet Explorer needs it. Part of the JavaScript has a double hyphen and HTML 5 doesn’t like “--” in comments, so fearphage sent me a rewrite that reversed the JavaScript. You don’t need to do this as you would have the script in an external file; I have it included in the head of each page so that visitors can see what’s happening.

However, none of the embedded Flash movies from YouTube would validate. I was using the default code given by YouTube which nests an embed tag inside an object tag and which doesn’t validate in current flavours of (X)HTML because embed was never in any spec.

Fearphage suggested using just the object tag for the Flash movies, but Patrick Lauke pointed out that there are some problems with that approach:

  • Internet Explorer can’t stream videos but must download the full movie before showing it
  • screenreaders can’t access accessibility information within the Flash movie (admittedly not likely to be a problem with most YouTube uploads)

One of the HTML 5 design principles is to “pave the cowpaths”. Because everybody uses embed, it’s been added to the spec. So by rearranging some of YouTube’s suggested code (self-closing param elements, escaping ampersands in URLs and repeating the URL for a third time as a data attribute on the object element) I came up with an accessible-as-possible, cross-browser, valid HTML 5 way to embed Flash movies:

<object width="425" height="344" data=";hl=en&amp;fs=1">
<param name="movie" value=";hl=en&amp;fs=1" />
<param name="allowFullScreen" value="true" />
<param name="allowscriptaccess" value="always" />
<embed src=";hl=en&amp;fs=1" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344" />

What we need now is for some kind soul to write a wizard that converts YouTube’s default code into code formatted as above.

It’s with some irony that I write this post, because one of the exciting things about HTML 5 is the video element that allows video to be added to a page with a simple <video src="blah.src" controls>I'm fallback content</video> and then plays it without any plugins or scripting. It allows an open, patent-free video codec to interact with canvas and SVG and it doesn’t require duplication of data twice or three times like the code contortions above.

Unfortunately it’s usefulness is mired in politics—see David Storey’s The future of video on the Web.

I’m too lazy to amend every instance from the last five years, but my home page is now valid apart from ARIA roles and an objection to the feed: protocol on a link to my RSS feed.

Thanks Patrick and fearphage.

Government guidelines, ARIA, microformats

Not so much a blog post but a collection of links.

UK government browser guidelines: good sense prevails

The Web Standards community changed some guidelines for government webmasters that would encourage designing to browsers into something that requires valid code, web standards and progressive enhancement. UK government browser guidelines: good sense prevails.

Talking of guidelines, I’m doing a short talk on Wednesday about BS 8878: Web accessibility – Building accessible experiences for disabled people at the Oxford Geek Night. See you there?

How Can I Validate (X)HTML + ARIA?

A while ago I speculated that the lack of a validator for ARIA might slow adoption. Steve Faulkner has written a proof-of-concept HTML4+ARIA Checker and hopes, as I do, that “the W3C validator adds support for (X)HTML +ARIA documents so I when check a document and it contains no errors in the HTML (except for the use of ARIA) and ARIA code, I see a message like this: this document was successfully checked. Passed (1 Warning)”

Should you think that ARIA is just w3c vapourware, there’s a podcast on ARIA by Freedom Scientific (the manufacturers of the JAWS screenreader) available:

Freedom Scientific’s Chief Technical Officer Glen Gordon explains ARIA and its benefits. Jonathan Mosen then demonstrates some applications with ARIA enabled for improved accessibility.

Didn’t see a transcript anywhere, surprise surprise.

More bandaids for microformats

Pat “Herb” Lauke wonders “if we should have an official anniversary each year where the same microformat/accessibility issue is rehashed” and links to an experiment by Andy Clarke. It’s a nice idea, but I think it’s a bandaid. I agree with Isofarro’s diagnosis:

It boils down to this: the title attribute is meant for human consumable content, just the same as the inner text of most of the HTML elements.

Everytime you put machine-formatted data into a container that is for human consumption, then you run the risk of it being exposed to a human being. In microformats this a ‘feature’, in accessibility this a ‘bug’.

I think that’s throwing the baby out with the bathwater to say “the easiest approach right now is to say Microformats are inaccessible, and move along”; it’s just this pattern that’s inaccessible.

Patrick suggests, “why not make a ‘title attribute’ pattern that allows for the use of the most semantically appropriate element? span with title in cases like datetime, abbr when it is actually an abbreviation.”

That makes sense to me. How would those plugins that make use of microformats cope if I marked up hCalendar dates with a span. Anyone know?