Autumn

The smell of roasting dust heralds the fan heater’s first use of the autumn, like the smell of the crematorium we’re all another year closer to.

On the accessibility of web components. Again.

I enjoyed watching Dimitri Glazkov’s introduction to Web Components Easy composition and reuse with Web Components, given at the Chrome Developer Summit. It’s an excellently-constructed talk that builds on the use-cases that web components address to make a compelling argument for the technology.

At 11 min 55 seconds, after a slide reading “Make HTML useful”, Dimitri says

Custom elements is really neat. It basically says, “HTML it’s been a pleasure”.

There we are. Bye-bye HTML; you weren’t useful enough. Hello, brave new world of custom elements. Of course, this isn’t the full messaging; a 20 minute video can’t go into the nuances. But it’s what a lot of people are hearing.

Let’s straighten that out.

One of the advantages of oh-so-boring HTML was that certain elements carried default behaviours in browsers and assistive technology. Like, when you use this mark-up

<label for="form-name">What's yer name?<label>
<input id="form-name">

and you click on the label, the focus goes into the associated input. There’s no need for JavaScript, there’s no fancy stuff extra for a developer (except setting up the association with the for="" attribute), and there’s a significant usability and accessibility advantage for the end-user.

A recent HTML5 Rocks article by Addy Osmani and Alice Boxhall called Accessible Web Components begins with the words

Custom Elements present a fantastic opportunity for us to improve accessibility on the web.

Yes. Yes. Yes. (Thanks Addy and Alice!) It’s perfectly possible to make web components and custom elements accessible. Alice has an example which I’ve screenshotted in Opera (top) and Safari (bottom).

boxall

Note that in the Safari screenshot, the second column of sexy checkboxes don’t work at all – there is no checkbox. That’s because Safari doesn’t support web components. You’ll see the same in IE, or browsers without JavaScript.

Note that the first column does render in Safari, but it’s just normal checkboxes; they aren’t sexy web component-ised as they are in Opera. But – crucially – you can still interact with them, as they’re web components progressively enhancing silly old “useless” HTML. It works like this:

<input type="checkbox" is="io-checkbox">

Simple, huh? You have a silly old useless HTML element, and a new attribute that says “this is extended via web components into a special element I’m calling ‘io-checkbox'”. The web component inherits all the silly old useless behaviour like associating labels with form fields, activation with keyboard for free.

Compare with the sexy but not progressively-enhanced way that doesn’t work in older browsers (the second column):

<io-custom-checkbox tabindex="0" role="checkbox"></io-custom-checkbox>

There’s a super-whizzo-fabbo-megalicious UltraShiny custom element there, which has no graceful degradation. It needs a tabindex and a role there because who wants that silly old useless HTML behaviour? Not us! We’re post-HTML. Yay!

Snarking aside, why do so few people talk about extending existing HTML elements with web components? Why’s all the talk about brand new custom elements? I don’t know.

Of course, not every new element you’ll want to make can extend an existing HTML element. In this case, you can still make your custom element accessible. Just because you’re in the super-whizzo-fabbo-megalicious UltraShiny world of web components, you can – and should – still add ARIA information to make your code accessible. Just because you’re hiding nasty code behind the Shadow DOM, it doesn’t mean that you can brush proper coding under the web components carpet.

You’d hope that those who are assiduously pushing components into the platform would ensure that their demos did this – after all, those demos are meant to be studied, copied and adapted by developers, right?

Wrong. Take a look at Polymer gmail, a “Polymer version of New Gmail app”. Patrick Lauke points out

Google has expertise in-house to create functional, beautiful, web-component stuff that is also accessible. It would be great if high-profile demos like these would actually take advantage of those resources to create things that work not just for sighted mouse/touchscreen users…

To which he received the reply

There’s plenty that can be done in the convenience of unlimited time and resources. If you’d like to help, please submit a PR.

A big demo of a Google cutting-edge technology, made by Google, and there’s no resources simply to make it accessible.

At Paris Web, Karl Groves and I talked about Web Components – the right way, we talked of extending existing elements, adding ARIA and suggested that web accessibility advocates actively fix issues on Open-Source projects. But I meant fixing small projects that you’re using in your own sites – like the WordPress Live Comment Preview plugin, which I tweaked, thereby making 44,837 sites accessible.

