First impressions of Tokyo

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!

(Photos)

Notes on Japanese toilets

There are times when even as a seasoned traveller you can feel pretty vulnerable. For example, breakfast: I’m as happy to tuck into raw mackeral as an evening meal, but there’s something about it for breakfast that is so unexpected that it takes you aback.

I’ve had similar double-takes with Japanese toilets. I went to Satoshi and Akane’s house for a lovely meal and, as you do after lots of soup and beer, felt the natural urge to micturate. Although they have a lavish toilet control panel (all of them do) I couldn’t work out how to flush.

After asking my gracious hosts, I learned that it was activated by infra-red. This is in contrast with the toilet in my hotel room, whose control panel had English language controls, and squirted water up my bum and around my bum at user-selectable strength (below), but didn’t seem to have a flush button.

I eventually located a traditional manual flush on the opposite side of the toilet bowl, and satisfactorily dismissed my ablutions.

Most Japanese toilets have heated seats, which is a bit of a win but odd when alone in a hotel room as you can’t help but wonder who has snuck in to poo while you were cleaning your teeth. Many flush for an inordinately long time automatically the instant you sit down; I’m told so that this means you’re unable to hear the sound of ladies urinating, as it’s masked by the flushing sound. I suppose that if you’re bashful about exposing the fact that ladies pee (they do, you know!) this would be a useful solution in a traditional thin-walled Japanese house in which sound would travel easily.

This theory might be borne out by the testimony of a lady attendee of the Web Directions East conference who told me that each ladies’ loo in the conference venue (consequent apologies for lack of photo) has a button marked “flushing sound” that played a loud recording of the sound of flushing, presumably to conserve water.

(@johnmcc sent a photo of a loo with a “flushing sound” button.)

Talking of water conservation, the apotheosis of lavatorial environmental responsibility was witnessed in my colleague Daniel’s apartment. On flushing the toilet (a laudably easily accomplished action, I might add), the tap on a small sink mounted above the cistern started automatically. I washed my hands and wondered how to turn the tap off. Then the brilliance of the design hit me: instead of re-filling a closed cistern, the washbasin drained the soapy water into the reservoir below, thereby flushing the toilet with the grey water that the previous visitor had washed his/ her hands in while simultaneously saving space in the compact Tokyo dwelling.

Genius. If I could work out a way to import them and sell them in the UK I’d make a million.

Big down under

My global tour continues, and I’ve moved from Tokyo to Australia, where I’m touring Sydney, Canberra, Melbourne, Perth and Brisbane with organiser and all-round-great-bloke Roger Hudson and The Mighty Steve Faulkner, for the Web Industry Professionals Association. We’re talking HTML5 and WAI-ARIA. (So far, there are a few places left for Perth and Brisbane: book here.)

I’m very much enjoying Aus. It feels like England done right: good weather, laid-back attitude and fabulous hot-pants (not me, obviously). The only downside is the vast pantheon of comically venomous creatures that lurk round every corner. In Canberra I was even warned about evil swooping magpies.

The tour so far has been great; sell-out crowds and really, really clued-up (“cluey”) attendees and great people like Russ Weakley, Ruth Ellison who I’ve long admired but never met.

The flight from Canberra to Melbourne yesterday was somewhat fraught; we took off two hours late due to what was variously reported as “mechanical trouble”, “bad weather in Melbourne” and “a catering mishap that was particularly unpleasant”. (At least it wasn’t exploding engines.) On arrival the doors wouldn’t open and the fuselage rocked as the ground staff attempted to bash the doors open with the airbridge. We arrived at the venue with only minutes to spare.

Now I’m having a weekend (shifted forward by a day as I fly to Perth on Sunday morning) in Melbourne with my old and dear friend Pippa. We’ve already seen a park full of flying foxes and are off to see Kangawallabats at the zoo tomorrow. Tonight I’m cooking us pork stirfry noodles and gyoza and there is a case of beer to drink.

The oil’s sizzling. Gotta go.

On the hgroup element

The more I try to explain it to people at workshops and in a marvellous book, the more uncomfortable I become with <hgroup>.

In the spec, it’s defined

The hgroup element is typically used to group a set of one or more h1-h6 elements — to group, for example, a section title and an accompanying subtitle.

