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?

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.

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’s comic features the chairs of the W3C HTML WG, Sam Ruby, Maciej Stachowiak and Paul Cotton as they and the Squirrel try to deal with the dangers of a cave monster in the dark. You’ll have to take my word for it, however, unless you follow the instructions on the comic to read the transcript. In a reversal of what is the norm, my sighted readers will have to take some extra effort to experience the joke; my visually impaired readers should be able to access the transcript like normal through the longdesc attribute on the comic.

Recently, these three personages made a Working Group decision about the fate of the longdesc attribute which you can read over here. The summary is this: the longdesc attribute, which is a method of serving detailed alternate text for complex images to visually impaired web users, is now obsolete and not a part of HTML5.

So much for backwards compatibility.

Almost a full year ago I addressed the issue of blind web users, encountering the topic on a personal level when I found that my commentary CAPTCHA at the time was challenging for a reader of mine because he was blind. A reader, at a web comic, who couldn’t even see the comics that my commentary accompany. I made a change to the site, setting up transcripts for every comic starting with that one, which can be accessed via either the longdesc attribute or an aria-describedby attribute, both attached to the comic’s image. I’ve been uneven at times in keeping the transcripts synchronized, but every comic since then has that alternate text so you don’t need operational eyes to be in on the joke.

I’m a bit confused to why it’s an issue for non-experts in the accessibility field to constantly be pushing against the presence of accessibility features that pre-exist HTML5 like longdesc. The most common arguments are that it’s largely unused. I know this is true. But that doesn’t seem like a reason to throw validator warnings for those sites that correctly use it for their users (like myself.)

Here’s the validator results for my comic page in HTML5 mode. Mind you, the page isn’t HTML5 yet (I’m really behind on a site redesign), but the one warning that shouldn’t be present is the last one: “The longdesc attribute on the img element is obsolete. Use a regular a element to link to the description.”

Excuse me?

Since when does a validator need to tell me how to design my site? The premise of a link on an a element is plausible (I’ve heard it a million times by now), but it seems to disregard the consequences for sighted users in some design experiences. In the case of the current comic page, I could wrap the comic in a link to the transcript, I suppose. That won’t work in the future design of the page due to interactions that I’ll be adding, however. Furthermore, for many sites, complicated images often have other functionality attached to a link around the image, like loading a larger version of the image or popping open a lightbox gallery. The only alternative at that point is add a separate link by putting an additional element on the page, aka, modify the design based on validation needs.

The fact is, most sighted users don’t want to click on an image description for alt text, because they can see the image. And non-sighted users have access to the accessibility features like longdesc. If a web developer is going to be providing alternative text for complex imagery to the point that he or she would actually create a description hyperlink, why wouldn’t this same person go an extra three inches and just use the longdesc attribute? The premise that a simple hyperlink is somehow more likely to be used is false: lazy people will be lazy no matter what.

I don’t expect this decision to somehow change. Not because I think it shouldn’t. I think it’s an incredibly stupid choice made to please punditry who largely don’t use any sort of alternate text for their sites whatsoever. I just think the issue’s been fought over for so long that those in the position to have the final say will gladly sit on the wrong decision just to move forward.

As a website owner who does make use of accessibility features for my actual blind users, I’ll take my validation error. The code was valid, it does work, and I don’t see any reason to clutter the visual design to implement a less elegant solution.

When the editor of a specification becomes openly hostile about the specification he is writing, and openly disrespectful to the duly appointed chairs of that effort, then it is time to replace that editor. This seems as rational to me as a star soccer (football for the rest of the world) player getting nasty about his team and coach.

Referencing soccer during the World Cup, see? I’m so topical.

There is no soccer occurring in today’s comic, which pokes fun at Ian Hickson, editor-for-life of HTML. It also features Miro Keller, the winner of my AEA: Seattle/Dribbble guest comic contest. There’s a washing machine and unicorn in there too. Thanks Miro, for being so patient about appearing in the comic.

The pink unicorn is an example of an imaginary solution to the issue of empty alt attributes inside image tags, one which is as equally valid as the image analysis heuristics suggested by Mr. Hickson for helping blind people understand images. See Matthew May’s related bug report on this actual situation. I’m sure if the unicorn seems too girly to you, we could use tea leaves and chicken bones.

I’d give Ian points for actually seeming to care about the visually impaired for a change, but an imaginary solution being championed seems like a really poor way to address the challenges they face. I suppose it’s arguably a step-up from claiming that table summary attributes are harmful to sighted users and that authors are incapable of writing descriptions that would be usable.

Yes, he says authors are incapable of writing useful table summaries that are non-harmful to sighted users. But, thankfully, the unicorns… I mean the image analysis heuristics will be safe and far more effective.

Competence regarding accessibility challenges isn’t something Ian needs, however. Arguably, what he really needs is the ability to accept advice on such a topic from people in the know… which ties into the issue I started this whole parade with:

I used to behave the way Ian Hickson does when it comes to dealing with responsibility, power, and making use of those when dealing with other people.

Then I turned ten.

Is that statement too caustic and pointed to belong in a standards debate? My apologies. I was just following Ian’s lead. He accuses Sam Ruby of weak leadership as the HTML chair “you just do what the more vocal members of this group want regardless of the technical arguments,” proceeds to insult either the entire workgroup or Sam again (I’m unsure of the exact recipient of “you” here) “from a technical point of view, your decisions are all arbitrary.” and “The WHATWG draft continues to exist because it’s the only way to have a specification that actually makes sense in the face of the ridiculous decisions you keep making.” and contrasts the two versions of the spec in a fashion that is more than slightly disrespectful to the W3C’s version “Easier to just add the reference in just the W3C version and keep the WHATWG version sane.”

Folks, this is all in a single email.

I’m a web developer who makes a comic poking fun at our industry in my spare time. Ian Hickson is the sole editor of the HTML5 spec, for both the WHATWG and the W3C. As discussed ad nauseum, he is (as characterized by even those not critical of him) the Leviathan, a sort of dictator/tyrant.

If Ian Hickson wants to snap at me, so be it. I’m poking fun at him with a stick as often as I can. But if as editor he cannot speak respectfully to the chairs of the HTML WG even when they’re attempting to be civil to him, then something is wrong. If he’s openly disrespectful to the very specification that he is responsible for authoring, then we’ve got an even bigger problem.

The fiction that the HTML5 spec isn’t split is just that, a fiction. The people empowered to run this process for us have a responsibility that outweighs the responsibilities of your average web monkey. Some would say this is how specifications were always written. Perhaps so. But this specification is far more public, and far more exposed to the “authors” that need to buy into using HTML5. I know for a fact from personal conversations that many of these authors aren’t buying in explicitly because of behavior like Ian’s creating the real confusion as to which specification matters (W3C vs WHAT WG) and whether the specification will survive this rancorous process.

If the editor of HTML5 can’t even be bothered to be civil about what he’s writing without a knock-down brawl every time there’s something added or subtracted that goes against his opinion, then he needs to stop being the editor. Period.

Do I file a bug for that?