This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13317 - spinbutton - are there any special handling rules for focus like there are for tablist?
Summary: spinbutton - are there any special handling rules for focus like there are fo...
Status: RESOLVED WORKSFORME
Alias: None
Product: ARIA
Classification: Unclassified
Component: Core AAM (show other bugs)
Version: 1.0
Hardware: PC Windows XP
: P1 normal
Target Milestone: ---
Assignee: David Bolter
QA Contact: ARIA UA Implementors
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-21 15:12 UTC by Andi Snow-Weaver
Modified: 2011-07-22 18:33 UTC (History)
0 users

See Also:


Attachments

Description Andi Snow-Weaver 2011-07-21 15:12:29 UTC
Even though tablist is a single selection scenario, it has special processing rules for setting states when a tab panel has focus:

"In the single selection case, it is not always necessary to manage selection events and states separate from focus, since selection mirrors focus. One exception is for tablist. In the case of a tab, if either the tab or its associated tabpanel has focus, then the tab is considered to be SELECTED. To implement this, the user agent can walk up the parent chain from the focus until it finds a tabpanel, then traverse the aria-labelledby relation from the tabpanel to the related tab, and mark the found tab as focused."

In the meeting on July 21, we looked through all of the roles to see if there are any other exceptions. Spinbutton looked like a possibility because the buttons might have focus but one of the options is selected. 

David, 

Determine if there are any special processing rules we need to describe for spinbuttons similear to what we have above for tablist.
Comment 1 David Bolter 2011-07-22 18:33:12 UTC
After a more careful reading of the case for tabs and tabpanel, I don't think spin button requires this sort of special processing.