In these notes, I summarize my presentation of original research and testing of an Ajax application (Basecamp) with users of screen readers and other adaptive technologies.
Here’s my working definition of Ajax: The use of scripting to cause portions of a page to refresh without reloading the entire page. That usually happens after the user does something, but it can also happen automatically.
Gmail is an Ajax application. So are a lot of things these days. The question is: Are they accessible?
Well, what do we mean by that? We mean that a person with a disability can do all the same things, and obtain all the same information, as a nondisabled person. That doesn’t mean the methods have to be exactly the same, but they cannot be significantly harder for disabled people or the result is discrimination.
Of course there’s a lot of wiggle room in the word “significantly.” There always is; that’s the nature of accommodation of disability. Some things are clear-cut, like “A person in a wheelchair must be able to enter your building” or “Every image has to have a text equivalent.” But some other issues really are judgement calls.
One way you can narrow things down is by user testing. If everybody or nobody can do a certain task, then you have an unequivocal answer. If most people can or cannot do the task, then you have a very strong answer. If one or two people using a certain set of equipment cannot do your task, then you know it mostly works and you only need to fix that one thing.
So instead of philosophizing about Ajax accessibility, I decided to do some quick user testing, which I’ll tell you about later.
But let’s start off with what the accessibility guidelines tell us.
The first place to start is WCAG, the Web Content Accessibility Guidelines. If you’ve ever read that WCAG 1.0 essentially bans JavaScript, it’s true. WCAG 1.0 was developed in an era in which screen readers could barely handle plain text, let alone DOM scripting, a term that didn’t even exist yet.
Here’s what WCAG 1.0 says:
- Provide a text equivalent for every non-text element... This includes: Images... applets and programmatic objects... scripts....
This really does mean you need a text equivalent for a script, which makes no sense at all.
But then they go on to give you advice that we would now consider along the lines of progressive enhancement or graceful degradation.
- [I]f you use applets and scripts: Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.
This is the killer. This is the checkpoint that forces you to create pages that work with JavaScript and without, which pretty much bans anything that only JavaScript can do, including anything that improves accessibility. You must provide both X and anti-X.
- For scripts and applets, ensure that event handlers are input device–independent.
- Until user agents allow users to freeze moving content, avoid movement in pages.
- Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies.
- Ensure that any element that has its own interface can be operated in a device-independent manner.
- For scripts, specify logical event handlers rather than device-dependent event handlers.
WCAG isn’t the only game in town, though. You can also look at the U.S. Section 508 requirements, which are a lot simpler:
- When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.
This at least means you can use scripting. You just can’t generate any text that a screen reader cannot locate and read.
- When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.
Since a lot of Ajax applications are pages full of glorified forms, this is useful advice.
But mostly we have to worry about WCAG compliance, since not many of you here are building Web sites for the U.S. federal government.
If you know about WCAG then you know that many parts of it are outdated. And you also know that a lot of people have developed expertise over the years in interpreting WCAG in contemporary ways.
For example, when people started making tag-soup Web sites accessible, we figured out that spacer GIFs had to have a null alt text, alt="". Then when we learned that tables shouldn’t be used for layout in the first place, we told people to stop using spacer graphics at all and do everything in CSS.
But if you just sat there and read WCAG, you wouldn’t know any of that. To make a really accessible site nowadays, you have to know these many details of implementation. The problem, of course, is that they aren’t all collected in one place.
We can do the same thing with the WCAG guidelines on scripting. The ban on scripting is simply passé and you can just ignore it. It isn’t realistic anymore to talk about browser–and–screen-reader combinations that don’t understand JavaScript.
Yes, of course there are one or two people using really old technology like text-only browsers. I use Lynx every day. But that ship has sailed. Not every single Web site needs to support that tiny minority.
The problem here is we don’t know what JavaScript accessibility is. We have a few ideas about it, but nothing’s nailed down yet. Really, it isn’t. And because there are so many things you can do in JavaScript, in so many different ways, it’s gonna take a while before we really decide on exactly what JavaScript accessibility is.
But: In the meantime, we can test. So that’s what I did.
For this conference, I had ten of my closest friends test an Ajax application in whatever browser and screen reader they were using. And which Ajax application did I use? Basecamp, of course!
A lot of you know 37Signals, right? That’s Jason Fried’s company. They’re famous for their blog, and almost as famous for their in-person appearances. Jason Fried and his mates are full of brio and really make a good strong case for whatever point they want to make. A lot of it is bullshit, but it sure sounds great, and, against my better judgement, even I find myself briefly believing some of it.
So one of their catchphrases is “Build half a product, not a half-assed product.” Another catchphrase is “Say no by default”: A feature you put in may require dropping another feature just to get the product shipped out. These sound pretty good, don’t they?
But the problem is: What if you think accessibility is a “feature,” like a to-do list or the ability to send a project reminder to your cellphone? (“We support accessibility,” like supporting a laser printer. “We provide accessibility support.”) If you look at accessibility as a feature, you’ll probably leave it out. Most developers are gonna leave it out anyway; most developers don’t know the first thing about accessibility or even that it’s important.
So my assumption was that Jason Fried and the lads had done exactly that: Just ignored accessibility because it had never occurred to them. It certainly should have occurred to them, since I’ve been leaving enough comments on their blog reminding them of it, but I expected they’d ignore it.
I also expected that my user testing would find Basecamp almost completely unusable because of what I assumed were nonstandard JavaScript calls.
It’s too bad Jason Fried couldn’t be here [in Iceland – he cancelled], because I wanted to have a total j’accuse moment when I presented evidence that Basecamp isn’t accessible. But I don’t have clear-cut evidence. The evidence I’ve got shows that Basecamp is usable, with difficulty and inconvenience, on Windows. And it’s even easier to use on Macintosh.
I’m only talking about blind people and I’m only talking about blind people who use screen readers. That isn’t everybody, but it’s the group with the most to lose from nonstandard Web development. They’re using lousy and outdated browsers, like Internet Explorer, with sometimes lousy and outdated technology, like screen readers.
I set up a demo Basecamp site, Denmark2006, inspired by and using facts from the site for my neighbourhood, Leslieville.org.
I recruited 10 blind testers using screen readers and I asked them to do three simple things: Add, edit, and delete. I figured if they couldn’t do that then they couldn’t do anything.
All they had to do was add an item to a to-do list; write something down in the Writeboard, which is a kind of general notetaking area; and delete a project milestone. Again, if you can’t do that then you can’t use Basecamp.
My results are easy to state: Everybody could do everything. It just wasn’t all that convenient.
I had people test with four versions of Jaws for Windows, with Internet Explorer and Firefox. I also had people test with Safari and VoiceOver on Macintosh.
I have a full listing of results, but here are a few things people said:
- Jaws 7.0, Firefox 1.5
I found the page difficult to proofread after I had entered the additional item. I wanted to double-check to make sure that I had entered the additional address, and I found the layout of the page difficult to follow. The list of addresses did not seem to directly follow a header. I had to read through a number of items on the page that did not seem to be directly relate to what I was looking for.
- Jaws 4.51, IE 6.0.290
I had to use the back button to get to the home page and found the Milestones button no problem. Once on the Milestones page, I had one heck of a time trying to find the right item to delete. Once I clicked the right check box I’m not sure what happened. Jaws went into forms mode and just hung. When I finally got it back the checkbox had been checked. The check box was not properly associated with the text, though.
But we aren’t done yet. I had the guy named Brothercake, whose real name is James Edwards (photos), run some other tests for me. He has a whole book chapter coming out (sample) on making JavaScript accessible to screen readers, and he’s got all the toys on his machine. His results are online with the other results.
But somebody else has done this kind of testing, too. Derek Featherstone back in Ottawa, and the blind guy who works for him, have tested Basecamp and other Ajax applications in various screen readers and have had seriously mixed results from one version of the Ajax application to the next. (Results are in the same place.)
What we can say, then, is that this Ajax application is usable by screen-reader users some of the time. They aren’t totally shut out, but it isn’t totally easy for them, either.
And if you’re thinking of low-vision people who use really large screen magnification, I’m pretty sure that the idea I like to promote – zoom layouts – will work here. Instead of a multicolumn page with small type, you use an alternate stylesheet to offer a single-column or two-column page with big type, usually light type on a dark background.
This requires rethinking the user interface somewhat, though only somewhat. But if you don’t do something like using a zoom layout, you get the standard problem of the right-hand side of the screen disappearing off the edge of the monitor when you blow up the size.
OK, so if Ajax is imperfect but not a total barrier to some blind people, is there another group it might actually help? I think maybe there is, and they’re the very hardest group to accommodate online – people with cognitive disabilities like dyslexia.
Contrary to popular belief, I am not opposed to accommodating people with these disabilities. I’m just realistic enough to say it’s difficult or impossible much of the time.
A lot of Web sites simply have too many words for this group, who often have trouble with reading comprehension. Sometimes the trouble is reduced just by using different fonts and colours, which is an easy issue that CSS can handle. But other times, there’s simply too much information on the page.
We’ve already got a few scripts out there – mostly from Australia, by people like Cameron Adams – to show and hide content on request. They use CSS and JavaScript, which by my definition makes them Ajax applications.
What I can imagine happening is the application of a kind of Web 2.0 graphic design to retail Web sites: Use not a lot of text and not a lot of interface options and let the text grow or expand on command. I’d bet that most people would never bother expanding the content, assuming it were well-designed and user-tested, but for people who need less content but can handle more content on request, this could be a good way of implementing it. But I don’t know of any examples, of course.
The conclusion I have from my testing is that Ajax has problems. Maybe not fatal problems, but problems nonetheless.
What I think is going to happen is that Web accessibility and Web standards will be replicated in microcosm: A tiny few people know how to make accessible Web sites and know how to code to Web standards, and everybody else does everything exactly the wrong way. It’ll be the same thing here, except the people doing the wrong things are hip upstarts like 37Signals rather than giant corporations hiring community-college grads trained in table layouts and the font “tag.”
I find this rather odd because, just to make an Ajax application work, you need pretty good HTML. You need pretty good document semantics to use as hooks for your DOM scripting. You’re more than halfway there just by getting your page to work in the first place. What I expect to happen, though, is that the remaining half of the problem will not be addressed – because accessibility is viewed as a “feature” that gets left off in the other half of the product.
See also: Results of usability tests of Basecamp
You were here: Home → Iceweb 2006 → Build Half a Product
Posted: 2006.05.04