Accesskey and tabindex not helpful to blind users?

Hi all -

OCW is doing a complete overhaul of our Web site in an attempt to improve 
accessibility and validate against the XHTML 1.1 DTD giving more control to 
layout via our CSS.

In this process, I've run a draft of our accesskey and tabindex policies 
past  Rich Caloggero from MIT's Adaptive Technology for Information & 
Computing lab (ATIC), who is blind.

As per his permission, I am enclosing his comments below. I see accesskey 
and tabindex being very useful for those who cannot manipulate a pointing 
device as well as those who are blind however in light of Rich's comments, 
I'm not quite sure where to go from here and I'd like to solicit the list's 
comments.

My proposal can be found here:
http://mit.edu/ocwhq/prod/access/accesskey-tabindex-6-6-05.pdf

> From Rich C.:
>
>** Tabindex
>The biggest concern for me is the use of tabindex. Its difficult to 
>explain how confusing use of tabindex can be, but I'll try...
>Just about all screen readers in common use today provide what they call a 
>virtual view of a web page. They essentially parse the HTML (either 
>directly or via the DOM), and allow the user to move through a textual 
>representation of the page in the same way as one would move through a 
>word processor buffer.
>
>Here is a page with three links on it and a bunch of text associated with 
>each link.
>( http://narita.mit.edu/js/tabindex.html )
>Imagine moving through the page line by line with the arrow keys. As you 
>move, one line is read.  If you decide that you want to move through the 
>document a bit more quickly and press tab, you'd expect the focus to move 
>forward through the document to the next anchor or focusable element. In 
>general, this is exactly what happens. However, if tabindex is used, this 
>is not always the case. It can be very confusing to be reading in one 
>point and then press tab and be taken to a completely different (possibly 
>unrelated) point of the document.  Another approach to navigating a 
>document via screen reader that many people (including me) tend to use is 
>to try and quickly scan the page first by heading (screen readers can move 
>from heading to heading with one keystroke) and then by tabstop. If we 
>then want more context (I just landed on an anchor which reads "book 
>list", and I want more context (book list for what), I'll start navigating 
>via arrow keys till I get the context I need. Then, I'll start moving via 
>tab again. If tab order does not follow element order (i.e., tabindex is 
>used), then a press of the tab (or shift+tab if going backwards) may not 
>move me to where I expect to be, and things get very confusing very quickly.
>
>If you need to see me demo this, we can schedule a few minutes to do that. 
>Its very hard to describe this in words...
>
>
>** Access Keys
>Personally, I don't like numbers as access keys, because they are not 
>mnemonic at all. I already have to remember hundreds of keyboard shortcuts 
>and screen reader keys, etc. I don't need another set of random mappings 
>to remember. However, I also understand the argument that numbers don't 
>conflict with menu keys, and saving the letters for buttons and other 
>form-based keys makes some degree of sense. My suggestion is to use as 
>small a set as possible, and have them make some kind of logical sense.
>1: home (this makes sense)
>2: moves to skip link (makes sense, this is something keyboard users will 
>do on just about every page)
>0: access key info (perhaps consider "k" for that, but 0 seems to be used 
>in a lot of places around the web, so makes sense)
>s: search (just about every site has a searchbox, so why not have this be 
>standard)
>
>I'm not sure you need much more than that to get started. If you use 
>headings properly, then screen reader users will use their screen reader's 
>heading navigation keys to skip nav lonks and efficiently move through the 
>pages; the access keys will mainly be used by non-screen reader keyboard 
>users.  Forms and web applications (like eMail clients) are the bits that 
>really need to use access keys. Are there any such pages planned for OCW? 
>If the form is a simple login for etc, then they are not really necessary, 
>but web apps like mail readers, file/resource managers (anything where you 
>need to move quickly from control to control) can really get tedious to 
>use if the only way you have to navigate is tab.


--
B.K. DeLong
Web Production Specialist

MIT OpenCourseWare (OCW)
Massachusetts Institute of Technology
Building 9, Room 215
105 Massachusetts Ave.
Cambridge, MA 02139-4307

email: bkdelong@mit.edu
http://bkdelong.mit.edu

Received on Friday, 8 July 2005 13:20:38 UTC