John Foliot reprises the role of the Scarecrow and Matt May takes a turn in the role of the Wizard in today’s Ozian look at the HTML5 Issue of the Week, and represents the frustration I’m sure accessibility experts face every damn day when trying to deal with the nonsense that is getting people to adopt proper accessibility support in the web.

Today we’re looking at ARIA’s role (no pun intended) in HTML5. More accurately, whether ARIA would have a role in HTML5. Now, typically my posts about idiocy involving HTML specs tend to involve Hixie and the WHATWG. This time, sadly, I’m discussing the W3C, and specifically actions of the co-chairs of their HTML WG.

And here I thought we were besties.

I’ll recap:

For entirely too long now the W3C has been debating whether or not to include the longdesc attribute in HTML5. This debate, which has been pretty rancorous since at least 2008 (jinkies!) is known as Issue-30. Longdesc is an attribute that you can attach to an image tag to inform capable devices of looking to a specific URL for a longer description of the image for the visually impaired. We’re not talking about a simple alt tag of “girl under tree” for every college campus in the world. We’re talking about a genuine effort to impart the information about an image to a viewer who can’t properly see the image, if at all.

Here at CSSquirrel I use the longdesc attribute to link to the transcripts for the comics.

To me, this is a big deal. I have blind readers, many of which want to enjoy the comic that the sighted readers can see. I’ve received numerous requests in the past to put transcripts up, so I’ve built the site to serve that need. Is it a sizable percentage of my readership? No. Does that matter? No! If we’re letting lazy implementation of available solutions get in the way of us helping one visitor with accessibility needs, then what does that say about us as people?

During a standoff between the W3C groups responsible for HTML and ARIA, Sam Ruby (Co-Chair of the HTML WG) suggested that the entirety of ARIA be removed from the HTML5 spec until sometime in the future when Issue-30 could be amicably resolved. This is absurd! It’s like throwing the baby out with the bathwater!

There is a lot of ARIA that is seeing author implementation in HTML right now, most notably ARIA roles. Their inclusion provide real assistance for visitors with accessibility issues in navigating and understanding the content of a website, and in some cases provide extra helpers for non-human agents to crawl the content as well. (I’ve even used them as clever hooks for tricky bits of CSS).

A debate ensued.

Well, re-ensued.

At one point, John Foliot dropped in with a detailed examination of statements being made by the HTML Co-Chairs about the situation, correcting falsehoods and reinforcing how important this issue is. This is a man who’s spent years as an accessibility expert watching bureaucratic process and non-expert interference getting in the way of providing solutions to genuine accessibility needs. He gets direct and to the point, as time and again it’s been proven over and over that anything short of that will fail to sink in.

Their detailed response to the situation thus far?

A slap on John’s wrist for his tone.

It’s been a few days since, and that’s as far as it has gone.

I’m sorry blind folks. The bad man’s mean tendency to call them out when they’re being bureaucratically false while defending their indefensible suggestion of removing major accessibility support from HTML5 is more important than your ability to use the 21st century’s most important communication medium.

But that’s OK, I’m sure your seeing-eye dog can navigate websites for you, right?

Steve Faulkner recently tweeted the following to me on the topic (good man, fights hard, really should be put in one of my comics ASAP): “I think the suggestion to move ARIA out of HTML5 was misguided tactic of the chairs to force progress on an issue. - won’t happen“

I appreciate that Issue-30, which has gone unresolved for years, is annoying. But threatening to pull out the entirety of ARIA from HTML5 in some sort of chicken head-on-collision maneuver is a new low in the entire HTML5 spec authoring process.

And that is saying a lot.

Are you an accessibility expert or a web developer that uses ARIA? Are you a person with an opinion about longdesc or ARIA roles? What do you think of this whole mess? What suggestions do you have for the W3C to get this mess fixed? Did I get something wrong? Please help educate me by responding via one of the methods below?

Today’s comic features Mat “Wilto” Marquis (Internet folk hero) in a nightmarish world that I imagine Ian Hickson envisions if HTML were ever allowed to slip from his hands and be created by the common man.

We’ve discussed the issue of responsive images in HTML and the proposed <picture> element before, you and I. Here’s a look back in case you need a refresher. It’s a bit cheeky. I get worked up over things like one smart person thinking his brain is more efficient than the combined powers of dozens of smart people.

<Picture> has had a rough road.

