Generalize AccessibilityRole/AriaAttributes IDL

[domenic]

This generalizes the AccessibilityRole/AriaAttributes IDL mixins to allow them to have different behaviors per host interface. For Element, they have the reflection behavior specified, but e.g. for ElementInternals, HTML can use this framework to define different behavior.

In the process, this consolidates the two mixins into one ("AccessibilityMixin"), since this makes it easier to define their behavior uniformly, and consumers should generally not mix in one without the other.

/cc @alice @tkent-google.

My next step is to work on a counterpart pull request on the HTML side, to prototype how we would use this more general framework for ElementInternals to allow custom elements to have native roles/states/properties. It's probably not worth reviewing this PR in too much depth before that is ready, in case I find out that something needs to be tweaked.

---

Preview | Diff

[caridy]

@domenic thanks a lot for putting the time to get this ready! wonderful stuff that we are eager to try out.

[jnurthen]

@domenic based on your comment

It's probably not worth reviewing this PR in too much depth before that is ready, in case I find out that something needs to be tweaked.

are we to assume this is not ready to consider merging? If so do you mind if I put a WIP label on it?

In order to consider merging in the future we'll need to the RFC2119 format changed to caps.

Once merged into our Editor's draft we'll need tests before we can add into a WD - the IDL section previously had tests supplied from outside the ARIA WG - would it be possible for this to happen with this change too?

[domenic]

Sorry for the delay in response! Please do put a WIP label on it. I'll fix the caps RFC2119 keyword.

As a status update, I did the HTML pull request in whatwg/html#4658, and this pull request seems pretty good. So at least technically I think it's ready to go, but it should still be marked as WIP until we have rough consensus on the HTML pull request.

For tests, I think this PR doesn't actually introduce any new normative requirements that would need testing. Instead, it restructures the existing normative requirements in a way that allows their underlying infrastructure to be reused by HTML, in whatwg/html#4658. And whatwg/html#4658 will definitely get tests before landing, as a required part of the WHATWG working mode; my team at Chrome is happy to commit to that.

[cookiecrook]

I have concerns about combining AccessibilityRole and AriaAttributes into a single AccessibilityMixin

1. Role is not used solely in the context of ARIA.
2. ARIA attributes to not represent the entirety of mixins that might be used to augment Accessibility, so this naming convention seems to limit the ability to mixin more Accessibility-specific extensions later. For example, some of the items in AOM would not necessarily need to be lock-step with an ARIA update.

My preference would be to change this back to two separate mixins: AccessibilityRole and AriaAttributes.

[domenic]

@cookiecrook thanks for raising these concerns. I'd like to try to understand them better. Note that how these mixins are structured, and their name, is largely an editorial detail, and is not observable to web developers.

The reason I merged these is because the specification infrastructure operates in the exact same way on both role and on the attributes. In particular, the "get/set the accessibility IDL attribute" infrastructure, and the steps for the getters/setters for each IDL attribute. See the spec text below the IDL block in this pull request, and in the corresponding HTML pull request.

We could certainly re-separate them. However, this would just make all the specification text more awkward: we would need to have separate cases for role, which are largely copying-and-pasting the spec text for the other accessibility attributes. Given the fact that these mixins are unobservable, I thus thought it would be better to keep them together.

To your points,

Role is not used solely in the context of ARIA.

This is definitely true, but I'm not sure how it relates to the PR.

Perhaps you are anticipating in the future mixing AccessibiltyRole into places that don't get AriaAttributes mixed in? Do you have any concrete examples in mind? Note that we can always re-separate them in the future, with no observable consequences and just a bit more work for spec writers.

ARIA attributes to not represent the entirety of mixins that might be used to augment Accessibility, so this naming convention seems to limit the ability to mixin more Accessibility-specific extensions later. For example, some of the items in AOM would not necessarily need to be lock-step with an ARIA update.

This isn't the intention. As with any Web IDL mixin, the only actual constraints on augmenting the AccessibilityMixin are that doing so automatically augments its mixin targets. Currently those mixin targets are ElementInternals and Element.

