Remove tab index

[limi]

Got some feedback here, putting it in the collector to make sure I don't forget.

We should mail him and ask for some feedback once we reach a testable state.

---

Subject: More Thoughts on Plone Accessibility for Screen Reader Users Date: Mon, 6 Dec 2004 20:17:53 -0500 From: rjc <rjc at MIT.EDU> Hi... Just been taking a more thorough look at plone with regard to accessibility. Please let me know to whom I should send these thoughts. I created a user for myself, logged in, and clicked on my folder. I now have access to one object (my homepage). When navigating this page, I noticed discrepancies between the tab order (when navigating via the tab and shift+tab keys), and document order. This lead me to check the HTML source and voila - lots of use of tabindex.

While very tempting, it is not a good idea to use this unless your very

careful. Its hard to explain the problem unless you are familiar with what it is like to browse the web via screen reader. Briefly, one has two views of a document via modern screen reader, the real view (what the browser sees and you can see via the tab order and when interacting with form controls), and virtual view (a view created by the screen reader for ease of navigation by the blind user. They are usually pretty synchronized, but when you use tabindex, then you will see items in HTML order via the virtual view, and in tab order (as modified via tabindex) in real view. For instance, I know that in virtual view the checkbox to select whether to delete an object from my folder is just before the name of the object. In fact, its in the preceeding table column. So, if I've tabbed to the object name and then hit shift+tab, logically I should land on this checkbox. However, since this checkbox is tabindex=4, I do not. Conversely, if I navigate to the name of my homepage object, and then navigate to the previous item in virtual view, I find the checkbox to "select my homepage object". If I then press tab, I end up not on the name of my homepage, but somewhere in the navigation section of the page (whatever comes after tabindex=4 in the tab order -- happens to be the rename button. This is very confusing to someone who cannot see. Its almost as if the "select object" checkbox exists in two places at the same time, depending on how you walk through the page. So, I strongely suggest you nix all tabindex usage from the code. See below for more ways of speeding up access to commonly used controls. accesskey= attributes These should be used correctly (see previous note), and only for commonly used controls. For instance, on the page displaying my folder contents (only my homepage object exists now), I see controls for all the standard operations like cut, copy, delete, etc. Since these will be conducted frequently by a user with real content, and since it is a pain in the butt to have to go tabbing around the entire page to find the control you wnat, a standard set of access keys (shortcut keys if you will) should be defined for such operations. They should be promoted throughout plone core and in default templates (so anyone who uses plone to produce sites should get them without having to do any extra work). A suggested set might be:

• cut=x, copy=c, edit=e, select current item=i
• I left delete off so people won't delete by accident
• undo=z, rename=r

You get the idea... Not familiar with plone, but there might be more common actions which deserve such treatment. Perhaps accesskey=0 on the link to take you back to the site homepage, and accesskey=n and accesskey=p for any pairs of next/previous links for browsing collections of documents or items in a list etc.

[limi]

And the mail on access keys:

Hiya... Just stumbled on plone.org. I am a blind computer user, and want to applaud your wonderful effort. Haven't delved very deep yet, but the site plone.or is very accessible and easy to use via screen reader, and the system seems very powerful and configurable. I have noticed one small problem with your XHTML however. You use the following code (note the accesskey= attributes on the "a" elements. They are not correct. An access key should specify a one-character string which becomes the shortcut key for that link or control. You can use it on

"a" and "input", and "select" elements. In your use of it below, it

looks as if you meant it to be a string specifying how one might access this element via keyboard; this is not correct. Note that different browsers will have different ways of invoking keyboard shortcuts applied this way. <!-- Plone code ... -->

<li id="portaltab-index_html" class="plain">

<a href=" http://plone.org"

accesskey="accesskeys-tabs">Home</a>

<!-- accesskey="m" ... IE would then honor alt+m as shortcut for this link

-->

</li>

<li id="portaltab-about" class="plain">

<a href="  http://plone.org/about"

accesskey="accesskeys-tabs">About</a>

</li>

... -- Rich Caloggero, MIT Adaptive Tech. for Info. and Computing

[hannosch]

Existing accesskeys are now properly definied in Plone 2.1. But we need to agree on what really should get an accesskey.

See also:  http://plone.org/collector/3535

[hannosch]

As accesskeys have been removed in Plone 2.1, this issue is now about tabindex only.

[hannosch]

Thx to optliude tabindexes are gone now :)