I wasn’t talking about fixing demos by a company with a $362.48 Billion market capitalisation. As Patrick Lauke so eloquently puts it:

My resources are currently a bit more stretched than Google’s…but I’ll put it on my to-do list ;)

I’m a fan of web components. But I’m increasingly worried about the messaging surrounding them.

Device Detection vs Responsive Web Design

This week’s reading list is devoted to Device Detection vs Responsive Web Design.

With all the cool kids getting into RWD these days, it’s time to have a look at the Device Detection companies again. Device Detection is the practice of matching a device’s UA string against a table of such strings and looking up certain characteristics of that device and then serving different websites accordingly.

Of course, the utility of such services is dependant on the quality of the look-up table: how many devices does it know about (all the ones in the world, ever?), how frequently it’s updated (have they added the Umbongo J2O TrouserPhone S+ that was released on Tuesday, yet?) and how accurate is that data (does the TrouserPhone S+ really have 178680979 X 7 pixel smellovision display?).They are, however, an order of magnitude more reliable than terrible CMS plugins or JavaScripts that were written years ago and which register IE11 as IE1, or don’t know Chrome exists. UA strings are comically unreliable, being the frontline in an unceasing battle between browser-sniffers who want to deny entry to certain browsers, and browser vendors who want their users to get a first-class experience.

Examples of Device Detection companies include scientamobile (WURFL), DeviceAtlas and 51Degrees. The databases owned by such companies do include device characteristics unavailable through client-side detection. For example, you can’t find out from JavaScript whether a device is actually a touchscreen device; the physical dimensions of a screen or the retail price of a device (which advertisers want to know, apparently – you only want to advertise yachts to gold iPhone or Umbongo J2O TrouserPhone S+ owners).

Mike Taylor, an ex-colleague of mine at Opera, now at Mozilla (and pathological hater of chickens) set up a collaborative document to collect use cases that people are trying to solve with UA detection (which can’t be solved by feature-detection), which is summarised by Karl Dubost (ex-Opera, now Mozilla) in User Agent Detection Use Cases.

Those who oppose Device Detection do so for philosophical reasons – it’s one web and we shouldn’t serve different content to different devices or browsers, or they are certain browser vendors: Internet Explorer, Firefox OS and Opera all have reasons to dislike browser sniffing or device detection (“this website is only available to iPad users”). Google uses device detection all the time on its properties, as do many other large companies.

The device detection companies have begun to issue reports comparing their products with responsive, client-side techniques. Here are three that I’ve seen this week:

They’re worth reading. Of course, case studies only go so far; every business, territory and site is different. One thing everyone agrees on is that performance matters – slow sites lead to fewer conversions. mobiForge has an article M-commerce insights: Give users what they want, and make it fast that claims

RWD sites were the slowest, on average, to load on mobile – 8.4 seconds – while dedicated mobile sites loaded fastest – in 2.9 seconds. Non-responsive desktop sites took 6.57 seconds to load.

I’d like to see proper A/B testing: a well-made responsive version of a site versus its “m-dot” equivalent, redirected from its canonical URL and assembled after a device look-up, across a variety of devices and network conditions. If we’re going to argue, it might as well be about data.

Update 1 Dec 2014: Here’s some initial research on the top 1,000 mobile websites: M dot or RWD. Which is faster? that concludes that “m dot” sites are 50% slower for time to first byte, and

RWD sites are VERY competitive on Visually Complete and SpeedIndex scores. The median values are within 5% for both metrics. Even though it appears that RWD is faster, there is enough fluctuation in the data that we should probably call it a dead heat.

Reading List

Pasternak: his transgression, and my revenge

This little poem popped into my mind on the Underground. (I’m very, very tired.)

Boris Pasternak
farted on my haversack.
I kicked him in his knackers-sack
(I had to get the bastard back.)

Moments 3 (10.7.87)

After posting my old song Speed Of Light which contains the delicate phrase “fucking in the summer rain”, I remembered this poem that I wrote about the same incident, with slightly more genteel vocabulary.

It’s part of the same series of poems as It is a hot evening in July that I wrote to try to capture a precise moment in time or emotion.