All the way back in December 2011, Bruce Lawson posted this idea for how the syntax of <picture> might work. Several people started a community group chaired by Mat Marquis back in February (based on a WHATWG email suggesting such) to push the idea forward so it could see eventual adoption into the HTML spec. They did a great deal of good work to make a workable, problem-solving piece of markup. Scott Jehl even created a polyfill script to provide support for the proposed markup until browsers implemented it, which you can find here.

Then Hixie stepped in. It’s been well documented in the past before, so I’ll summarize: he decided to ignore the community group and efforts of the developer community and went with srcset. Classic Hixie solo action. Here’s an aptly named summary, WTFWG by Tim Kadlec, and a piece on A List Apart by Mat Marquis.

Developers were mad. Developers were vocal. Then for the most part, the web moved on.

If it wasn’t for the continued effort over the past several months of people like Mat, that would have been that. But he and others didn’t stop, and they kept on pushing, and wouldn’t you know it? Something came of it.

Not in the WHATWG, of course. Someone hoping for that sort of miracle would be essentially signaling to everyone that they finally lost their last marble. (Here’s an example of how things were going over there, AKA, Hixie’s got his blinders on like normal.)

But over at the W3C, Mat and his allies accomplished this: an official w3C Editor’s Draft of a proposal for HTML Responsive Images Extension, featuring both srcset AND <picture> to be included into the HTML5 spec. It’s just a step, but it’s a fairly big one, and a great deal of validation for the developers that worked so hard, despite Hixie’s best attempts at ignoring them, to create a responsive image solution that works for them.

I could tell you how it’s a heroic accomplishment that is leading us towards a better web. But I won’t. Not because I think it isn’t (it in fact is!) but because Marc Drummond already said it better. Go read his article Responsive images, the picture element and the W3C: This is how you deal with Hixie and WHATWG. It’s worth it.

It’s hard to say if <picture> will ever make it into the browsers. The browser makers are mostly (but not entirely) involved in WHATWG, and would prefer to work around the W3C. But I do believe that enough community effort will continue to build on the success that Mat and the others have brought us.

I asked Mat about what he saw as the future of <picture> in light of these recent accomplishments, and what interested developers should do to help. Here’s his response.

