Yeah, Yeah…. But Does it Talk?
There’s been quite a bit of discussion in the blogosphere regarding the [latest version of Google’s toolbar](http://toolbar.google.com/T3/index “Visit the Google Toolbar 3 beta site”), currently in public beta. At the center of the controversy is AutoLink, a feature which may be useful, harmless, or the end of civilization as we know it. It depends on whom you ask. A few samplings from the anti-AutoLink camp include [Dave Winer](http://www.thetwowayweb.com/2005/02/22#a272 “Google’s Toolbar and Content Modification”), [GeekNews](http://www.geeknewscentral.com/archives/003879.html “Open Letter to Google”), and [Dave’s Ramblings](http://blog.captivereefing.com/2005/02/17/googles-world-domination/ “Google’s Word Domination”). In the pro-AutoLink camp, you’ll find sentiments such as those of [Fred von Lohmann](http://www.eff.org/deeplinks/archives/003377.php “Who Owns Your Desktop? You Do!”), [Yoz Grahame](http://cheerleader.yoz.com/archives/001928.html “A response to Dave Winer about Google AutoLink”), and [Anil Dash](http://www.dashes.com/anil/2005/02/17/free_the_user_a “Free the User Agents!”).
As is often the case, I find myself in yet another camp: the Just Make It Talk Camp. For those of you not familiar with this obscure little group of which I am a proud member, I am not suggesting that the Google Toolbar include a text-to-speech component. “Does it talk?” is a colloquial way of asking if a product is compatible with screen reading software. Screen reading software provides access to information through speech synthesis and/or refreshable braille output. As you can see, “Does it talk?” is easier to say. And the answer with respect to the Google Toolbar is “No, it does not.” As a result, people who are blind cannot decide based on experience to applaud this new feature or to declare it a blight worthy of nothing less than immediate eradication.
Having downloaded and installed Google Toolbar 3, I have identified the primary access issue to be the lack of keyboard shortcuts. If you physically cannot move focus to the toolbar buttons, how are you supposed to use its features? (For those of you who are not familiar with access issues for users who are blind, try this experiment: Turn off your monitor and then try to click on your browser’s Tools menu. You’ll have an awfully hard time because you cannot see where your mouse pointer is. Now try to get into the Tools menu with the keyboard shortcut Alt T. Even with the monitor off, this time you should be successful.) The only toolbar control I was able to navigate to without the mouse was the search edit combo box using Alt G. A subsequent glance through the online documentation confirmed my suspicions: “At this time Alt + G is the only keyboard shortcut the Toolbar recognizes.” So I sent the Google folks a brief note, and immediately got an automated reply stating that they don’t respond directly to feedback, but they take it all very seriously. Where have I heard that before? But I will give them the benefit of the doubt for now and encourage you to [advocate for an accessible Google Toolbar](http://www.google.com/support/toolbar/bin/request.py “Send feedback to the Google Toolbar team”) as well.
In the meantime, I decided to put Google Toolbar 3 through its paces. Given the lack of keyboard shortcuts, I had to use JAWS to physically move the mouse pointer around on the toolbar. Most of it can be done non-visually if you know exactly where to look, have good spatial orientation, and a very strong desire to use Google Toolbar. I’m not convinced that, in its current form, it’s worth the hassle. But I took some notes as I tried it out, and will find some time to post them for those of you who want to experience first-hand what all the fuss is about. That said, there is one aspect of AutoLink that strikes me as potentially promising in terms of access to the web, something that is not intended to be an access feature—or a feature at all: navigation by class of information. Let me give you an example: One of the sites I tried AutoLink on was [NAPVI.org](http://www.napvi.org “The home page of the National Association for Parents of Children with Visual Impairments”). I navigated to the the NAPVI Chapters page, then used the JAWS cursor to move to and click on the “Look for Map” button (apparently the AutoLink button changes names depending upon page contents). With each click on the button, focus automatically moved to the next street address, and JAWS read it. It was the functional equivalent of visually scanning the page for street addresses!
If you’ve been keeping up with what’s new in assistive technology, then you probably are already familiar with my favorite new JAWS 6 feature: Skim Reading. Skim Reading allows you use JAWS to scan a document for “regular expressions,” or patterns, such as all of the lines that contain a number followed by a word followed by Ave, Str, Dr, etc. However, given a complex document, you have to be pretty clever to find all of the items you do want, and only those items. The ability to skim by type of information, rather than by pattern, would be even better. The Google Toolbar is not there yet. Not by a long shot. And it might never get there, because that’s not the intent of AutoLink. As its name suggests, AutoLink’s purpose is to add links to documents based on type of information so that you can quickly locate other related pages; not to find what you want on your current page. Besides, currently the only types of information supported are:
- Street Addresses
- DHL, FedEx, UPS and USPS tracking numbers
- Book or publication ISBN
- Automobile VIN
So I have two hopes: Ideally, one day, web pages will be marked up not just in terms of format, but in terms of information type so that all users—including those who are blind or visually impaired—can quickly locate the information they need. Barring that, it would be nice if the AutoLink controversy died down and the technology further developed so that we could inherit navigation by type as a side effect. To quote [Anil Dash](http://www.dashes.com/anil/2005/02/17/free_the_user_a “Free the User Agents!”)
I’ve always thought that a user agent (the software that decodes a web page so that you can work with it) should be able to do whatever it wants. In the same way I can rip, mix and burn all the other media I bring into my computer, something as straightforward as an HTML page should be fodder for processing however I want.
I don’t think Anil’s talking about equal access to information, but I couldn’t have put it better myself.
—jd