It has no rendering; its sole purpose is to hide subtitles from the outlining algorithm which browsers, third party sites (warning:broken) or bookmarklets may use to make document outlines/ tables of contents.

So if you have the following code

<header>
<hgroup>
<h1>bruceawson.co.uk</h1>
<h2>Gorgeousness in a gimp mask</h2>
</hgroup>
</header>

only the <h1> appears in the outline; the <h2> is suppressed. (The highest-ranking heading wins.) More on <hgroup> at HTML5Doctor.

The trouble with this is that there is a new magic element that does nothing except change the semantics of its contents in a way that is new (there has never been an outlining algorithm before) so it’s difficult to grasp.

There was discussion about minting a new <subtitle> or <tagline> element instead. This has the advantage that it”s much easier to grasp the purpose of it. However, these new elements would have no default rendering in legacy user agents and, the argument against continues, people are already marking up subtitles as headings, so this way paves a cowpath. (I have my doubts: I usually encounter constructions like <p class=tagline>Gorgeousness in a gimp mask</p> for subtitles).

Thinking out loud here, but I wonder if we need explicitly to group headings and subtitles, anyway. It seems to me that an outlining algorithm should just treat multiple headings (<h1>…<h6>) that are direct children of a header element to be a group of “main heading” and subtitle(s) automatically. So

<header>
<h1>brucelawson.co.uk</h1>
<h2>Gorgeousness in a gimp mask</h2>
</header>

would automatically “know” that the <h2> is the subtitle and not be shown in an outlining application.

This would only work for direct heading children of a <header>: here’s an example of multiple heading descendants in which the <h3> is not a subtitle:

<header>
<h1>brucelawson.co.uk</h1>
<h2>Gorgeousness in a gimp mask</h2>
 <nav>
 <h3>Main navigation</h3>
 <a href="home.html">Home</a>
 <a href="about.html">About</a>
 </nav>
</header>

I can’t think of any use cases for multiple headings as children of a <header> that wouldn’t be main heading + subtitles.

Can you?

(Also: ambiguities in mapping <hgroup> and ARIA information.)

Added later, after coffee: The outlining algo would only need to say: adjacent headings in a <header> are automatically considered to be a heading and subtitles, whether there be 2 or 22. Then, even if there were two headings for the <nav> inside the <header>, they would be automagically heading and subtitle.

On the hgroup element

The more I try to explain it to people at workshops and in a marvellous book, the more uncomfortable I become with <hgroup>.

In the spec, it’s defined

The hgroup element is typically used to group a set of one or more h1-h6 elements — to group, for example, a section title and an accompanying subtitle.

It has no rendering; its sole purpose is to hide subtitles from the outlining algorithm which browsers, third party sites (warning:broken) or bookmarklets may use to make document outlines/ tables of contents.

So if you have the following code

<header>
<hgroup>
<h1>bruceawson.co.uk</h1>
<h2>Gorgeousness in a gimp mask</h2>
</hgroup>
</header>

only the <h1> appears in the outline; the <h2> is suppressed. (The highest-ranking heading wins.) More on <hgroup> at HTML5Doctor.

The trouble with this is that there is a new magic element that does nothing except change the semantics of its contents in a way that is new (there has never been an outlining algorithm before) so it’s difficult to grasp.

There was discussion about minting a new <subtitle> or <tagline> element instead. This has the advantage that it”s much easier to grasp the purpose of it. However, these new elements would have no default rendering in legacy user agents and, the argument against continues, people are already marking up subtitles as headings, so this way paves a cowpath. (I have my doubts: I usually encounter constructions like <p class=tagline>Gorgeousness in a gimp mask</p> for subtitles).

Thinking out loud here, but I wonder if we need explicitly to group headings and subtitles, anyway. It seems to me that an outlining algorithm should just treat multiple headings (<h1>…<h6>) that are direct children of a header element to be a group of “main heading” and subtitle(s) automatically. So

<header>
<h1>brucelawson.co.uk</h1>
<h2>Gorgeousness in a gimp mask</h2>
</header>

would automatically “know” that the <h2> is the subtitle and not be shown in an outlining application.

This would only work for direct heading children of a <header>: here’s an example of multiple heading descendants in which the <h3> is not a subtitle:

<header>
<h1>brucelawson.co.uk</h1>
<h2>Gorgeousness in a gimp mask</h2>
 <nav>
 <h3>Main navigation</h3>
 <a href="home.html">Home</a>
 <a href="about.html">About</a>
 </nav>