Moments 3 (10.7.87)

The lethargy of evening
insects in the long grass
the langour and the language
I will not find a meaning
I will not bind my feeling

soft rain silvers cobwebs
on the stone for Stan and Ellen
that we lie upon all grassy
when the world gives up its whirling
for an instant small as insects
in the calmness after climax
in the stillness of the twilight
we are here

Reading List

The Lucies, live, 1991

When I was clearing my dad’s house I found the VHS tape on which there was the only video of my band doing a gig. I don’t know who took the video, but here are five songs recorded in a tent at a festival in the West Midlands in 1991. The band are me (rhythm guitar, vocals), Tony Sherrard (bass), Andrew Cope (drums) and Nick Sherrard (lead guitar). We were called “The Lucies”. Here we are as a three-piece before Nick joined, with some hanger-on called John Peel.

3 young men in horrible shirts with John Peel

This song is one I wrote called “Silka, Wearing Fancy Dress” in Summer ’91. There’s a studio demo with variant lyrics available. Words, music © Bruce Lawson.

Silka walks in those evenings When you feel like you’re still a virgin.
You don’t trust your feelings, Silka’s certain she’s hurting.
She is dressed in lace when she says, “Yes, yes, I will; of course I will, yes” -
But if you feel the need to believe her,
remember – Silka’s in fancy dress.

Silka in black satin, like the Mona Lisa if she were in mourning.
You try to please her, then with no warning
There’s a pause for the sinful applause and your unsatisfying taste of success
and the knowledge of the flaws that you hate, then through the door
comes Silka in fancy dress.

Bejewelled in a shattered promise, she’s wearing fading fraying denim.
You’re pierced by inverted commas
that have appeared round the tales she’s been telling you for so long.
She’ll decree: “Everybody loves me”, but it’s too late for you’ve already guessed
Underneath there’s nothing that’s real to see; Silka’s only fancy dress.
Really, she’s merely fancy dress.
She’s very nearly Silka, wearing fancy dress.

Keep your mind and your eyes closed;
Silka’s wearing borrowed clothes
and all her cheap and gaudy trinkets.
Silka said she’s gonna crash; listen. Sing it.

Let no-one say The Lucies couldn’t rock out. However, accusations of leaving heavier songs open to extemporised guitar noodling and never properly rehearsing how to end them will be met with hands in pockets, eyes averted and shuffling of feet. “Dancing (Across a backdrop of Stars)” is a moronic heavy riff I wrote, with some vaguely psychedelic words I wrote after bring mightily impressed by a performance by the London Contemporary Dance Theatre. Words, music © Bruce Lawson

“Don’t Bring Me Down” is a storming bassline and tune by Shez, with some blahblah words from me about not harshing my mellow because “I’m lost, don’t wanna be found again” and “floating in colours and sound again” etc. It’s for this reason we were called “The Hallucinogenic Freedom League” (later abbreviated to “The Lucies” because no-one could ever spell the full name). There’s a studio demo available. Words, © Bruce Lawson, Music © Tony Sherrard.

This song – called “The Missionary’s Position” – is proof that a short satisfying riff repeated ad infinitum with jazz chords (F9 – E9- D7- A7, woo!), funk bass, wiggly wiggly heavy rock lead and a bluesy middle break doesn’t add up to a good song. Note Paul, the roadie/ soundman putting his spare wheel in front of the bass drum, as Andy played so hard his drum was moving away from him. Words, music © Bruce Lawson.

This last one is a ballad called “Sweet Sadie Sings”. It’s one of my favourite songs I wrote for The Lucies because (1) it has a nifty G add9 chord, (2) it has a shouldn’t-work-but-does F#m to F change and (3) because I remember who the real “Sadie” is. But what’s in a name if the name’s been changed?

Live, it suffers a bit from lack of variation – the studio demo has a sexy extra guitar line by Shez, the bassist. This performance got me dangerously close to being blacklisted by the Tortured Artists and Singer-Songwriters Association as I visibly, and publicly, smiled while singing it. Words, music © Bruce Lawson

Sadie sings sweetly
about all of the things she’s done
and says, “They can’t be classified neatly
into those I’ve lost and those I’ve won.
For experience gained
My innocence has been shamed.
until only empty words remain.”
Sweet Sadie sings.

