bestkungfu weblog

Alt text matters to users. When an image is not visible, due either to a user’s own visual or cognitive disability, or their use of a low-bandwidth or intermittent connection to the web, @alt is there to provide the necessary, missing semantics. This is a good thing. So good, in fact, that @alt is a required attribute in HTML 4.01 and all flavors of XHTML. If you omit alt text, your code is not valid HTML.

However, as of today, alt is not a required attribute for the img element in HTML5. Despite claims that this is neutral or even beneficial to accessibility, this is a bad idea, made worse by adversarial relations between participants in the HTML Working Group and accessibility advocates, including those in the W3C/WAI Protocols and Formats Working Group, of which I am a participant.

Much of the discussion around this rather tense standoff has centered around what I call the Flickr Defense. It goes like this:

Sites like Flickr depend on user-generated content in the form of uploaded images. (Of course Flickr now accepts video, something that has also been added to HTML5, and which may have even bigger problems than the issue at hand. But that’s for another time.) Flickr doesn’t know what to communicate as meaningful alt text. But if we want them to adopt HTML5, they wouldn’t be able to create valid documents without that @alt. So in this very limited case, Flickr should be able to have an img element without @alt.

This argument is bogus on numerous counts.

First, let’s dispense with the very limited case for making @alt optional. Once an attribute like @alt is optional anywhere, it’s optional everywhere. One could make the argument that the specification limits the scope of acceptable use of missing @alt to only where it’s not possible for it to be meaningful. But that’s just one image out of 65 on the average Flickr photo page. And if it’s an optional attribute, we could strip the alt text from all of those other images, and an HTML5 validator could do nothing but assert that it remains valid. That’s a huge step backward for users as well as accessibility evaluation tools, which interpret missing alt as an error. But more on that later.

Second, Flickr could, in fact, require that meaningful alt text accompany images that are uploaded. Other sites, such as Smugmug, actually do offer the ability to do that, either as they’re uploaded, or as a batch job after the fact. The Authoring Tool Accessibility Guidelines 2.0, which apply explicitly to sites like Flickr, require that such sites prompt users for that content. If they prompted for and stored that content from the user, they’d be able to insert meaningful alt text where it is required. There’s no need to give them a pass.

(Although that’s exactly what the Web Content Accessibility Guidelines 2.0 does. Flickr could make a partial conformance claim stating exactly why they can’t produce alt text. They could still insert generic alt text like “user-uploaded image” and satisfy the requirements of users with disabilities to some extent.)

Third, Flickr image pages have over 80 validity errors, and that’s just HTML 4.01 Transitional. Why should the HTML specification make supposedly narrow exceptions to the spec to be more lax about validation when the sites themselves aren’t even trying today?

How it works today

There are three conditions for alt text that are currently determinable:

