Archive for the 'accessibility web standards' Category

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 Codemotion.it – Microsoft, Mozilla & “I’m Bruce from Opera, and my browser’s the fastest”.

Reading List

URLs

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 html5accessibility.com 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.

TL;DR

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

Misc

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>
</DIV></DIV></DIV></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.

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

(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.”

Also

  • 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”
  • webcomponents.github.io “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