Html: Proposal - add aria property to the HTMLElement (just like dataset)

[Konrud]

My proposal is actually very simple, reflect aria-* attributes on HTMLElement with a property like with dataset.
It will help a lot, especially when developers need to add aria-* attributes
to the HTML via script and then toggle them afterwards.

Example:

// setting aria attribute
button.aria.hidden = true;
// getting aria attribute
var isAriaHidden = button.aria.hidden;

[domenic]

I've talked about this with @alice previously.

I don't think we should add another dataset-like object for something that isn't open-ended like data-* attributes are. (In fact we should never add another such object at all, as that design was pretty bad for a variety of reasons.)

But I'm in favor of adding appropriate ARIA reflection properties for all the ARIA attributes. So e.g. it'd be

button.ariaHidden = "true";
const isAriaHidden = button.ariaHidden === "true";

Last I heard @alice was working on a proposal for that.

[annevk]

cc @whatwg/a11y

[patrickhlauke]

i believe the use case would be covered more appropriately by the proposed Accessibility Object Model (AOM) https://github.com/WICG/aom (specifically phase 4 https://github.com/WICG/aom/blob/gh-pages/explainer.md#phase-4-full-introspection-of-an-accessibility-tree which unfortunately is not likely to be fully/specced and implemented any time soon). As such, I don't think it would make sense to embark on a parallel effort here. /cc @alice

[Konrud]

@domenic I'm happy to hear that you agreed upon this, but don't you think that if we were doing it the way you proposed it would clutter the HTMLElement as it is? I mean if we would use some prefix as a namespace it would be more preferred and less cluttered way?

[Konrud]

@patrickhlauke I think if we were did this as soon as possible we would encourage more developers to use it in the production as it would be more explicit and friendly for them, instead of using getAttribute / setAttribute each time you want to toggle some aria-* attribute on the HTMLElement. IMHO, the simplier it will be the more willingly developers would use it.

[patrickhlauke]

reflecting the ARIA attributes would be ok (as suggested by @domenic) provided it's non-controversial for browsers to do. my comment was more about the dataset-like approach.

[KrusaderCell]

It can definitely help and what more important encourage web developers to use aria attributes in their projects. I do think that proposed syntax (e.g. using element.aria.*) will be more appropriate and easy to remember. I mean, we already have aria-* so why not use it as it is in HTMLElement property instead of clutter (as @konrud said) the HTMLElement with all aria properties that exist and will be add in the future.
Currently, I'm working on project where we're using aria attributes very profusely, so each time I want to toggle or set them I need to use setAttribute which is very tedious think to do. So if this will be change to something more convenient to use, developers and users will all be in win.

[patrickhlauke]

