tabContainer: the tabstrip arrows are in the tab order and should not be

[Becky Gibson]

As I tab through the first tab panel example in dijit/tests/layout/tets_TabContainer.html, focus goes from the click to Add Tab button to the down pointing arrow on the far right of the tab strip, then to the left pointing arrow on the left hand side of the tab strip, then to the right hand pointing arrow and finally to the actual current tab button. Since there are no keyboard actions associated with the arrows they should NOT be in the tab order.

If I look at the generated source, those tabstrip arrows are in a div that is marked with aria role=presentation but also have tabindex=0. You can not have both an aria role and a tabindex defined. I suspect that these tabstrip buttons inherit from tabbutton as I see that they are marked dojoAttachPoint="innerDiv,focusNode". I suspect the tabindex is inherited via attribute map because they are marked as focusNode.

At any rate, these arrows should NOT be in the tab order unless they work with the keyboard AND are given proper ARIA roles for the screen reader. Currently when using the screen reader there is no information spoken about these arrows.

[Shane O'Sullivan]

Patch that fixes this issue.

[Shane O'Sullivan]

I've attached a patch for discussion. The approach it takes is to ignore the tab index when it is set, by creating the function _setTabIndexAttr

I would have preferred to modify the attributeMap, but for some reason, I can't seem to remove elements from it. Doing

delete this.attributeMaptabIndex?

in the constructor doesn't modify it. Setting that value to null or undefined causes an exception to be thrown, since doing

for(var name in this.attributeMap)

will still show up the "tabIndex".

If anyone can figure out how to simply remove the tabIndex from the attribute, let me know. Otherwise I'll go ahead and submit this patch

[bill]

Well, for the patch you've attached, it seems like you can achieve the same thing by just sticking tabIndex: -1 into the definition of _ScrollingTabControllerButton, right?

[bill]

PS: actually that should have had quotes:

tabIndex: "-1",

[Shane O'Sullivan]

(In [20599]) Refs #10038 Fixes the tabbing issue where it is possible to tab onto the SlidingTabControllers? control buttons. These are intended for mouse use only, and should not be possible to tab onto.

[Shane O'Sullivan]

Bill,

You're right, that works just as well, and is simpler. I've checked in that change in [20599]

[Becky Gibson]

Although now you have a div that is marked with role=presentation and it has a tabindex=-1 which is not allowed per comment in #9802.

[bill]

Oh, sorry, I guess I gave bad advice above.

Since the goal is apparently to override an inherited tabIndex: "0" from dijit.form.Button, I think tabIndex: "" will work. It seems to, I'll check that in.

Firebug is still reporting that that node has tabIndex=-1, but it says that about every node, so I think that is different than having tabIndex = -1 explicitly set.

[bill]

(In [20611]) Try not to set tabIndex to anything on the <div>, rather than setting it to -1. Refs #10038 !strict.