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?

On Monday, August 20th, I’ll be speaking at Refresh Seattle (Ballard Library, 5614 22nd Ave. NW) from 6-7:30pm. Attendance is free, but you totally have to buy me a beer afterward. (Okay. Maybe just one of you. Sixty would be too many.)
One talk about accessible design ain’t enough, Jack. You’d better make it three. The talk is titled “Web Accessibility in Three Acts”. These mini-talks will cover:

• Everything you should probably know by now as a web designer or developer;
• What to look forward to with new web technologies and advanced accessibility techniques; and
• Accessibility hacks – what you can do with the tools that come free with your operating system.

Yes, I will be talking about Ajax, Flash and Flex. Yes, I may even say “Rich Internet Applications.” Things are moving so fast in this space that it’s hard to know what to say even in an hour and a half, especially to tired, thirsty people. Hopefully, this one is going to be fun for the whole family. Bring your engineers! Your product managers! Everybody is invited!

Today at work, the fire alarm went off, and I was reminded of what the HR person told me during orientation on Monday: if you get outside and there’s no ice cream, then it’s not a drill.

We got ice cream.

As some of you may have heard, this week I started in my new position as Adobe’s accessibility engineer. I’ve known many of my new coworkers at Adobe for years now, and it’s great to be able to finally get me a copy of CS3 – I mean, to have such talented people around me. I’m working out of the Seattle office, next door to where I got married, and across the street from the Blue Flavor guys. All systems are go.

And hey, while I’m at it, here’s a brief history of my 2007 so far. Since the first of the year, I had been working in Amazon.com’s enterprise group on the front end for their newest merchant. That site went live last Tuesday. (Rumor control: no, they didn’t hire me to do accessibility work. No, I didn’t have anything to do with the NFB agreement. In fact, I never even talked with anyone who works on Amazon’s core site, that I know of. Hopefully this ends that little telephone game.)

Also, as of today, I am a second-year Arabic student. I’ve been studying at the Seattle Language Academy (which, conveniently, is a 5-minute walk from Adobe) since last June. The number one question I’ve had to answer since then has been, why Arabic? (Although “Can you get Photoshop for me?” is giving it a run for its money.) The answer is that I’m an infojunkie, and most of the important info is, unsurprisingly, coming from the Arab world. It’s a language that’s beautiful and complex, and I will (ٍإن شاء الله) stick with it until I have a good enough basis to move on from Modern Standard Arabic, or فصحى (fusHa), to colloquial, or عامية (ameyya).

So, that’s the news. No more fire drills for a while.

Yesterday at the Web 2.0 Expo, I had a chance to see Jeremy Keith’s session titled “The Beauty in Standards and Accessibility”. (If you happened to catch that and my session earlier in the day, I’m sure you got the point that standards-based development is kind of important when it comes to making reasonably-sized sites reasonably accessible.)

What I didn’t expect to see was the crowd of people that followed him for the quarter-mile walk from the session room up to the speakers room, where he handed out copies of his book, Bulletproof Ajax. It was fascinating to see this guy being swarmed by people as he left the room. I got the sense that they would gladly have carried him on their shoulders.

Jeremy wrote about it on his blog, but in typical British Irish-living-in-Britain style, left out the details of his new fan club, and it is my responsibility to state for posterity that Jeremy does, in fact, have a posse.

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

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.