Opened 12 years ago
Closed 11 years ago
#8217 closed defect (wontfix)
stackContainer: update ARIA to set relationship between tab and tab panel
Reported by: | Becky Gibson | Owned by: | Becky Gibson |
---|---|---|---|
Priority: | high | Milestone: | 1.4 |
Component: | Accessibility | Version: | 1.2.1 |
Keywords: | Cc: | Joseph Scheuhammer | |
Blocked By: | Blocking: |
Description
This affects AccordionContainer? and TabContainer? as well.
There is an action for the ARIA spec that describes that a relationship should be set up between the tab and the tab panel associated with that tab: http://www.w3.org/WAI/PF/Group/track/actions/311
Thus, we need to update the containers to follow this pattern. Either add an unique id to the associated tab panel and do
dijit.setWaiState(tabButton.focusNode, "controls", Id of tabButton.contentWindow.domNode.id) or
dijit.setWaiState(contentPane.domNode, "labelledby", id of button associated with contentPane.focusNode);
I think the first option (using controls) makes more sense since the button is already labeled via the labelledby attribute and this could be too many levels of indirection fot the browsers to handle.
Change History (5)
comment:1 Changed 12 years ago by
Milestone: | 1.3 → 1.4 |
---|
comment:2 Changed 11 years ago by
actually, the div that wraps the associated tab panels already has a labelledby relationship set up. The div with the role of tabpanel has an aria-labelledby that associates it with the current tab button. This should be sufficient. Doing more checking.
comment:3 Changed 11 years ago by
The only issue is that the labelledby value is changed after the onclick handler for the button has been invoked. This means that Firefox might not be catching the labelledby change and notifying the screen reader. Have sent an email to Firefox and JAWS devs for clarification.
comment:4 Changed 11 years ago by
After email discussions, current labelledby scheme should work correctly. It probably would be better if the actual contentPane associated with each tab button is given the role of tabpanel. However, I am reluctant to do that because the author may have already specified a role on that content pane (could be a tree, navigation or other role) and I don't want to over write it.
comment:5 Changed 11 years ago by
Resolution: | → wontfix |
---|---|
Status: | new → closed |
some of this depends upon support from FF and screen readers - moving to 1.4 so can work with screen reader developers for next release