AOM could add lots of functionality, which could target ElementInternals, Element, or both. The intention of this mixin is for things that end up targeting both. If AOM wanted to add functionality that targeted only one of them, there are definitely ways to do that.

If your concern is mostly about naming, I would be happy with any naming convention. Keeping in mind that the name is only observable to spec authors, we could call it AccessibilityElementOrElementInternals (similar to the DocumentOrShadowRoot or WindowOrWorkerGlobalScope mixins). Or maybe RoleAndARIAAttributesElementOrElementInternals, if you think in the future we might want to add other accessibility-related mixins that apply to both Element and ElementInternals. (Although in that case we probably should just expand this mixin?) Let me know!

[cookiecrook]

Thanks. Based on that explanation, I think it'd be okay to keep them together and just rename AccessibilityMixin to AriaMixin.

Does that work for you?

[domenic]

For sure! I've renamed it and will make the corresponding HTML-side changes now. (I used capitalized ARIAMixin instead of Pascal-case AriaMixin per https://w3ctag.github.io/design-principles/#casing-rules.)

[annevk]

Does it make sense to talk about content attributes here given that they're not content attributes for all consumers? From the wording in the HTML PR it seems these are really "state or properties" (that happen to match the casing conventions for content attributes and are used as such when this mixin is included by elements).

[domenic]

I am mostly just reflecting preexisting text (where the previous version of this table said "Reflected ARIA Content Attributes"), but I agree with your sentiment so I'll change it.

[domenic]

Hmm, nope. Upon going to make the edit, I realized that because "role" is included in this table, "content attribute" is now the best super-category. ARIA defines a number of content attributes, namely role, a bunch of states, and a bunch of properties. So I think this is reasonable as-is.

There is a bigger editorial meta-issue about how ARIA seems to be largely defined in terms of content attributes instead of having underlying models, but let's not get in to that here :).

[domenic]

ARIA editors, I think this is ready to merge. Tests are available for the new stuff that this enables (which is specced in whatwg/html#4658) at https://github.com/web-platform-tests/wpt/blob/master/custom-elements/form-associated/ElementInternals-accessibility.html.

Also, I realized I didn't make this super clear before: from the ARIA spec's perspective this is a refactoring without observable consequences. But it does support infrastructure like whatwg/html#4658.

[domenic]

Ping to ARIA editors. I've rebased this on master, and the corresponding HTML side pull request in whatwg/html#4658 for adding accessibility semantics to custom elements is blocked on this.

[carmacleod]

Thanks for the ping, @domenic - it's looking good!
A couple of little things:

1. The role link in the correspondence table is broken, because role is defined in a completely different document.
   Probably the nicest fix is to just change <pref>role</pref> to: <a href="#introroles">role</a>.

2. Wondering if we need an "Editor's Note" about the missing element reflection attributes in the mixin and the correspondence table? Here's an example Editor's Note in combobox and the corresponding markup on index.html#L2098:

   <p class="ednote" title="Major Changes to combobox role in ARIA 1.2">
   The Guidance for <rref>combobox</rref> has changed significantly ...
   </p>
   

Other than those, I think this is good to merge!

[domenic]

The role link in the correspondence table is broken, because role is defined in a completely different document.

Fixed!

Wondering if we need an "Editor's Note" about the missing element reflection attributes in the mixin and the correspondence table?

Although that makes some sense to me, I'm not sure how it relates to this PR; this PR just consolidates what was previously two mixins (one for role and one for everything else) into one.

[carmacleod]

+1

@domenic

Wondering if we need an "Editor's Note" about the missing element reflection attributes in the mixin and the correspondence table?

Although that makes some sense to me, I'm not sure how it relates to this PR; this PR just consolidates what was previously two mixins (one for role and one for everything else) into one.

Good point. I'll open a new issue.

[domenic]

Thanks for all your help! Please feel free to merge at your convenience :).

[domenic]

Gentle ping! I'd love to get this and the corresponding HTML spec pull request merged.