Generalize AccessibilityRole/AriaAttributes IDL #984

domenic · 2019-05-22T21:25:14Z

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

index.html

caridy · 2019-05-23T22:19:08Z

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

jnurthen · 2019-05-30T22:51:07Z

@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 · 2019-06-14T19:07:06Z

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 · 2019-08-21T00:21:24Z

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

Role is not used solely in the context of ARIA.
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 · 2019-08-21T18:34:24Z

@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 · 2019-08-21T23:18:54Z

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 · 2019-08-22T18:21:17Z

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 · 2019-09-25T11:23:49Z

index.html

+
+	<section id="accessibilityroleandproperties-correspondence" class="normative" data-dfn-for="ARIAMixin" data-link-for="ARIAMixin">
+		<h2>ARIA Attribute Correspondence</h2>
+		<p>The following table provides a correspondence between IDL attribute names and content attribute names, for use by <code>ARIAMixin</code>.</p>


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).

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.

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 · 2019-10-31T19:35:44Z

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.

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 ("ARIAMixin"), since this makes it easier to define their behavior uniformly, and consumers should generally not mix in one without the other.

domenic · 2020-08-28T19:33:13Z

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 · 2020-08-29T13:27:15Z

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

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>.
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 · 2020-09-01T20:53:06Z

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 · 2020-09-02T16:25:41Z

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

index.html

domenic · 2020-09-18T15:31:27Z

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

* Generalize AccessibilityRole/AriaAttributes IDL 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 ("ARIAMixin"), since this makes it easier to define their behavior uniformly, and consumers should generally not mix in one without the other.

carmacleod reviewed May 22, 2019

View reviewed changes

index.html Outdated Show resolved Hide resolved

domenic mentioned this pull request May 23, 2019

Allow setting default accessibility semantics for custom elements whatwg/html#4658

Merged

3 tasks

caridy mentioned this pull request May 23, 2019

Update polyfill for AccessibilityMixin (former aria props) to match spec salesforce/lwc#1259

Open

jnurthen added the WIP label Jun 14, 2019

rakina mentioned this pull request Aug 7, 2019

Default accessibility semantics for custom elements w3ctag/design-reviews#401

Closed

3 tasks

domenic force-pushed the generalize-idl branch from 83a2438 to fa7ce86 Compare August 22, 2019 18:20

annevk reviewed Sep 25, 2019

View reviewed changes

scottaohara mentioned this pull request Oct 4, 2019

update custom element w3c/html-aria#180

Closed

jnurthen added this to In progress in IDL Nov 13, 2019

domenic force-pushed the generalize-idl branch from fa7ce86 to f9b2ab2 Compare August 28, 2020 19:32

jnurthen requested a review from cookiecrook August 28, 2020 20:11

Fix role link

f10348b

jnurthen added Agenda and removed WIP labels Sep 1, 2020

carmacleod approved these changes Sep 2, 2020

View reviewed changes

carmacleod mentioned this pull request Sep 2, 2020

Add "Editor's Note" about missing element reflection attributes #1318

Closed

Last-minute rename per HTML spec feedback

c1949bd

cookiecrook self-assigned this Sep 3, 2020

cookiecrook added this to the ARIA 1.3 milestone Sep 3, 2020

carmacleod reviewed Sep 4, 2020

View reviewed changes

index.html Outdated Show resolved Hide resolved

takes -> take

70dcd60

jnurthen merged commit 02fee23 into w3c:master Sep 18, 2020

IDL automation moved this from In progress to Done Sep 18, 2020

carmacleod mentioned this pull request Sep 19, 2020

updates to custom elements w3c/html-aria#210

Merged

saschanaz mentioned this pull request Aug 27, 2021

ARIAMixin properties should be nullable? microsoft/TypeScript-DOM-lib-generator#1119

Closed

pkra mentioned this pull request Jan 11, 2022

FPWD of ARIA 1.3 #1331

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Generalize AccessibilityRole/AriaAttributes IDL #984

Generalize AccessibilityRole/AriaAttributes IDL #984

domenic commented May 22, 2019 •

edited by pr-preview bot

caridy commented May 23, 2019

jnurthen commented May 30, 2019

domenic commented Jun 14, 2019

cookiecrook commented Aug 21, 2019

domenic commented Aug 21, 2019

cookiecrook commented Aug 21, 2019 •

edited

domenic commented Aug 22, 2019

annevk Sep 25, 2019

domenic Oct 18, 2019

domenic Oct 18, 2019

domenic commented Oct 31, 2019

domenic commented Aug 28, 2020

carmacleod commented Aug 29, 2020

domenic commented Sep 1, 2020

carmacleod left a comment

domenic commented Sep 2, 2020

domenic commented Sep 18, 2020

Generalize AccessibilityRole/AriaAttributes IDL #984

Generalize AccessibilityRole/AriaAttributes IDL #984

Conversation

domenic commented May 22, 2019 • edited by pr-preview bot

caridy commented May 23, 2019

jnurthen commented May 30, 2019

domenic commented Jun 14, 2019

cookiecrook commented Aug 21, 2019

domenic commented Aug 21, 2019

cookiecrook commented Aug 21, 2019 • edited

domenic commented Aug 22, 2019

annevk Sep 25, 2019

Choose a reason for hiding this comment

domenic Oct 18, 2019

Choose a reason for hiding this comment

domenic Oct 18, 2019

Choose a reason for hiding this comment

domenic commented Oct 31, 2019

domenic commented Aug 28, 2020

carmacleod commented Aug 29, 2020

domenic commented Sep 1, 2020

carmacleod left a comment

Choose a reason for hiding this comment

domenic commented Sep 2, 2020

domenic commented Sep 18, 2020

domenic commented May 22, 2019 •

edited by pr-preview bot

cookiecrook commented Aug 21, 2019 •

edited