• This image has meaningful alt text. (alt=”foo”)
• This image is decorative, and needs no text equivalent. (alt=”")

The third is determinable now, but would not be in HTML5 as proposed:

• The author has not entered alt text for this image. (missing @alt)

This is critical because assistive technology looks for repair data (including filename, etc.) when @alt is missing. We need to know whether @alt is null due to conscious effort, or that it has been ignored, in order to know what to do next.

The Flickr Defense is a fourth state:

• The author asserts that s/he cannot provide alt text.

It is the wrong solution to take away the semantics from the third state to indicate the fourth. There would be far more missing @alt attribs due to inattentiveness on the part of the author than conscientious statements that @alt is not possible.

The clearest indicator that this is an awful idea is that same Flickr image page. All of the images with missing alt attributes on the Flickr image page could have meaningful data. In fact, most of them do. It’s just sitting in the title attribute instead.

So what do we do, smart guy?

I don’t want to propose a solution to the problem when I think the status quo in HTML 4.01 doesn’t need to be mucked with. But, okay, you read a big long accessibility article, so here’s a thought experiment.

Add an attribute. Call it @usergenerated. When a UA encounters this attrib, it indicates that the author has stated alt cannot be provided programmatically.

It would be even better if other users could detect that attrib and annotate the attached image. If you could get around the spam potential, this could be a real winner. Crowd-sourced @alt. That’s actual accessibility progress, measurable today.

If you can’t do that much, leave @alt alone.

Gez Lemon’s analysis of the subject got me wound up enough to write about it. If you don’t like what I had to say, blame him.

(Note: This isn’t meant as a critique of Flickr per se. It just happens to be a site that’s being held up by third parties as the reason to backtrack on @alt as a required attribute.)

You know what I think should cause everyone to give at least some thought to accessibility?

Your thirties.

I remember one day, when I was 30. I threw the sheets off the bed, and shot my legs out to launch myself from the bed. I took two steps forward, saw a blinding light… and found myself lying on the floor, unable to move for several minutes. It was my first back spasm, and knocked me out of commission for a couple weeks.

Suddenly, things I took for granted, like getting up and looking in the fridge, were things I had to consider. I didn’t want to go anywhere, because it hurt to breathe, much less move. But in that time, I had to fly cross-country to tend to my grandmother in her final days, and that meant managing my pain while my back was screaming in an airplane seat, and then being wrenched as I carried all my luggage. It was the first time that my mobility was reduced, the first time I preferred elevators to taking the stairs two at a time, and the first time I had to depend on other people to help me do what I considered to be basic tasks.

It seems that since then, every six months I get a reminder that my body is not necessarily my friend. Most recently, I strained a ligament in my foot while exercising. Let me tell you, foot injuries suck. When your foot hurts, you keep hoping it doesn’t get worse. And when it doesn’t, you’re scared to do anything that might aggravate it again. So I had a very strange weekend that involved walking with a cane to keep weight off my foot.

It’s simple to look at people with a visible disability and say, I’m glad that’s not me. But you know what? Sooner or later, it will be.

Your vision will likely be the first thing to go. You may strain to read small type, at first. Then, maybe you’ll try bifocals. After that, as the effects of presbyopia set in, you’ll come to rely on your glasses to read. Your vision may start to yellow a bit, as well.

But wait! There’s more!

Hearing loss is a common side effect of the aging process. You may also encounter problems with arthritis (by the way: you’re not resting your wrists on the wrist rest while you’re typing, are you? Are you?), or any of a host of other fine or gross motor dysfunctions that will advance over time. And you may find that your cognitive abilities aren’t as sharp as they once were. (Hopefully before those around you start talking about it.)

I started doing web development when I was 20. At the time, it was barely conceivable to us that people of a certain age would be using the web. We didn’t even know if the web itself was going to last. But here it is, still chugging after a dozen and a half years, and not looking a day over 10.

And nowadays, I look around at the people I’ve worked with, and some of them are really old. Like, in their fifties! Some have even retired — the kind of retired where they’re collecting Social Security and posting pictures of their grandkids to Flickr. Get it? They’re using Flickr. And YouTube. And Gmail, and Twitter, and especially eBay. They also tend to have money to spend, and companies tend to like people like that.

And yet, I still hear people dismissing accessibility for older people on the web. That’s not going to fly any longer. Younger people are coming up on the web, that’s true. But those of us already there are only getting older, and we’re not going to stop liking the web anytime soon.

Keep this in mind when you’re about to downplay whether older users will want to use your site. The right thing to ask is:

Will you want to use this site when you’re older?

Or maybe, do you want some 20-year-old smartass deciding you won’t?

It must have been some kind of event for me to break my blogging silence.

I read about the IE 8 beta (and I’ll test it for myself as soon as I prep a fresh virtual machine…). Key features include support for the WAI-ARIA spec, and Acid2 compliance. Chris Wilson apparently also said during his talk today at Mix that they’re aiming for full support for CSS 2.1.

Okay, guys. You win. I’m impressed. There, I said it. I said something nice about Microsoft. I even did it on my Tablet PC, running Vista, just for good measure.

I was one of many who groaned at IE 7 when it caused a new round of conditional comment breakage, and when its own issues started to pinch authors into making more tweaks just to keep standards-based development working. Back then, I saw it as a small step forward for a team that had just been reassembled. I hoped for big things to come after - big, positive things - but so far, if the bits resemble the hype, let me be the first to welcome Microsoft back to the standards-based web.

There have been almost too many battles to name in the web standards arena over the last several years, and there are still some that make me itch. The <canvas> element springs to mind. But the thought of every major vendor finally supporting HTML 4.01 and CSS 2.1 has left me almost giddy, and ARIA support in all the major browsing platforms just puts me over the top. I think it can now be said that the standardistas have finally got what they wanted: a stable contract with browsers that what they code is what the user will get.

What next? Oh, I don’t know. How about we gather up everybody still designing web sites in 2008 using layout tables, font tags, and the like, and run them out of town on a rail? Who’s with me?

Sorry, Web 2.0 Expo participants, for not posting my presentation links in time for, you know, the presentation. Here they are, better late than never.

• Gez Lemon: Making Ajax work with screen readers
• James Edwards: Ajax and screenreaders: When can it work?
• Dushan Hanuska: Hijax
  
• Bruce Lawson: Ajax, Hijax and accessibility
• Jeremy Keith: Progressive Enhancement with Hijax
• Juicy Studio: Improving Ajax applications for JAWS users
• W3C: Roadmap for Accessible Rich Internet Applications (WAI-ARIA)
• Accessibility features in Firefox
• Mozilla accessibility projects
• Dojo Accessibility Strategy
• IT Business: Canadian schools collaborate on more accessible interfaces

Welcome, dear UIE Web Applications Summit participants, to my presentation links:

• Gez Lemon: Making Ajax work with screen readers
• James Edwards: Ajax and screenreaders: When can it work?
• Dushan Hanuska: Hijax
  
• Bruce Lawson: Ajax, Hijax and accessibility
• Jeremy Keith: Progressive Enhancement with Hijax
• Juicy Studio: Improving Ajax applications for JAWS users
• W3C: Roadmap for Accessible Rich Internet Applications (WAI-ARIA)
• Firefox 2 Voluntary Product Accessibility Template (VPAT)
• Mozilla accessibility slides (December 2006)
• Accessibility features in Firefox
• Mozilla accessibility projects
• Dojo Accessibility Strategy

I’ve had a problem with how my browser memorizes passwords for a while now, and I’m certainly not alone. Since the holy grail of identity management appears to be a long ways away, I think it’s time to address it.
When I enter a username and password, Firefox helpfully offers to remember it. This is good, and helpful, if you know your username and password. My problem is that I have hundreds of accounts scattered all over the place, and I can never be sure that the username and/or password I am entering is correct. If it’s not, and I tell Firefox to remember it, then I am guaranteed to be starting with the wrong credentials on subsequent visits. Only I won’t know it until I try signing in. That’s a less than stellar user experience.

The problem compounds itself on sites where the form sends you to another page in the site’s hierarchy. Then, you may store the correct username and password combination on that other page, and Firefox will remember them both. And as a result, you’ll go to log in on a site’s front page, then fail, but then be sent to that second page, which will let you in. I had to do that for years with Vonage, having forgotten that the original username and password I provided were useless.

It seems a better way to store new usernames and passwords would be to ask whether to store them after the transaction has been completed. So once you submit the form, and you know whether your credentials have been accepted, you can inform the browser to continue. If not, you can go back and try again. But in any case, you will not be saving bad credentials that will continue to come back and bite you each time you forget whether you used this password or that, or whether you’re bob or bobsmith or bobs or bobsmith@gmail.com or b0b_l0l_360 at any given site you have visited.

Am I alone in this, or does this seem like a useful feature request?

Since the National Federation of the Blind sued Target Corp. for the inaccessibility of its Web site, many people have taken sides, vilifying Target and/or lionizing NFB in turn. I think it’s too early for that, if it’s necessary at all. In terms of US law, this was a suit that needed to happen, because the case law on Web accessibility is so far pretty thin. The most important thing to take away from this news is that the same case could be brought against dozens of comparable e-commerce sites, and all over problems that stop many users dead in their tracks, and yet could be fixed without affecting their visual design or functionality.

I’m hesitant to paint Target as the solitary enemy of users with disabilities. Let’s be clear: The accessibility of Target’s site is terrible. But in a short review I did of big-box store sites this morning, they’re not the worst around. In fact, they’re pretty much the middle of the range.

Take Costco.com. Please. From an accessibility standpoint, if Target is bad, Costco is a godless abomination. Never mind the distinct lack of alt text (which, by the way, is not the alpha and omega of Web accessibility): Costco’s homepage contains over a hundred subcategories in hidden drop-down boxes. But they’re not links. Noooooo. They’re table cells, with mouse events that fire JavaScript functions to load the relevant pages. Nice. The Costco site is not only inaccessible, its code is so poorly designed that its bloated size alone contributes to major usability problems for everyone.

Costco is only one example of many I found. But I’m picking on them in particular because their brick-and-mortar operation is refreshingly progressive. The company prides itself on a “workplace focused on ethics and obeying the law”, and has enormous signs at their front door stating that they strive to accommodate the needs of their customers in accordance with the Americans with Disabilities Act.

So, to what do we attribute the utter inaccessibility of many e-commerce sites: ignorance, miscommunication, or malice? I’ve seen all three in practice. Often, it doesn’t take the threat of a lawsuit to get site owners to come around; they merely need to understand the problems, and what they can do to solve them, in order of impact on the user.

But I’ve also seen cases where it’s a legal game of chicken: some companies refuse to comply with a legal mandate that they feel doesn’t clearly apply to them. They’re gambling that the cost of being found guilty of non-compliance is lower than that of conforming to a standard that may not apply to them. This strategy falls apart like a house of cards as soon as one of them is found liable. And it’s a tactic I find particularly odious when they’re consciously acting to keep users with disabilities out.

The fact is that the Web has afforded many people with disabilities new-found potential to buy and sell things, work, manage finances, find community, gather news, and access government services — all things able-bodied people take for granted. When people with disabilities received legal protection, it wasn’t given out of pity. It was given to protect their right to participate equally in society. Web designers and developers can enable that equal participation with every site they design, using modern coding principles. Or they can hide in a castle or a cave, clutching their legacy code, certain that those evil, litigious disabled people are out to get them.

So, which is it?

At long last, the update to the paper I wrote (with the help and support of the WAI Protocols and Formats Working Group has been published as a W3C Working Group Note. It is now titled “Inaccessibility of CAPTCHA: Alternatives to Visual Turing Tests on the Web“, putting a finer point on the issue at hand than its predecessor, “Inaccessibility of Visually-Oriented Anti-Robot Tests: Problems and Alternatives“.

Weighing in at a hefty 3,000 words, it’s pretty long, even for me. It’s more than most people ever need to know about visual verification schemes. But hidden in there is a call to think about the problem you’re solving before relying on CAPTCHAs as a panacea. In some cases, outside of accessibility factors, its use is overkill. And in others, it may provide a dangerous false sense of security.

The new paper also gets into details the older version didn’t, and offers actual guidance at the end for solving the problem. The short version is as follows:

If you are a major site that doesn’t have a choice

…then it makes sense to have to use CAPTCHA, but you must allow other ways for real humans to access your service in a timely fashion.

If you are a low-volume site such as a blog

…don’t use CAPTCHA. Especially if it’s just to protect against posting spam comments. It’s inefficient, it’s a usability barrier for everyone, and it locks out more people than you think. Bayesian filtering is a Good Thing. I get dozens to hundreds of comment spams daily, and Spam Karma 2 for WordPress catches them all silently.

If you are a financial services site

…don’t use CAPTCHA-like tools for access control. New authentication systems are in use that randomize letter codes to correspond to a numeric keypad displayed on-screen. At best, the design falls into the dubious category of security through obscurity, which means it will be exploited when someone feels like it’s worthwhile. In the meantime, you’re blocking vision- and mobility-impaired users from basic tasks that would allow them to live unassisted. Until you figure it out, don’t take away those users’ autonomy for a short-term security benefit.

Have a look if you are using or considering CAPTCHAs for your site. And thanks to the Working Group, Al Gilman, Jon Gunderson, Janina Sajka, Marc-Antoine Garrigue, Dina Katabi, Kentarou Fukuda, Casey Chesnut, Sam Hocevar, Peter Krantz, Jason White and Viking At Large Charles McCathieNevile for their work on this paper and/or making access control more accessible.

Sometimes it’s funny when you’re cited. From the Woot blog:

“Hilarious!” raves Matt May of Corante about the Woot podcast. “These guys make Crazy Eddie look like His Holiness the Dalai Lama,” he continues. “Discover the Woot podcast.” We’re humbled to be praised by someone with May’s rugged good looks and fine ear for comic excellence.

As if you needed more evidence from me that CAPTCHA is a bad idea, here’s some more: Amazon has just made automated Turing tests obsolete.

Witness Mechanical Turk, which creates an open market for humans to solve tasks which are “extraordinarily difficult for computers, but simple for humans to answer.” Sound familiar? It was already a known fact that spammers had used cash (not to mention porn) as an incentive to get people to solve CAPTCHAs. Mechanical Turk now disintermediates the spammer-to-solver equation.

I would say that this is a decent way for blind users to get someone to solve a CAPTCHA that is in their way. But I know how things are going to go: spammers will use Mechanical Turk in droves, flooding it with high-value Turing tests. They will load the system with tests, something which will be particularly easy for them to do since it has hooks to Amazon’s Web Services API. They will often masquerade as blind users to attract sympathetic solvers. And they’ll offer the vast majority of the tasks on the site, at low prices, which will threaten the community of solvers unless Amazon gets involved in a serious way to weed them out pre-emptively. In essence, Amazon will have to be able to disqualify CAPTCHA-collectors worldwide, and make it stick, in order to keep solvers coming back, and major Web companies from suing Amazon for contributing to their access-control problems.

In other words, this whole thing, cool as it seems, is doomed from the start. But it’s going to take visual Turing tests along with it. No matter how hard the tests are to solve, Mechanical Turk is a magic bullet for anyone who wants to pay to get past it. It’s not as threatening for bloggers (who shouldn’t be using CAPTCHA anyway, since Bayesian filtering is as effective and less obtrusive) as it is for the Hotmails, Googles and Yahoos of the world, whose resources are worth much more than a ten-cent investment in solving a Turing test. It’s just a much easier method for attacking a weak authentication scheme.