Sadie sings softly
of the last twenty-seven times she’s been in love
and says “If you would only get off me
I could transcend this wrecked room and rise above
My stupid hopes and my facile fears
My futile dreams and my fatuous fears.
I never claimed that I was proud of these last three years.”
Sweet Sadie sings.

Sadie is grieving
for the dreams she’s nurtured and then denied.
She said, “One November evening
I took them out and I laid them bare and there they died.
I know that I am far too small
to contemplate ever achieving them all,
so on the way some of them fall.”
Sweet Sadie sings.

Sadie sings sadly
conscious of her words’ ambiguities.
She says “Who’s to say I’ve done so badly
when all I’ve ever really done is try to please?
For experience gained
My sense of wonder has waned.
What’s in a name when the name’s been changed?”
Sweet Sadie sings

Reading List

Notes on draft CSS “alt” property

A while ago, there was discussion in CSS Working Group about an alt property to be added to CSS. Its purpose is to let assistive technology know the meaning of unicode characters inserted into a visual rendering of a document with CSS generated content. The problem is described by James Craig, Apple’s nice accessibility chappie.

It’s been shipping as -webkit-alt for a year now, and has just been added to the draft CSS Pseudo-Elements Module Level 4 spec. Let’s say you’re using a star glyph to show something is “new”, by generating CSS content using a class of .new as your selector:

.new::before { 
  content: url(./img/star.png);
  alt: "New!"; 
}

The alt gives information to assistive technology.

The alt string can be blank. Assume you’re generating “►” to show that a widget is expandable. Because you’re a lovely human being and a responsible developer, you’re using aria-expanded="false" in the HTML. Therefore, you’d use empty alt in the CSS that generates the glyph to prevent assistive technology “helpfully” reading out “Black right-pointing pointer” after the AT has relayed the ARIA information to the user:

.expandable::before {
  content: "\25BA"; /* a.k.a. ► */
  alt: ""; 
  /* aria-expanded="false" already in DOM, 
     so this pseudo-element is decorative */
}

Update 17:05 GMT fantasai of the CSS WG has mailed the CSS Working Group protesting against the syntax above. I don’t have any horse in the syntax race; my aim with this post is to show that we need some mechanism to give alternate content to assistive technology given that we allow non-textual content to be generated via CSS.

When I tweeted about this earlier, a few people objected to the concept because it adds content to CSS. But that ship has long sailed, with the content property that people have been using for ages. If you say “adding non-decorative content to a page is a misuse of CSS that merits the author 100,000 years in purgatory with Tim Berners-Mephistopholee pouring hot Ovaltine over their dingle-dangles whenever they try to sleep”, I will vehemently nod my agreement.

But sometimes, for organisational reasons, or because you inherited code, or you’re refactoring code from before you saw the light, you’re working with CSS that generates icons. This new property at least allows an author to make that content more accessible.

Years ago, I joined a web team a week after their brand new website had been delivered, months late and squillions over budget, by Big London Agency PLC. The site was a vile splodge of nested layout table cells and spacer GIFs with “click here” links pointing to PDFs. Of course, I could have instantly resigned my job and let the bank repossess my house.

Instead, I gently pointed out to any who would listen the inadequacies of the site and made plans about how it could be refactored. But while biding my time, I was also making small tweaks here and there to make it better and incrementally more accessible; removing duplicate link text from title attributes, changing “click here”s, putting blank alt text on spacer GIFs in the small parts of the template I controlled.

This was before the days of ARIA but I would have jumped at the chance of adding role="button" to the horrible mess of nested <div>s that the CMS spat out. Yes, it’s much better to spend a fortune getting the external CMS provider in to change the templates, the retest every single form on every single browser – but that simply wasn’t possible.

Two years later, when the senior manager who commissioned the terrible site left and we could jettison it, we did. And then we did it right. But for those who needed the content and were unable to wait nearly three years (that is, everyone), I’m glad I applied sticking plasters and polished turds.

It’s often said that if a job’s worth doing, it’s worth doing well. But it’s also wise to remember: sometimes, if a job’s worth doing, it’s worth doing badly than not at all. If you must have meaningful content generated by CSS, at least now you can make it accessible.