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?
Like everyone else, I post links to interesting stuff on Twitter. Some friends tell me that they miss those links because either they don’t follow me as I tweet lots of non-webdev stuff, or Twitter is blocked at their workplace.
So I plan to post those links to my blog. As with my tweets, I don’t necessarily endorse or agree with the links.
Listing useful links on blogs, eh? What an innovative idea.
Introducing HTML5 translations
A chum pointed me to Изучаем HTML5: our publishers tell us that translations are in progress into Simplified Chinese, Traditional Chinese, French, German, Italian, Korean, Polish, Portuguese as well as Russian.
Speaking Staffordshire University, Wed 16 Feb
I’m speaking with Remy Sharp and two other super-special guests (they haven’t announced yet) at Staffordshire University, Beaconside Campus. I’ll be talking about open Web standards. Remy will be talking about HTML5 APIs. Festivities begin around 1.30.
As I wearily stepped off a plane in which I’d been sandwiched between the two fattest Germans since Goering for ten chuckle-filled hours, my first sight outside the airport was the smiling visage of Web Directions organizer and all-round nice guy John Allsopp, who assisted me on the 70kms journey to my posh Ginza hotel.
Like two years ago when I travelled to Jakarta for the first time, I was weirded out by how familiar it felt: the elevated roads, skyscrapers and purposeful crowds reminded me of the four years in spent in Bangkok.
Just like two years ago, it was extra-strange when I realized that I had no language. I’m fluent in Thai, so it’s immensely frustrating not to be able to speak to people here.
Of course, after the superficial feeling of familiarity, the differences became apparent. The streets aren’t full of pot holes. The food is very different. There are ten bajilion vending machines where n Thailand there would be noodle vendors. The toilet in my hotel has more controls than the bridge of the starship enterprise. It’s not all different though: the women are, like Thai and Indonesian women, jaw-droppingly gorgeous.
The Japan-resident HTML5 Doctor, Oli, picked me up and we rode a pleasantly non-crowded train to Satoshi’s house, where I’m drinking a very welcome cold Kirin beer before dinner and writing this on John’s iPad.
I’ve wanted to visit Tokyo for twenty years and now I’m finally here. Yay!
As the colder nights harden, splashing autumn on gardens, I’m charging off to exotic climes to do the last few talks of 2010.
– Stafford University: HTML5, CSS 3
A live coding demo of some HTML5, and a bit of a rant about CSS 3. Non-students welcome.
The lecture will be 1-2pm in the blue lecture theatre Octagon building, and the Q and A session after in K129, Octagon Building at 2pm.
– Tokyo, Japan: HTML5: semantics and structure
A full-day workshop (with translation into Japanese) on using HTML5 markup. Sold out
The new HTML5 specification gives you 28 new markup elements to choose from. What do they mean? How do they work together? Bruce will answer these questions, and — most importantly — show how to apply them to real world sites. There are also many changes to HTML 4 elements, and even some obsolete elements, and you’ll find out the important differences. Finally, you’ll get a glimpse of the amazing things people are doing with HTML5 now, and an insight into the future of the web.
– Tokyo, Japan: Be an Iron Chef of HTML5
A one-hour talk with simultaneous translation into Japanese at the Web Directions East conference.
23 November – 1 December – Australia: The A Team: ARIA & HTML5
Five dates in Australia (Sydney, Melbourne, Canberra, Perth, Brisbane) speaking with The Mighty Steve Faulkner of The Paciello Group. Organised by the Web Industry Professionals Association, the 3+ hour long workshops cost $60 for members, $90 for non-members.
I’ve also done an interview with Remy (the editors have edited me to call him “Sharp” throughout, as though we were both pupils at Eton or something) in which we say crazy things like “you don’t have to use canvas, and you don’t have to immediately switch to HTML5″. It’s called HTML5: The 900-Page Gorilla with a Wide Ensemble.
A nice review of our book was published by Peter Steen Høgenhaug, noting that we “relate every part of HTML5 to accessibility”, which is great as that’s exactly what we set out to do.
I spent last week in Stockholm, giving 4 presentations, checking out the marvellous Vasa Museum and autographing a copy of our book with a picture of a unicorn and a double rainbow (Unicorns, butterflies, ribbons, rainbows & fluffy kittens feature on page 35 of the book).
And there are still quite a few talks to give before the end of 2010!
I’ve written an article on making sure your websites have a fighting chance of working across devices (mobiles, consoles etc).
It’s for web designers used to making desktop sites, rather than for people designing iThing apps.
The article was originally called “The ultimate guide to mobile optimisation” but the boss rightly said no (you could write a book about the subject, but all the main points are introduced in the article).
As someone who is timezone-maths challenged and forever dialling into international conference calls an hour early or an hour late, I greatly appreciated the intuitiveness of the everytimezone iPad app by Amy Hoy (idea & design) and Thomas Fuchs (development).
David Storey, Patrick Lauke and I set about exploring why. The answer was simple: browser-sniffing. The app was only looking for browsers with the strings “webkit” or “Gecko” in the user agent string, and only feeding those browsers the necessary code. So we copied the code and, as a proof of concept, added “opera” to the list of strings being sniffed, and made trivial amends to the JavaScript to send -o- prefixed styles.
Additionally, the main CSS was only using -webkit-border-radius and -moz-border-radius, while Opera and IE9 use the naked property name border-radius. (See my Writing cross-browser, future-proof CSS 3 for more on this.)
Adding this to our proof of concept made the application work in Opera. There are differences; Opera doesn’t support CSS Gradients so those don’t show (although an SVG gradient as a CSS background-image would work perfectly well) and a bug means it doesn’t pick up the Futura font. But visual differences are to be expected on the Web; it’s the content that’s king (or, in the case of an application, the functionality).
We sent this to Thomas, and very sportingly he made the code live, so now everytimezone.com works in Opera too. The moral is that it’s pretty easy to make your sites work across all modern browsers and, while you might expect the user to be coming from one specific device, if your app is on the Web (rather than a W3C Widget or some proprietary format like Apple app store) you can expect visitors using other devices, browsers and operating systems.
Of course, it won’t work in IE9, even though it was announced yesterday that IE9 will support canvas, as the browser-sniffing locks out all versions of IE, past and future. That’s the downside to browser-sniffing: it’s completely non-futureproof. If you make a deliberate policy to block a browser, and a future version of that browser is capable of supporting your code, you have to go back and amend your blocking code. If you have hundreds of sites in your portfolio, that’s a massive commitment.
So congratulations s to Thomas and Amy for a lovely little app; I can now dial into conference calls with confidence and punctuality!
Last Friday was our deadline and, with the spec changing all around us, Remy and I got all the chapters in for Introducing HTML5. There’s still much to do; we have to address comments made by our editor Jeff Riley, a copyeditor and our two technical editors Patrick Lauke and Robert Nyman, as well as add information about the brand-new track element.
Some people have asked for a chapter list. Here it is:
Introduction (why HTML5 exists)
Structuring a page (header, footer, nav, aside etc)
Marking up a blog (the outlining algorithm, other new elements, what’s removed, what’s changed, WAI-ARIA, case-study of HTML5ifying The Guardian homepage. This chapter is a monster so we may split it into two.)
Forms
multimedia (video, audio) markup and APIs
canvas
storage
Working offline
Drag and Drop
Geolocation
messages, web workers, web sockets
From the introduction:
Who’s this book for?
No knowledge of HTML5 is assumed, but we expect you’re an experienced (X)HTML author, familiar with the concepts of semantic markup. It doesn’t matter whether you’re more familiar with HTML or XHTML doctypes, but you should be happy coding in any kind of strict markup. While you don’t need to be a JavaScript ninja, you should have an understanding of the increasingly important role it plays in modern web development, and terms like DOM and API won’t make you drop this book in terror and run away.
What this book isn’t
This book is not a reference book. We don’t go through each element or API in a linear fashion, discussing each fully and then moving on. The specification does that job in mind-numbing, tear-jerking, but absolutely essential detail. What the specification doesn’t try to do is teach how to use each element or API or how they work in the context of each other. We’ll build up examples, discussing new topics as we go, and return to them later when there are new things to note.
You’ll also realise, from the title and the fact that you’re comfortably holding this book without requiring a forklift, that this book is not comprehensive. Explaining a specification that needs 900 pages to print (by comparison, the first HTML spec was three pages long) in a medium-sized book would require Tardis-like technology—which would be cool—or microscopic fonts—which wouldn’t.
The publishers are intransigent about page-count, so there’s lots that we can’t put in (but we cover the important things that are being implemented today). There also wasn’t room for “sexy photos of the authors looking dreamy lying on fluffy shag pile animal pelts, 70s style” that one HTML5 Doctor requested, although we may have a contest in which the lucky winner gets 2 hours in which to take such photographs.
Other people have expressed surprise that I had never been to SxSW before (last year I had the chance to go to India so went there instead) and it was with some trepidation that I went to bring the good news about Opera, HTML5 and give the Texas ladies the chance of some hot lovin'.
I very much liked Austin - or "Steve" as I like to call it - and it's become my new favourite American city; I used to like San Francisco but against Steve, it feels a bit like Brighton - too self-consciously cool to be relaxing.
I didn't see many talks as I had to be a boothbunny, but (to be brutally honest) I wasn't terribly impressed with those I did make it to. The panel format seemed a bit like paying to watch at a circlejerk, with everyone agreeing and congratulating each other, although I was impressed with some. The parties were not my thing either; I'm decades past queuing for an hour for a chance to shout at people you want to talk to (bah humbug get off my lawn). The free drinks in the lobby of my hotel every evening was far more conducive to chatting, sharing a laptop and doing the things I like to do with interesting people.
Fortunately, the "interactive workshop" I presented (which was actually a traditional presentation; there's no workshop potential with 400+ people in a room) was on Sunday so I had a couple of days to relax afterwards. (Slides are available for your downloading pleasure). It was a full house, with some great feedback ("Bruce Lawson is like an open-source Steve Jobs") - thanks all! Special thanks to Martin Kliehm for inviting me to take part in the 3 hour extravaganza he curated.
One of the highlights was talking to real customers on the booth. Many challenged our "fastest browser" claim, and went away pleasantly surprised when they found their own sites rendering so speedily. It was also great to blow the "Opera has a bad UI" bullshit out of the water.
The other highlight was meeting so many people that I know on the Web, but rarely meet in real life—people like the unrepentant hardliner, John Foliot, baby-eating Matt May and lovely people who I'd never actually met before, like Allan Kent (on-line friend since 2003), Jared Smith of WebAim and the best-dressed lady in Web, Nimbupani.
That nice Dan Oliver from .net magazine did an interview with me:
I got to eat a burger (Whataburger!) for breakfast, hang in the Media Temple VIP room, wear a Mexican wrestling mask and a glittery camisole. There are a few photos, fewer memories and, apart from liver made of paté and terminal jetlag, I survived my first South By SouthWest.
As I sit here in Austin, Texas munching a breakfast of bafflingly-termed foodstuffs like “eggs medium over-easy”, “white omlette” and incorrectly-pronounced tomatoes, I thought I’d update you on a few HTML5 tidbits.
The first is the news that Google will start indexing content marked up using microdata. No browser does anything with data it finds in pages, but the voodoo magicians that do SEO will presumably find the chance of extra googlejuice compelling.
I’m a lurking member of two W3C subgroups that work on the accessibility of video and canvas. We recently had two internal votes. The first was on what type of captioning format should be supported, and asked us to choose between the .srt format (a plain text file with time markers and text) or the W3C standard DXFP which, although minging, allows markup. (.srt seems to me to be as limited alt text on an image; it can’t contain markup or styling information). I voted for DFXP because, at its most basic it doesn’t need to be more complex than plain .srt, but has the potential for extensibility when browser implementations become more sophisticated. (My vote was a personal opinion and not an official Opera vote, by the way.)
The second vote that’s taking place is about extensions to canvas. There are two main proposals, one is for a new attribute called adom (for “accessibility DOM”) that constructs a “shadow DOM” for assistive technologies can hook into – and which the author must ensure is in sync with the visual rendering. I’m uncomfortable with this proposal for reasons that I’m not quite able to articulate at the moment (but its author is at South By Southwest so I hope to be able to catch up with him for a chat).
The proposal that I like is to extend canvas is “Improve image maps, don’t use @adom” which I favour because it uses familiar markup and reuses ideas from (and browser implementations of) HTML4. (Disclosure: the proposal was made by Chaals, Head of Standards at Opera, but that’s not why I prefer it.)
Anyway, gotta go and shower my pits before booth-bunnying the Opera South By Southwest booth. It’s in row 300 of exhibition room 4. Why not stop by a chat, especially if you’re a gorgeous Web Standards babe, or have a black coffee for me? Alternatively, I’m first speaker at an HTML5 extravaganza on Sunday from 2 to 6 pm.