This is inspired by a discussion between Jamie, myself, and RJ from Google. In Gmail, when you open a conversation and have all keyboard shortcuts enabled, n and p switch focus between the different messages within that conversation. In Chrome (and incidentally, Safari on OS X), a screen reader will speak the from, to, and message body information of a message. In Firefox, it won't. The difference is that Chrome calculates an accessible name from a certain div's sub tree, and Firefox doesn't. There is no explicit name like aria-label or aria-labelledby, but there is a tabindex="0" on that div. The reasoning to not use an aria-label here is that there is too great a risk some AT might do the wrong thing and trump all child elements, including interactive ones, and will just use the aria-label* on the whole thing, even inside a virtual buffer or so. I even saw this myself in a different context in Safari+VoiceOver back in the Mountain Lion days, but thankfully they fixed that since. The child elements simply weren't accessible even when tabbing. So I propose to treat container elements like this: If they have tabindex="0" set, and no explicit name, calculate a name from the sub tree for this element. Thoughts?

To add to my report: The effect of us not doing an accessible name calculation here is that, if the user isn't in browse/virtual cursor mode and uses the shortcuts p and n, JAWS and NVDA will just speak "section", but no useful information. Further reasoning: If tabindex="0" is usd on a div, it is fairly safe to assume that the author wanted something to happen with this particular element. So we should make sure that, if no explicit name is given, we give screen readers something useful to speak.

somewhat related: https://lists.w3.org/Archives/Public/public-html/2015Apr/0037.html Marco wrote: "Further reasoning: If tabindex="0" is usd on a div, it is fairly safe to assume that the author wanted something to happen with this particular element." I wouldn't be so sure, but think if you go down this route, then and announce the acc name from subtree then should have some role (group?).

(In reply to steve faulkner from comment #2) > Marco wrote: "Further reasoning: If tabindex="0" is usd on a div, it is > fairly safe to assume that the author wanted something to happen with this > particular element." I wouldn't be so sure, but think if you go down this > route, then and announce the acc name from subtree then should have some > role (group?). Maybe. Group, however, is dangerous because some screen readers have the annoying tendency to repeat the group name when tabbing to children of that group. Sticking to the Gmail example, that would cause real problems if the message, and therefore the resulting calculated accessible name, is long.

(In reply to Marco Zehe (:MarcoZ) from comment #3) > Group, however, is dangerous because some screen readers have the > annoying tendency to repeat the group name when tabbing to children of that > group. Please don't use a role of group. NVDA doesn't repeat the group name for each child, but it does speak the group when focus enters it for the first time. It's perhaps reasonable to assume that the user cares about the name if the div itself gets focus, but I don't think we can extend this to say that it's reasonable that the div should be treated as a true semantic container.

On the VoiceOver side, VO focus doesn't even move to such an element (tabindex, but no role) in Firefox. In Chrome and Safari, it announces as "Group" - following in line with your suggestion, just without the calculation of something useful to say along with that based on the element's internal bits. Chrome does expose up an AXTitle on the element based on its textnode in MacOS and a name attribute in IA2. Since nobody picks up on that, guessing Chrome may need to do that differently? Happy to file a bug on that end, if so.

(In reply to Shawn Lauriat from comment #5) > On the VoiceOver side, VO focus doesn't even move to such an element > (tabindex, but no role) in Firefox. In Chrome and Safari, it announces as > "Group" - following in line with your suggestion, just without the > calculation of something useful to say along with that based on the > element's internal bits. Hm, this can't be right, at least for Chrome, because I *do* hear the message contents in VoiceOver when I open a conversation in Gmail and press n and p. > Chrome does expose up an AXTitle on the element based on its textnode in > MacOS and a name attribute in IA2. Since nobody picks up on that, guessing > Chrome may need to do that differently? Happy to file a bug on that end, if > so. But JAWS and NVDA *do* pick up on that on Windows. And from my observation, VoiceOver does on OS X, too. Whether having the profile image's UUID or other non-useful info to be included in that is debatable ;), but at least one hears something other than just the word "section" on Windows, or "group" on OS X. Re the "group" on OS X thing: any things on OS X are a "group" from the main AXRole. We should not let this guide us to think role "group" is appropriate here. I agree with Jamie that it isn't.

I hear that too, but in a reduced case of <div tabindex="0">Hi there</div> I don't. The gmail case has an aria-labelledby pointing to a div with a consolidated phrasing, which I'd guess informs Chrome as to the label to use there. It doesn't just pull it from the subtree from what I can see. Otherwise, I'd expect VoiceOver to say something about the "Hi there" text node in the super-reduced case.

Forgot to add: I completely agree that Firefox shouldn't just follow what VoiceOver happens to say in this case, I just wanted to add more context for the discussion without folks having to go check for themselves as to what VoiceOver says.

I do prefer that those divs had a role, for example, "from" and "to" fields are probably matched well by readonly textfields. If that doesn't go with the real world then I'm flexible about name computation for div@tabindex in general but I have doubts about div@tabindex@contentEditable (aka focusable div vs editable and of course focusable div), I'm not sure whether 'message' field from example above is an editable field. Anyway, it'd be good to have some public discussion with Googlers. Marco, would you send an email to Browser Accessibility Development group?