#10038 closed defect (fixed)
tabContainer: the tabstrip arrows are in the tab order and should not be
Reported by: | Becky Gibson | Owned by: | Shane O'Sullivan |
---|---|---|---|
Priority: | high | Milestone: | 1.4 |
Component: | Accessibility | Version: | 1.3.2 |
Keywords: | a11y | Cc: | Becky Gibson |
Blocked By: | Blocking: |
Description
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.
Attachments (1)
Change History (12)
comment:1 Changed 10 years ago by
Cc: | Becky Gibson added |
---|---|
Owner: | changed from Becky Gibson to Shane O'Sullivan |
comment:2 Changed 10 years ago by
Milestone: | tbd → 1.4 |
---|
comment:3 Changed 10 years ago by
Status: | new → assigned |
---|
Changed 10 years ago by
Attachment: | NoTabIndex_TabController.patch added |
---|
comment:4 Changed 10 years ago by
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
comment:5 Changed 10 years ago by
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?
comment:7 Changed 10 years ago by
(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.
comment:8 Changed 10 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Bill,
You're right, that works just as well, and is simpler. I've checked in that change in [20599]
comment:9 Changed 10 years ago by
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.
comment:10 Changed 10 years ago by
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.
Patch that fixes this issue.