This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Both the summary element and the details element are capable of receiving focus. That is problematic for assistive technologies. It would mean that the author could give the container focus <details> and the <summary> element focus. That is incredibly confusing as you have two elements meant to represent the entire element. So, if details gets focus we would need to say that the implied semantics is a something like: <details role="button" aria-labelledby="sumid"> <summary id="sumid"> ... </details> In this scenario the open attribute would have implied semantics equivalent to aria-expanded If you want summary to have focus then we have to give it a role of button with an aria-expanded property. That does not make a lot of sense but we could do it. If both summary and details have focus it is a pain for browser manufacturers and ATs requiring special case software to handle two different design patterns.
I recommend only details receive focus and that the summary be a label for it.
I recommend only details receive focus and that the summary be a label for it. In other words <summary> should not support tabindex
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Did Not Understand Request Change Description: no spec change Rationale: I don't understand. Is this only about tabindex=""? If so, how is this different than both <html> and <body> having tabindex, or six <div>s nested within each other all having tabindex=""?
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.
(In reply to comment #2) > I recommend only details receive focus and that the summary be a label for it. > In other words <summary> should not support tabindex Was this something you said based on how <label> works in Webkit? In Webkit, then it isn't possible to jump to the <label> via tabbing, no matter if you set the @tabindex attribute for <label>. As one tabs, the <label> is simply jumped over, in favour of the next element on the index list.
(In reply to comment #5) > (In reply to comment #2) > > I recommend only details receive focus and that the summary be a label for it. > > In other words <summary> should not support tabindex > > Was this something you said based on how <label> works in Webkit? > > In Webkit, then it isn't possible to jump to the <label> via tabbing, no matter > if you set the @tabindex attribute for <label>. As one tabs, the <label> is > simply jumped over, in favour of the next element on the index list. Webkit also doesn't allow focus on <legend> - only on <fieldset>. Regarding your expensive-for-AT-to-implement argument: Isn't the fieldset/legend/label/input combo quite complex as well? Do you simply want to avoid the same kind of complexitiy? It seems like giving focus to the <summary> element, is quite logical to authors. See this early <details> demo: http://mathiasbynens.be/demo/html5-details-jquery (article: http://mathiasbynens.be/notes/html5-details-jquery) In my view we have a similar dilema for <table>: I always found it illogical that @summary was located at <table> instad of on <caption> - as if one coudn't decide if the caption or the container should carry the caption role. Also see bug 10483: When we have captions, then I think it is important that that there is strong link between the captioning elemenet and the container element, as that element represents the entire element. E.g. if I had a page full of table elements, then the natural thing - if I were to jump from table to table - would be to jump from caption to caption. Should I want to copy the entire table, then it is just to move one parent up. And if I want to focus on the content, then I visit the adjacent element of the caption. The captioning element is like the semantic tag of the framing element - details/table/figure. Finally, it seems like you consider the focus-ability closely linked to the role. In that regard, how do you evaluate that <summary> at the moment has strong native semantics role="heading"?
new info provided
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Did Not Understand Request Change Description: no spec change Rationale: I still don't understand. Why would <details> be focusable? Surely only its disclosure widget would be focusable. I really don't follow what the problem is here. Note that just removing tabindex="" support from <summary> would presumably not change anything here, since you can still put links and widgets and so on inside <summary>.
Assigning to Steve to work with Rich to provide further info. http://www.w3.org/2011/02/03-html-a11y-minutes.html#item01
looking at how it is implemented in chrome the summary element is focusable and the details element can be open/cosed by either clicking/ pressing space or enter key.The details element does not recieve focus
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: works for me Change Description: non Rationale: implemented behaviour in webkit/chrome follows https://dvcs.w3.org/hg/html-api-map/raw-file/tip/Overview.html#examples-sum
I am satisfied with the solution and the accessibility API Mapping.