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.

As I first discussed here, and then officially announced here, I’ve been upgrading CSSquirrel with accessibility features to help make this site more accessible for the vision-impaired. I first considered the idea several months back, when John Foliot approached me with a code sample that I could use to give the comic an alternative long description for screen readers. I’ll admit that I didn’t act on it at the time, though, because it seemed like a low priority. How many blind people read comics?

I realized the mistake in my complacency when I received my first blog comment from a blind user here, where he was testing his ability to post despite the CAPTCHA that was present. At that point I realized that if even one person was visiting my site and incapable of at least knowing what was happening in the comic, they were getting a severely degraded experience, which was a disservice on my part.

My growing awareness of how frustrating such a thing would be is borne out in my Squirrel in the Dark post. As a result of this, I went about adding an aria-describedby attribute to my comic’s image tag. Later, based on feedback from a JAWS-10 user and with another suggestion by John, I doubled up with the addition of the longdesc attribute to the image. In both cases, the value for the attributes is an URL for a separate transcript page.

Thinking all was well, I congratulated myself and went back to poking fun at the HTML5 process and spent a lot of time drawing people in spandex.

Of course, it wasn’t that easy.

First, a new accessibility problem had reared its ugly head. When I built the site’s CAPTCHA, I had actually taken vision-impaired users into consideration and provided description text of each image to allow them to select the proper one for the CAPTCHA (mind you, not including the word that the CAPTCHA asked you to match with the image). However, when someone tabbed through the page’s links and fields, the tabbed indexing would go out of order, going through the other input fields for the comments at a different time than the CAPTCHA itself, making the whole affair confusing.

Secondly, I learned that the aria-describedby element isn’t meant to direct to other pages (which I think is a bit silly of a limitation, but I’m not an expert at these things), but rather should contain the ID of an element on the page containing a description. It’s quite a difference, and one I’ll admit I made by failing completely to do enough homework on the matter in advance.

I’d thank Henri Sivonen for his “bug report” on the aria-describedby issue, but he chose to use the issue to draw a comparison to the Super Friends‘ list of concerns (and its initial posting to a blog instead of the WHATWG mailing list) and neglected to mention it to me directly. So instead I’ll thank Laura Carlson for drawing my attention to my error, Arve Bersvendsen for sharing his opinions on alternate techniques, and Steven Faulkner for suggesting a way to use aria-describedby to link validly to off-page content. I know others contacted me about the error, but I’m sorry to say I don’t remember all the names at the moment.

My solution, therefore, was what Steven suggested in the W3C mailing list. The aria-describedby attribute on the image tag now has a value that is the ID of an anchor on the page. That anchor then links to the comic’s transcript page. The anchor is hidden by CSS to avoid distracting sighted users. You can examine a recent comic, like this one on the Super Friends, to see it in effect (if you’re on a normal browser you won’t notice much unless you view the page source).

The CAPTCHA’s messed up tabbing issue turned out to be an easy fix as well. Stéphane Deschamps pointed out in a comment that there was tabindexes on the form’s fields, which was causing the tab order to go screwy. I didn’t know these existed, having failed to examine the blog software’s default fields very much. Now that he’s pointed it out, I’ve taken them off, hopefully making the CAPTCHA less burdensome.

As I’ve stated in the past, I’m a non-expert at pretty much everything that doesn’t involve vector squirrels. However, I have an appetite for absorbing as many web-related skills as possible to help better the web through direct effort or comic-related advocacy. One of these areas of the web that I realize that I need a great deal more knowledge about is accessibility, and it’s a deficit that I seem to share with almost every designer or developer I meet.

Having admitted my deficiency, I’d like feedback on this issue, if you have it. Does the updated aria-describedby technique for serving the transcript actually use the attribute properly? Is the CAPTCHA usable by vision-impaired visitors with approximately the same level of annoyance all people feel when they use a CAPTCHA? Is there another feature on the site that causes accessibility issues that I haven’t mentioned or considered?

To those who contact me with these problems, thank you. I’m in your debt.

In one of his recent lengthy, marathonesque comments in other people’s blog posts, John Allsopp said the following quote in response to Bruce Lawson’s post HTML is a mess: “I guess one of the reasons folks are resorting to raising their legitimate concerns in public fora, rather than directly with the HTML WG (or should that be the WhatWG, or maybe both?) is possible they don’t have a tonne of faith in the process.”

This comment by John sent me down several interesting paths of consideration. Firstly, it made me think that Mr. Allsopp might spend more time writing in other people’s blogs than his own, much like Jeff Croft (who I had the fortune to see at Refresh Bellingham last week) appears to spend more time in every other city in America than the one in which he lives.

Secondly, I briefly thought that I’d start spelling “ton” (American spelling) like “tonne” (which appears to be the Australian, and I’ll bet also the UK spelling). I quickly discarded that plan, since it’d just limit my word count in Twitter. Which made me wonder, do Japanese users of Twitter get to use kanji in their tweets? If so, that seems highly unfair. They could fit a War & Peace sized comment in a single tweet that way. (Note to self: learn Japanese.)

Finally I really got to the meat of what he said in that sentence (one of many that expressed his thoughts on the mess topic Bruce had posted about). Why should you or I bother with figuring out how the hell to send an email to the proper mailing lists for the HTML5 WG? Or the WHAT WG? Heck, I’m not even sure which group is more relevant. The former has more technical authority, but the latter is actually making all the calls. RDFa, ARIA, and other fruits of the loins of other W3C chartered working groups are being disregarded by the HTML5 people consistently, or being carefully argued away with a pleading for use cases, a suggestion that their expertise is flawed, or that alternate solutions (read that: the WHAT WG’s solutions) are the better option.

People who’ve spent decades in service to their fields are being shot down by non-experts. Consider the issues with accessibility. Laura Carlson recently sent a proposal (signed by a lot of notables including accessibility guru John Foliot and HTML5 doctor in residence Bruce Lawson) that suggested the audacious idea that there be a formal procedure that describes how HTML5 will seek accessibility guidance from the W3C WAI groups.

HTML5 editor-for-life Ian Hickson evaded the issue by listing all the unanswered questions he has waiting on such topics instead of addressing the proposal. Sam Ruby one-upped Ian by expressing his disappointment that the proposal even existed.

In a situation like this, where motivated, caring experts in their fields are being ignored or deflected when using the official channels, why should your average John Everyweb even consider unraveling the process involved enough to attempt to address concerns, knowing the almost certain result of such efforts?

I can’t think of any motivating reasons.

Today’s comic features John Foliot (representing accessibility efforts) submitting such a suggestion to the HTML5 group(s), with my squirrel alter ego looking on in horror at the results. Consider it a softened metaphor that reflects my own growing dismay at the direction HTML5 seems to be heading when working with others.