[Bug 9817] Details element Focus problem

http://www.w3.org/Bugs/Public/show_bug.cgi?id=9817





--- Comment #4 from Rich Schwerdtfeger <schwer@us.ibm.com>  2010-09-09 18:21:47 ---
The problem is that if tabindex can be on the button and the container that the
b utton ultimately launches you have defined two interaction patterns. We just
can't say people are on a details element when you are on a button. If you are
going to place a user on a button and then have it control a section that is
being revealed then you have the situation where:

default native semantics is a button with an implied aria-controls relationship
to the what is being rendered as well as aria-owns relationship that allows an
AT to go back to what reveals the details. The container will have different
semantics based on how it is used. Basically, anything can be in the container.

However, if you have focus moved to the container then you are no longer on a
button and when it is read to the screen reader it is a container with
indeterminable semantics but it is no longer a button it is an expandable
container. 

Then you have the situation when the container and the button could receive
focus as they are both in the tab order. This is incredibly confusing.

So, what we are saying is HTML 5 is defining two different sets of semantics
based on how it is being implemented. Once you land on the element with focus
-button or container you need to decide what to do next. It is confusing to a
user to land either on a button or a container and then know what type of
element they are and what to do. Let's be consistent. 

A recent source of frustration we experienced with HTML 4 and browsers is the
form element for grabbing a file to upload. In FF the button gets focus. In
Chrome the container and button get focus. In neither of those case can you
access the text returned from the file dialog. However, then you have IE which
then puts the text of the file returned in the tab order and then allows you to
edit it which none of the other browsers do. This is all incredibly confusing. 

We need consistency and we can't get there with multiple interaction patterns
on the the details element.

<divs> by themselves have no semantics. So, if you land on one and add some
interaction behavior to it without applying semantics it is a wcag 2 guideline
4 failure. <HTML> should not receive a tabindex either. 

So, yes, this is a problem that results from tabindex.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Thursday, 9 September 2010 18:21:49 UTC