I totally stand by that follow-up tweet I posted earlier ( http://twitter.com/wilto/statuses/240486846801514498 ): no matter how things play out from here, the dev community has done something that I don’t believe has ever been done before. You just don’t see specs - proposed or otherwise - with a developer’s name at the top. If nothing else I hope this marks the beginning of that, and that it leads to we authors having a voice in web standards equaling that of the vendors.

To get involved, more folks should join up with the RICG! http://www.w3.org/community/account/request

Let’s not waste the opportunity this has given us. We’re the developers that will have to work with the spec that’s being created, and will be answerable to the clients and site visitors that will use the sites we create. We should and can have a bigger voice in the direction of HTML. What Mat and others have done is show us how.

It’s been a few days since I wrote my post (and comic) entitled The Value of Meaning, wherein I registered my objection to Divya Manian’s article about HTML5 semantics called Our Pointless Pursuit of Semantic Value. In that time there’s been a great deal of continuing discussion on the topic from a lot of intelligent people that’s worth pointing out in case you missed it.

• Firstly, there was a great comment thread on my post including voices such as Divya’s. Check it out.
• In particular, you should read John Foliot’s response at the end.
• Jeremy Keith’s Pursuing Semantic Value is a must-read. In it he agrees with Divya’s core message, notes an issue with tone, and guides you through the process of where his agreement with that core message takes him to a very different conclusion.
• Steve Faulkner replies to Jeremy’s article with a comment that grows up to being a full-sized article of its own: HTML5 Semantics and Accessibility.
• Paul Irish, a veritable Chuck Norris of web development, also wrote in response to Jeremy Keith with Semantics in practice and mapping semantic value to its consumers.
• John Foliot responds to Divya in a detailed, no-holds barred post that examines the merit (or lack thereof) of her speaking points about semantics in My Thing About the Thing That Thing Wrote About Thing.

If you have time, you should read all of these. They’re all written by intelligent people getting into the heart of the HTML5 semantics debate with more clarity and detail than I could ever manage.

Divya Manian is a bright cookie. When it comes to the web, you can say with complete assurance that she knows her s***. She’s in that category of people that makes me insanely jealous of their creativity and intelligence.

All of which makes me think that somehow she’s trolling us today.

Our Pointless Pursuit of Semantic Value is a shortsighted piece, placing the value of markup solely upon the capabilities of browsers (and other user agents) today at the expense of tomorrow. It’s the sort of article that I would have perhaps expected from the internal website developer of a large corporation at the turn of the century that only permitted its employees to use Internet Explorer 6.

When I started getting paid to make websites instead of pizza, I was bombarded non-stop by the value of making websites that weren’t locked into the limits of the less-capable browsers of the moment (some of which, like the big blue e, were more than a little antiquated), but was instead encouraged to embrace forward-looking mentality of making the best of emerging features where I could and creating a fallback position where necessary. I can’t remember if we called this graceful degradation or progressive enhancement (I’ve heard the two used and misused so much that they blur in my brain), but nowadays we just call this technique “common sense”.

Did I make special span tags on elements that had rounded corners, placing background graphics on four separate corners so that the Great Blue Mentally Misunderstood Beast of the Internet could have pretty edges? Hell, no! I used border-radius and knew that somehow, someday, all browsers would eventually understand it meant I wanted pretty, round corners to nuzzle up against and whisper sweet nothings to at night.

I’m aware that HTML isn’t CSS, and what applies to one doesn’t necessarily apply to the other. But I’m fairly convinced that if anything, the principle applies even more with HTML today than it did with CSS yesterday. Barring a few legacy browsers that need to ride the HTML5 Shiv/Shim Short Bus, using a div or a header isn’t going to have any impact on a browser’s ability to properly render an element. Which means there’s no harm being done by using a semantic element before user agents get around to taking advantage of its extra meaning.

If I had to summarize Divya’s points in her article (I recommend you read it rather than relying on what’s bound to be a dramatic oversimplification on my part), it is that we shouldn’t bother with semantics because:

1. Semantics Are Hard
2. Current Browsers, Search Engines and Assistive Technology Don’t Understand It, So Don’t Bother
3. Spending As Little as 40 Minutes To Learn About HTML5 Markup Is A Waste Of Time

Semantics Are Hard

Divya points out a piece by Mark Pilgrim on the difficulty of semantics. So, Semantics is hard. So what? Last I checked, I was a professional doing a job for a living. It’s my job to know what part of a website is its navigation or is its primary content. HTML5 isn’t really demanding much brainpower from me on deciding what element to use for what job. I’m fairly confident that the general meanings of header, footer, nav, time, audio, video, progress and summary elements are easy enough to grasp as a person who works with websites for a living. Agreed, article and section are a bit confusing, but I don’t think by and large that HTML5 semantics are a byzantine labyrinth of alien thought impressions that cannibalize the minds of sane men.

Current Browsers, Search Engines and Assistive Technology Don’t Understand It, So Don’t Bother

When I was making a few years back, Internet Explorer didn’t understand border-radius. Yet, despite that, I used it in making websites. And not only does IE now understand (and render) those pretty corners, but many of those websites still exist, using the same code I wrote back then. If I had chosen to not use border-radius because of the limitations of the time, the sites wouldn’t look good today because of my short-sightedness.

HTML5 is still settling down into its patterns. Some of the meanings are still being locked in. It’s not “done”, as evidenced by Hixie’s arbitrary and somewhat bizzare attempt to remove the time element from the spec. Does this mean that I shouldn’t be using elements from the specification because it’s not done now? Of course not! The sites I’m making today will not only be live for years, they very likely won’t see a redesign for much of that lifetime. Relying only on what’s “finished” now would be a disservice to my clients today, preventing them from benefiting from features for years because of a technicality on the spec’s status or the full support level of browsers.

AT, browsers, search engines, they will all catch up with taking meaning from semantics at some point in the future. When they do, would you rather that your website was ready for them, or would you like to spend time (and money) re-coding your mess of divs into something slightly more relevant? There is no harm in using divs now (when other, more semantic elements might be better). But there is a very good chance that it will put your site at a disadvantage later, when the technology catches up.

Saying that I shouldn’t use semantic markup because AT, browsers or search engines aren’t consistently taking advantage of it in the present is like saying that I shouldn’t use video or audio elements because some browsers aren’t taking full advantage of them yet. It’s limiting my future benefits by over-adhering to the present. How many of Divya’s CSS tricks shown at her presentations at conferences work on all current browsers? In all likelihood, none of them. Does that mean they don’t have value, and shouldn’t be used?

How is making use of semantic markup any different?

It’s not.

Spending As Little as 40 Minutes To Learn About HTML5 Markup Is A Waste Of Time

I am shocked that she said this. I’d almost characterize it as insulting. We are professionals in a career that demands continuing education.

At the end of the very same post, Divya suggests that developers learn Javascript. Which is good advice. Learn it. Love it. But how can you advocate the value of self-education while simultaneously characterizing spending forty minutes of your time to familarize yourself with the meaning of some of HTML5′s elements as a waste of time?

Sometimes the choices we make in markup don’t result in manna from heaven. Personally, I don’t attempt to adhere to sensible, semantic markup for the sake of SEO (which I consider a bunch of snake oil bulls*** anyhow) or for accessibility purposes. I do it because there’s an inherent value in attempting to do something in a consistent and correct fashion. There is meaning and purpose in constantly attempting to improve one’s level of craftsmanship.

There is nothing pointless in pursuing good standards, including adding semantic value to your website. Even if there was no future benefit to properly, professionally crafted markup (and there will be), there’s an inherent value in taking pride in your work and producing a product that is more elegant than that of your hurried, slapdash competitor.

There is meaning in striving for meaning.

Or as Karl commented in Divya’s post:

inadf, rjfsnsl nx pjd yt zsijwxyfsi jfhm tymjw. ny’x ymj xthnfq htsywfhy ns gjybjjs tzw nijfx. dtz fwj rncnsl uwthjxxnsl fsi rjfsnsl. vznyj xfi.

Edit: Roughly twenty minutes after I posted this, the W3C took action on the issue, insisting that the <time> element be placed back into the specification. You can read about it here. But please read on. It’s a good primer for the next time something like this happens.

Contrary to what you may have already heard, the <time> element hasn’t disappeared from HTML.

Yes, officially <time> is currently not part of the HTML spec. (Thanks to the muddle that is “HTML Living Specification” I’ll be honest and admit I’m not sure if is no longer part of HTML5 or it’s in some sort of Schrodinger’s Cat quantum-zombie state of existing in HTML5 but missing in the “ongoing HTML” that the WHATWG is proud to keep rolling down the conveyor belt.)

That doesn’t mean it’s not being used by authors (how’s Drupal builds, 2.6 million WordPress installs and the Boston Globe for you?) nor does it mean that is it not being used by user agents (ever-plucky Opera supports it).

What it means is that a single human being has decided that he doesn’t care for time one wit, and that a rather vague element called <data> can replace it instead.

This human is none other than Ian “The Benign Leviathan Dictator For Life” Hixie, editor for the HTML specification.

I could give you an explanation on how this scenario came to exist, but two Brits who are far more informed than I am (and likely slightly smarter) have made their own summaries. If you like knowing what’s going on (and I do) then go read them. These pair of fine gentlemen, Jeremy Keith and Bruce Lawson, both guest star in today’s comic as the good Doctor thanks to a little spot of regeneration, where they’re fighting the good fight against Hixie’s <data>leks.

Virtually every problem I have with a single person wielding so much power over such a fundamentally important pillar of the web as HTML can be summed up in this incident. <Time> is officially out, despite the lack of merit or consensus in that decision. And it took just one man to make that happen. Either through a lack of awareness or a genuine disregard for what authors are already doing, Ian has claimed incorrectly that <time> isn’t seeing adoption, isn’t useful, and should be canned. And because the only balance to his power is a rather tedious process to oust him, there’s no official remedy to bringing <time> back into the HTML fold than trying to convince him that its existence is a good thing.

From what I understand, it’s easier to keep red shirts alive on away missions than it is to change Ian’s opinion on something.

Fortunately, there’s a big difference between having no official remedy and having no remedy whatsoever.

As “authors”, we are the 99% of HTML5. We can follow Jeremy Keith’s sage advice:

We can make a stand and simply carry on using the time element in our web pages. If we do, then we’ll see more parsers and browsers implementing support for the time element. The fact that our documentation has been ripped away makes this trickier but it’s such a demonstrably useful addition to HTML that we cannot afford to throw it away based on the faulty logic of one person.

So as I said, <time> hasn’t disappeared from HTML. It’s still there on millions of sites already. And nothing is stopping us from putting it on millions more. It’s our chance to send those <data>leks packing. As soon as this post is finished I’m going to edit my site’s theme to make use of <time>. Hixie can go stuff it.

Occupy HTML5.