Operating under the assumption that this is going to land, I'm working on making the change in Chromium. (This is independent of the name prohibition code changes btw.) Running Chromium's tests to see what broke led to me finding another thing we need to handle somewhere:

The group role does allow naming BUT from author; not from content. So some things which were generic lost their names as a consequence of becoming a group with no author-provided name. Oops!

Thoughts?

in the context of contenteditable, if not specifically named by an author, it exposing no name makes sense to me. since large areas of content can have a contenteditable parent, we would not want all that content contributing to the parent's accessible name.

Similar with tabindex=0 on a scrollable div of content.

what are some of the things you are finding that lost names that I might not be considering here, that we might want to maintain?

what are some of the things you are finding that lost names that I might not be considering here, that we might want to maintain?

One test that broke had this: <div tabindex=0>Focusable div</div>

• Expected results for blink (reminder: I've not done the name-prohibited stuff): genericContainer name='Focusable div'
• Actual results for blink: group

If a user tabs to that focusable div, they should get a name presented to them, right?

@joanmarie yeh that's a reduced example of these https://codepen.io/scottohara/pen/bGBaYEQ

where i think it'd be quite problematic for all that content to be exposed as the name. I don't think <div tabindex=0> should get name from contents.

IMO this is something that should fit into the "handling author errors" of the ARIA spec. So if something gets focus and has no accessible name then author agents MAY correct by doing (a) (b) (c) etc.

@scottaohara and @jnurthen I'm away on "vacation" next week. But it would be great to have consensus on this so that we can proceed doing/getting our 1.2 implementations. 😄

I think role=group may be too simple of a repair.
For a contenteditable, I would suggest role=textbox is more appropriate. The browser can even try to set aria-multiline appropriately based on whether the field's CSS limits rendering to a single line.
We could even map to role=button if there is a click handler.

@aleventhal have you reviewed the discussion on this in #259?