AOM phase 1 (which is at least spec'd and being implemented) may actually cover the getting and setting already https://wicg.github.io/aom/spec/#properties - so again likely there's no need to reinvent a second wheel here (even with regards to simply reflecting attributes)?

[patrickhlauke]

related: https://tink.uk/playing-with-the-accessibility-object-model-aom/

We could then start adding semantics to the DOM node for the span in the usual way:

button.setAttribute('role', 'button');
button.setAttribute('aria-expanded', false);
But instead we can create a reference to the accessible node that corresponds to the DOM node for the span element, and add the semantics straight into the accessibility tree:

button.accessibleNode.role = "button";
button.accessibleNode.expanded = false;
The AOM uses the same set of roles as ARIA. The AOM Phase 1 spec also includes a table that maps AOM properties to their corresponding ARIA attributes (the expanded property corresponds to the aria-expanded attribute for example).

[domenic]

There are currently pretty extensive discussions about the relationship between AOM and reflection which landed us on the proposal to just reflect as normal and remove the reflection from AOM. We've had further, as-yet-inconclusive discussions about how this impacts further phases of AOM, but it seems like AOM phase 1 is entirely subsumed by this proposal. See https://github.com/WICG/aom/issues/88 for more details.

Again, happy to treat aria-* attributes as first class and just reflect them like other attributes are.

[alice]

@patrickhlauke Right, as @domenic commented above, we were mooting whether this might be preferable to the current proposal for AOM phase 1.

Some initial experimentation by @robdodson suggests that the status quo for the relationship between AOM and ARIA leads to potential confusion and annoyance for developers:

• AOM taking precedence over ARIA means that developers would need to use AOM to be sure that their semantics are applied
• Moreover, custom widget authors in any framework will need to write boilerplate to respect ARIA if they want to support ARIA at all, if they are using AOM to set their default semantics.

The potential benefits of AOM phase 1 are, essentially:

1. Programmatic API instead of setAttribute()/getAttribute()
2. Being able to use element references for relationships - particularly useful when Shadow DOM is involved as IDREFs become unusable across Shadow DOM boundaries
3. Non-reflected semantics mean custom elements don't need to "sprout" ARIA attributes to set default semantics, and can look more like built in elements

The proposal being discussed here would address (1).

We could get (2) by building on top of that and creating a mechanism to allow using element references wherever an existing attribute requires an IDREF.

And I have some ideas for (3) that aren't really ready for prime time 😛

It would be great to get a sense for:

• what folks' sense of the priorities for the above set of benefits is;
• whether there are some other benefits/use cases I may have overlooked?

[marcysutton]

It would be great to get a sense for...what folks' sense of the priorities for the above set of benefits is; there are some other benefits/use cases I may have overlooked?

I'm in favor of the AOM proposal since it's building significant momentum towards a programmatic API for accessibility information. I was tempted upon reading this issue to think element.aria.* would be easier to follow, but then I re-read the naming appendix in the AOM explainer doc...and I think they're right that it could be confused with the ARIA spec, which doesn't cover all of the use cases for this API.

I'm keenly interested in parts of the AOM proposal that reduce developer confusion, as ARIA is already confusing to the average developer. Two-way reflection with validation would be nice to eliminate the "which one wins" question (and warn against invalid properties/attributes), but it seems to open cans of worms in regards to performance and necessary APIs for managing IDREFs and custom elements. Perhaps ARIA attributes should just take precedence, and require unsetting before using the AOM.

Throwing a warning to the console would be a good way to alert developers they did something wrong, IMO.

From Leonie:

I can understand the appeal of two way reflection now, but as the AOM and ARIA diverge, my hunch is that developers will favour the AOM over ARIA because it'll be more feature rich/capable. So keepin the separation clean from the outset would make things easier on developers in the long run I think.

Perhaps the best practice could be if you're going to use the AOM, don't use ARIA attributes in HTML (or unset them first). Overriding ARIA roles is definitely frowned upon, but it would still be nice to have the mechanism in the scenario where you have to clean up after third-party code you don't control.

[domenic]

open cans of worms in regards to performance and necessary APIs for managing IDREFs and custom elements.

I don't quite understand this, or at least the first two parts. What performance concerns do you have?

IDREF-replacement APIs are pretty simple; we used to have one in the spec for a feature only Firefox ever implemented (contextmenu=""), and @alice and I brainstormed the outline of one in the margins of some document a while back. We shouldn't hold ourselves back because of that; we should just do it.

I agree making this work for custom elements (@alice's (3)) takes a bit more work, but it can build on top of it.

[marcysutton]

I don't quite understand this, or at least the first two parts. What performance concerns do you have?

I gathered as much from reading the discussion around reflection, in particular this comment from @cookiecrook in which he mentioned selectors referencing ARIA might cause repaints: https://github.com/WICG/aom/issues/60#issuecomment-286956084

[alice]

To clarify a couple of points:

• The current AOM phase 1 spec does not include any kind of validation. This was discussed at length and eventually we agreed to drop it.
• The current AOM phase 1 spec explicitly does not include any properties beyond the current ARIA set.
• Domenic's proposal in this thread has been discussed by the AOM spec authors already, and we are still weighing the pros and cons with our existing goals, and particularly how it would affect later phases.

Per the existing AOM phase 1 spec, if we take it as standing alone, I think the only benefit over my and Domenic's proposals in this thread are being able to set non-reflected semantics.

James and Marcy have suggested that _may_ be a performance win as it does not involve mutating the DOM.

However, typically when the semantics change, the DOM will mutate anyway (since there will be an associated UI change in the vast majority of cases which is being reflected in the changing semantics). Also, I believe there would be no performance implications of updating an ARIA attribute unless it was used in a selector.

That being the case, I really am curious what concrete benefits there may be to the current AOM phase 1 proposal beyond the three I listed earlier:

1. Programmatic API instead of setAttribute()/getAttribute()
2. Being able to use element references for relationships - particularly useful when Shadow DOM is involved as IDREFs become unusable across Shadow DOM boundaries, but also has a benefit of not needing to constantly generate unique IDs
3. Non-reflected semantics mean custom elements don't need to "sprout" ARIA attributes to set default semantics, and can look more like built in elements[*].

In particular, I'm not clear on how the AOM phase 1 spec helps to reduce developer confusion - I would love to understand this! My feeling was that because it adds another API surface, it could only serve to increase developer confusion.

---

[] Another benefit of this is that custom element authors don't need to take extra care to avoid stomping on embedders' ARIA, but it is *possible, if unwieldy, to do this with ARIA alone. I do believe there are benefits to non-reflected semantics, but a lot is possible without them if we have the other the other two benefits.

[notwaldorf]

One problem with automatically reflecting all aria attributes as properties is that there is no guarantee you won't stomp on _current_ custom element implementations. For example, paper-input has an _ariaLabelledBy property -- it has a leading _ by convention (and not one that has to do with the fact that there's an aria-labelledBy attribute), so it could've very well not had it, and it is conceivable that in a different custom element, ariaLabelledBy could be a function that returns some element to use for labelling. Stomping over that would be pretty weird.

This generic fear that the platform is at some point going to introduce properties that will break custom elements was recently raised on a React thread (@robdodson has more info on that), and I think given that aria has a lot of properties, that fear is super relevant here.

[domenic]

Built-in properties don't stomp over user-defined ones; it's the opposite :). So there should be no impact on if people are already using such names in their custom elements.

[robdodson]

This generic fear that the platform is at some point going to introduce properties that will break custom elements was recently raised on a React thread (@robdodson has more info on that), and I think given that aria has a lot of properties, that fear is super relevant here.

I think React is concerned about new global attributes, not properties. As Domenic mentioned, your element's properties will shadow any properties added to HTMLElement so your element will continue to work. Attributes, on the other hand, will not have anything to shadow.

[notwaldorf]

Oh, Rob tells me your custom element properties will stomp over the native ones. Well then.