Define concept of minimum role

[scottaohara]

Worked on this with @aleventhal as this concept is necessary for some current HTML features (as identified in the attribute mapping table in this PR) as well as future proposed features, such as popover.

Implementation

• WPT tests:
• Implementations (link to issue or when done, link to commit):
  • WebKit:
  • Gecko:
  • Blink: https://bugs.chromium.org/p/chromium/issues/detail?id=1474047
• Tests
  • Create roles-minimum.tentative.html web-platform-tests/wpt#44934

---

Preview | Diff

[adampage]

I have no feedback of substance 😅, just a couple proofing suggestions.

[spectranaut]

This is an approval caveat remove the sentence fragment, at least!

[spectranaut]

Maybe it's time to open issues on the browsers with this change?

[cookiecrook]

I see a few problems with this and suggest we schedule a deep dive.

The first is that this doesn't seem to account for native-reserved roles, or roles that we can't yet or haven't yet mimicked with ARIA. For example, or … I think this change suggests UAs MUST map both to group, even though it wouldn't be logical to do so. Even if ARIA eventually adds a role for native date pickers, video is likely to remain separate for a while, because there isn't a good method to support the video API that goes along with it.

The second issue is that ARIA's concept of group requires a much more explicit and purposeful author decision, IMHO, than the related concept in the AX API... As a reminder, AXGroup predates ARIA's group by almost a decade, and is used as a generic container. ARIA's group, as I understand it, represents some explicit logical grouping, so I am not certain it's a good change to force promotion of something like

when the author may have added the relevant role and label to another nearby container. E.g.,

Now I have an extraneous, unlabeled group inside my main, where I hadn't before.

[scottaohara]

@cookiecrook thank you for the review.

per your two comments:

...that this doesn't seem to account for native-reserved roles...

it was definitely the intent to account for that, so happy to incorporate changes to make sure that's included / I'll have a think on other wording to make sure that's clear.

re:

so I am not certain it's a good change to force promotion of something like

when the author may have added the relevant role and label to another nearby container.

that's an interesting idea. Though it makes me think back to past projects I worked on - one being a website builder where there were blocks of editable areas within predefined templates. So a main could have 2 or 3 contenteditable divs within it. Something to think about...

[cookiecrook]

per your two comments:

FYI Our comments crossed when I added a third to the list: contenteditable="false" or contenteditable="plaintext-only" override cascades on sub-sections may not need explicit roles... example above.

[scottaohara]

@cookiecrook we had talked about false not triggering a need for a minimum role. In the comments for contenteditable it indicates the minimum role only changes if the value is true. I have a comment in the source code to mention what happens with plaintext-only when that is added to the standard.

[spectranaut]

We had a deep dive this morning, it seems the main conclusions were:

• to remove the minimum role of group from contenteditable, as there is already a history of browsers/ATs attemping to make contenteditable work and we can't be sure if making those elements "group" would make things better or worse.
• there was agreement that the minimum role of contenteditable=plaintextonly could be "textbox"
• there was quite a bit of discussion about whether or not "minimum role" was the right language (instead of "implicit role for this attribute", opponents say the "implicit role" has a specific meaning related to the tagname so sound cause confusion). @mcking65, who thought it was unclear, committed to reviewing this PR in order to understand.
• It was decided not to use the language "fallback" because that implies that authors shouldn't rely on the minimum role, when in fact, the aim is to allow them to rely on the minimum role. If adding an attribute makes the semantic meaning of the element clear, then you shouldn't need to also add a role. Therefore validators will have to be updated to not report errors when these attributes are used on elements with no implicit or explicit roles.

[cookiecrook]

It was decided not to use the language "fallback"

Also that term had been used to describe the fallback roles such as role="switch checkbox" where checkbox was the ARIA 1.0 fallback role if the engine did not yet support the ARIA 1.1 switch role.

[scottaohara]

had a call with aaron and james today
agreed that accesskey can be dropped from this
no disagreement about introducing the concept
still not 100% on tabindex, but not against it - it's just a change that may create other issues to review (re: naming divs with title which are now groups because of tabindex=0)
can this be merged with the other work i'm doing for contextual role (proably?)

i need to work though if this should be merged, or can be revised into contextual role. i'll work on that soon

[aleventhal]

@scottaohara what's the update on this? Which attributes should we start with?

[scottaohara]

OK, finally got back to this and resolved all the merge conflicts. The PR is much simpler to review now in the diff mode.

This now adds the minimum role concept, and to start we're indicating this will occur for the draggable and autofocus attributes.

tabindex is presently not part of this PR (well, it's commented out for further investigation/discussion).

I plan on some editorial revising of this section with the contextual role PR (#484) - but need this to merge first before I work on that anymore.

I think this finalizes the outstanding conversations for this PR (with any potential addition of tabindex being it's own topic for the future)

cc @aleventhal @cookiecrook @jcsteh @benbeaudry

[aleventhal]

Still LGTM.

[benbeaudry]

+1!

[scottaohara]

merged via w3c/aria#2220