</header>

I can’t think of any use cases for multiple headings as children of a <header> that wouldn’t be main heading + subtitles.

Can you?

(Also: ambiguities in mapping <hgroup> and ARIA information.)

Added later, after coffee: The outlining algo would only need to say: adjacent headings in a <header> are automatically considered to be a heading and subtitles, whether there be 2 or 22. Then, even if there were two headings for the <nav> inside the <header>, they would be automagically heading and subtitle.

The Ghosts of ARIA Present and Future

Today, two articles were published on A List Apart about ARIA (Accessible Rich Internet Applications) – The Accessibility of WAI-ARIA by Detlev Fischer and ARIA and Progressive Enhancement by Derek Featherstone. Like the ghosts in Dickens’ A Christmas Carol, they present an accurate, though somewhat depressing picture of the current and potential future state of things.

The Ghost of ARIA Present

Scrooge entered timidly, and hung his head before this Spirit. He was not the dogged Scrooge he had been; and though the Spirit’s eyes were clear and kind, he did not like to meet them. “I am the Ghost of Christmas Present,” said the Spirit. “Look upon me.”

In Dickens’ classic, the Ghost of Christmas Present shows Scrooge the dismal state of present affairs. As the ALA articles detail in great length, ARIA support is quite a mess. While we’ve seen good adoption of ARIA support in some areas, it is still very buggy and not useful to the vast majority of screen reader users. The fault here lies primarily with browsers and screen readers.

ARIA is supposed to alleviate the need for accessibility hacks, workarounds, fall-backs, and alternative versions. Instead, because of patchy support, these are the very things necessary in order to implement much of it.

Still, ARIA is new. In fact, it’s less than new – it’s not even a finalized W3C specification yet. Implementing ARIA into user agents is difficult, especially considering the limitations of the accessibility APIs on current operating systems. Despite this, we’ve seen ARIA implemented to varying extents in most modern browsers, many screen readers, and in authoring tools and scripting libraries. It is unreasonable to expect that ARIA will work perfectly right out of the box. However, unlike the ALA articles, I will not focus on the current state of ARIA, and think that developers for the most part shouldn’t either. Instead, we should be focusing on what we can and should do to ensure that support increases as we move forward.

What to do now?

Both articles recommend that great care be taken in implementing ARIA. This certainly is true. Detlev Fischer suggests that using anything more than the most basic of well-supported ARIA semantics will almost certainly make things worse for screen reader users. I, however, believe that there is much that can be done today to enhance web content with ARIA that can only make content more accessible on platforms that support it. And Derek Featherstone shows this to be true with several practical uses of ARIA to enhance already-accessible content. There are, however, some important points that I believe should be addressed.

Some things cannot be made accessible without ARIA!

These articles suggest only two courses of action: 1) don’t build it, or 2) build it so it remains accessible without end-user ARIA support. These, unfortunately, are not viable options for many modern web applications. We certainly should encourage the progressive enhancement approach to accessibility. We should build highly accessible web apps with all of the available and widely supported tools and markup available, and then use ARIA to make it even better. But this is not always possible for complex web applications – and Derek Featherstone demonstrates that it’s not even really possible right now with even very basic interactive elements such as a required form field.

The Ghost of ARIA Yet To Come

"The Phantom slowly, gravely, silently approached. When it came near him, Scrooge bent down upon his knee; for in the very air through which this Spirit moved it seemed to scatter gloom and mystery."

Developers will continue to innovate with or without accessibility. Because not building it is not an option and because some things cannot be made accessible without ARIA, developers are left with two options – build it potentially accessible with ARIA or build it perpetually inaccessible without ARIA.

I believe that most developers want to make things accessible, particularly once they know how. ARIA allows them to do it right the first time. We must allow developers to focus on potential accessibility, rather than bogging them down with the complexities of current support. Implementing ARIA is not very complex, especially compared to scripting or even HTML5. But, understanding current ARIA support is a nightmare. Trying to implement ARIA detection and degradation where it is not supported is a nightmare that nightmares have. Developers try to avoid nightmares, so let’s not force one upon them.

If we take a hard-line approach and insist that developers wait for ARIA support (whatever that means) rather than implementing ARIA now despite today’s incomplete support, they will most often throw their hands in the air and build it without ARIA and accessibility at all.

