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.

In a perfect world, Ethan Marcotte would star opposite of me in a web design-themed, buddy cop action comedy called Beep and the Squirrel.

Actually… I’m writing that one down, just in case.

Until that glorious moment, I’ll enjoy his raw intellect and seasoned wit while envying his creative talent in a suitably stalker-like fashion. (Unless you’re reading this, Ethan, in which case I assure you that I am in no way digging through your refuse bins looking for cast-off brilliant ideas and toothbrushes.)

While we’re in the vein of borderline creepy idol worship, I’m going to agree with Ethan’s succinct tweet on the W3C’s CSS Conditional Rules Module Level 3 Working Draft (which I’ll reduce to the much easier to remember abbreviation “CCR Module”, hereafter nicknamed the “More Cowbell” document). I feel cold.

I’m still perusing the document. Although any judgement leveled while shooting from the hips (hello, ladies) is bound to be rife with bad summaries and skewed views, in my opinion the module doesn’t seem to solve any problems that aren’t already being solved in a better fashion by good CSS practice or other techniques. It’s a lazy man’s shortcut to “supportin’ olla them thar browsers”.

As Dylan Wilbanks said, these aren’t the conditionals I’m looking for.

Just look at @supports, for the love of cheese (or dairy-free cheese alternative for vegans and the lactose intolerant). It lets you test if a browser supports a feature, before (in their examples) you then go and use the feature. What? How bizarre is that? I know in their examples you can get far trickier with not and or and doogie howser, but seriously?

When it comes to the problems that CSS is supposed to solve, although @supports and its ilk would work, they seem to encourage bad or unnecessarily laboriously bloated CSS documents instead of streamlining the process. And when it comes to @document I believe that the authors are trying to make CSS solve problems it wasn’t intended for.

Look, if you’re trying to get your CSS to be flexibly supported across different browsers and devices, I recommend checking out Ethan’s Responsive Web Design, or at least actually using your skullmeat instead of slapping shoddy shortcuts into your CSS. Capiche?

In the past I’ve made it fairly clear that I disagree with a lot of the decisions that HTML5 editor Ian Hickson has made in the past, such as the movement of the WHATWG version of HTML5 into Last Call (well before the W3C has done so, creating an oddball situation where arguably the spec exists in two different states). I felt that he was making a decision to move the spec forward to meet an arbitrary timetable, and not because it was mature enough to deserve that state.

Now that the WHATWG has gone onto its version-free HTML Utopia, leaving the W3C to make sure there’s a benchmark for browser vendors to compare against with what us mere mortals are still calling HTML5, I had hoped that at the very minimum we could rely on a standard that would properly address all the issues before declaring itself an adult.

I was wrong.

Accessibility is an issue that gets me worked up at times. While observing the various battles in the mailing lists of the W3C, it becomes clear that often those most aware of good practices for accessibility are given the least amount of attention by decision makers. Right now we’re witnessing the W3C’s chairs pushing for HTML5 to move to Last Call while ignoring a massive lump of requested data about an accessibility issue.

AKA: They’re moving the spec forward without addressing existing, outstanding issues.

Today’s comic highlights my opinions on that.

It seems that as a result we’re going to end up with a standard that will only address best practice for accessibility as some sort of later patch. This is a load of crap.

For some reason, several smart people think the longdesc attribute is hard to use. So hard to use that we’d best not even bother keeping it in HTML5 as a means to provide alternate text for images to sight-challenged web users.

I’m going to tell you how to do it in a detailed fashion, and you can decide if it’s hard: 1. Put a longdesc attribute on your image with a value that points to a url of a page with a detailed description of the image. 2. At that destination, write the description.

Pretty hard stuff, right? I don’t know if you can remember all that.

This culminated last August as Issue 30, where the working group chairs decided to leave longdesc out due to a lack of data, and they encouraged people to feel free to get more data and approach them again.

In fact, I quote:

This issue can be reopened if new information come up. Examples of possible relevant new information include: use cases that specifically require longdesc, evidence that correct usage is growing rapidly and that that growth is expected to continue, or widespread interoperable implementation.

Laura Carlson took them at their word, creating a research document with over 150 examples harvested from the “wild” and compiled into several use cases, along with relevant local laws and policies from governmental and corporate entities using the attribute.

Armed with a treasure trove of the requested data, she asked the chairs to re-0pen the issue to consider it before Last Call.

Sam Ruby, W3C HTML5 Co-Chair, says “Thanks for all the data. I know I asked for it. But no. Focus on other important stuff instead. Ha ha.” (That might be a bit flavored of a paraphrasing…)

I couldn’t help but read into that an unspoken “Addressing the needs of blind people should take a back seat to getting the spec out the door.”

Class act, guys.

Today the W3C unveiled its new logo for HTML5. As you might notice, it’s quite fancy.

The site’s pretty slick, as well.

Today’s comic relates to this new logo, in a roundabout way, featuring Jeremy Keith, Bruce Lawson (or perhaps it’s Super Bruce) and Remy Sharp (Or is it SuperHTML5Rem?) in their guises as HTML5 Super Friends, attempting to save the web from itself. It also refers to a slippery terminology slope.

The FAQ page for the new logo (yes, it gets its own FAQ) includes a little mention about what the logo represents. Which is obvious: HTML5, right? Well, apparently HTML5 doesn’t stand for Hyper Text Markup Language anymore. But apparently its all for “a broad set of open web technologies, including HTML5, CSS, SVG, WOFF, and others.”

Say what? I’m with Jeremy and Bruce on this one. The logo is pretty, but the intentional use of HTML5 as a blanket term for other modern web technologies is a crock. Newspapers making merry with the term is one thing, but a web standards organization? We rely on these groups to keep our handy developer toys in nice, cleanly demarcated buckets so that we can easily educate ourselves and the next generation of developers on what toy is used for what job and how.

I could rant on this for hours. But I recommend reading at minimum Jeremy’s bit on the topic. He manages to be far more eloquent with his words and has earned his place as a bit of an authority on the topic. So maybe you’ll value his two cents more highly. All I know is that when I used to say “HTML5″ people knew what I meant. At least in my own community of website creators. But now it’s as meaningless as “doohicky.” As in, “Are you talking about the doohicky that I style pages with or the doohicky that I make the structure with?”

TL;DR Version: Love the logo, hate the term-squishing.

As a parting shot, I object to Karl Dubost’s characterization of term-blurring opponents’ commentary as “vapid“. I’m sure Jeremy Keith is capable of a lot of things when writing, but even if you disagree with his viewpoint on the topic, his well reasoned rhetoric doesn’t merit such a label. Shame on you, Karl.