This is especially true with the many web applications that are already in place – ones that will never be rebuilt with full accessibility, but that could be greatly improved by adding minor ARIA enhancements. By suggesting that full ARIA support and fallbacks are required, we are encouraging that these apps remain inaccessible into perpetuity.

While the Ghost of Christmas Yet To Come convinced Ebenezer Scrooge to change, I fear that web app developers are not always so repentant – whether we like it or not, their future is pretty good with or without accessibility.

If you build it…

I once visited the baseball field where The Field of Dreams movie was filmed. A theme of this movie was, “If you build it, they will come.” With the current state of ARIA, we are telling developers, “Don’t build it, because some can’t currently come.” While our intentions are certainly noble – we don’t want to leave folks behind – the result of asking web developers to hold off on innovating until ARIA support improves is that developers will instead innovate anyways without ARIA support at all. The result is much worse accessibility.

Now I’m not advocating that we simply forget about the many limitations of ARIA. The ALA articles outline many of these limitations ad nauseum. My point is that if we want ARIA to succeed, we must look beyond the limitations of today. We must advocate that people start building with it by the book now. This means building things to be as accessible as they can be, then using ARIA to make them better. And when ARIA is required for accessibility, do that, because it’s better than the alternatives.

If we focus on supporting ARIA as it is now, support will largely remain how it is now. We should instead advocate that developers build things following standards, increase our pressure on browser and assistive technology vendors to increase their support, and help users understand the increased accessibility they can experience by using standards-compliant web browsers and assistive technology. The future of ARIA is bright, but only if we make it so.

“Men’s courses will foreshadow certain ends, to which, if persevered in, they must lead,” said Scrooge. “But if the courses be departed from, the ends will change.”

Some thoughts on ARIA support detection

In his conclusion, Derek indicates that we “need to be able to detect ARIA support in assistive technology so that we know if ARIA is supported in those user agents.” While this initially seem like very appealing functionality, I believe that if this were possible (it isn’t, and probably won’t ever be), the results could be very damaging. The fact that we cannot detect assistive technology has resulted in significant increases to mainstream accessibility. An ability to detect assistive technology support would have potential to allow for complex enhancements to accessibility, but in reality, I fear it would lead to fragmentation of code and user experience at best, and “You must have JAWS 12+ to view this page” at worst.

Fixing Alt - If Web Browsers Were Celebrities

A humorous infographic was recently published and twittered about, If Web Browsers Were Celebrities (full image). I've noticed more than several of these in the last few months, and one big issue about them continues to nag me: there's no sufficient alternative text! (Also a good case for the longdesc attribute!)

So I decided to to my typing skills to work and provide the alternative text. Hopefully there will be more of these to come on this blog. So here it is, the alt text from the If Web Browsers Were Celebrities infographic:

Browser Compatibility; If Web Browsers Were Celebrities

[Each item includes a nice, large browser icon and a cartoon-style avatar of the celebrity's face.]

Firefox - Can do no wrong, though not as spry as it once seemed. Would be: Morgan Freeman.

Chrome - The new hotness. People love it so much they're nervous it will go wrong and embarrass them later. Would be: Christopher Nolan.

IE6 - Everyone thought it died a long time ago, but still seems to crop up all over the place. Would be: Betty White. [LOL!]

IE7 - After years of giving it chance after chance, performance never gets better. Would be: Matthew McConaughey.

IE8 - Trying desperately to stay relevant, even though it's still the same thing. Would be: The Shatner. [William Shatner]

Safari - Reliable performance, seems to be everywhere. Would be: Samuel Jackson. (Just wait til he collaborates with 'Chrome')

Flock - Hip, but people don't take it seriously anymore. Would be: Michael Cera.

Netscape - When it died, everyone said 'Oh yea, that one!' and then forgot all about it. Would be: Walter Matthau.

Opera - Only ever used if you already have 100 tabs open in IE, Firefox isn't available, and you have no toher choice. Everyone agrees it looks nice, though. Would be: J-Lo. [Jennifer Lopez]

IceWeasel - Who? You mean that weird one? Would be Kristen Schaal (AKA Mel on Flight of the Conchords)

Requires No Browser - Is unquestionably Keanu Reeves. [Avatar of Keanu says 'Wo']