ARIA custom element API

[hayatoito]

Title: [Accessibility]: Custom element should allow declaration of default accessibility features, such as role and other ARIA attributes. (bugzilla: 20466)

Migrated from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20466

---

comment: 0
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20466#c0
James Craig wrote on 2012-12-20 20:19:01 +0000.

Probably needs to be done declaratively on the container rather than in the ShadowDOM content template, as this should be available in the DOM.

…

Example:
$ new AlertDialog().outerHTML

…

---

comment: 1
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20466#c1
Dominic Cooney wrote on 2012-12-21 06:59:49 +0000.

I think this is a good idea.

Does it make sense to have a default set of attributes and values, and simply piggyback accessibility defaults on that mechanism?

---

comment: 2
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20466#c2
Dominic Cooney wrote on 2013-06-06 02:13:02 +0000.

I think that this has been languishing under the wrong bug--this is a Custom Elements spec question.

---

comment: 3
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20466#c3
Dimitri Glazkov wrote on 2013-10-08 02:38:40 +0000.

James, since there is no declarative syntax in this iteration (level?) of the spec, I had assumed that it's not in scope, at least for the moment.

FWIW, I certainly do not want to build something that magically sets attributes on an element at the construction time.

Dominic (the Accessibility one), I remember you talking about this for custom elements or shadow trees? I thought you guys had a good reasonable solution?

I would really like to move default ARIA roles problem over to the next iteration and get the spec to LC.

---

comment: 4
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20466#c4
Dominic Cooney wrote on 2013-10-08 02:44:39 +0000.

While I'm NOT the accessibility Dominic, I believe the current thinking is:

• UA can respond to ARIA roles inside Shadow DOM. Component authors who want to be "like native" can use this approach.
• UA responds to ARIA roles on Custom Elements like any element. Authors that want to tweak ARIA roles can use this approach.
• There's an issue with the default value of tabindex, but it is related to Shadow DOM, not Custom Elements.

So I don't think there's anything for the Custom Elements spec here. This bug should be closed.

---

comment: 5
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20466#c5
James Craig wrote on 2013-10-08 03:36:27 +0000.

(In reply to Dominic Cooney from comment #4)

While I'm NOT the accessibility Dominic, I believe the current thinking is:

• UA can respond to ARIA roles inside Shadow DOM. Component authors who want
  to be "like native" can use this approach.

There are a few issues with that approach.

1. The end result would be an element with a role inside the generic parent element. If the custom element inherits its role from a native one (like the dialog example) there is no way to override it, except to tell all authors to explicitly use role="presentation" on the custom element.
2. I don't believe focus management for shadow DOM components is fully specified, which I hope to raise as an issue on that spec, but is nevertheless a blocker for this suggestion.

• UA responds to ARIA roles on Custom Elements like any element. Authors
  that want to tweak ARIA roles can use this approach.

This bug was about letting the custom element define its default role so the author would not have to do this.

---

comment: 6
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20466#c6
Dominic Cooney wrote on 2013-10-08 03:57:50 +0000.

(In reply to James Craig from comment #5)

(In reply to Dominic Cooney from comment #4)

While I'm NOT the accessibility Dominic, I believe the current thinking is:

• UA can respond to ARIA roles inside Shadow DOM. Component authors who want
  to be "like native" can use this approach.

There are a few issues with that approach.

1. The end result would be an element with a role inside the generic parent
   element. If the custom element inherits its role from a native one (like the
   dialog example) there is no way to override it, except to tell all authors
   to explicitly use role="presentation" on the custom element.

Is that a problem?

The Custom Element can also set the role attribute in the created callback, without adding additional machinery to the spec for this.

1. I don't believe focus management for shadow DOM components is fully
   specified, which I hope to raise as an issue on that spec, but is
   nevertheless a blocker for this suggestion.

I think focus management in Shadow DOM is unrelated to Custom Elements.

• UA responds to ARIA roles on Custom Elements like any element. Authors
  that want to tweak ARIA roles can use this approach.

This bug was about letting the custom element define its default role so the
author would not have to do this.

This was commentary that authors can do this if they want. Note: "can" not "have to".

---

comment: 7
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20466#c7
James Craig wrote on 2013-10-08 06:40:59 +0000.

(In reply to Dominic Cooney from comment #6)

(In reply to James Craig from comment #5)

(In reply to Dominic Cooney from comment #4)

While I'm NOT the accessibility Dominic, I believe the current thinking is:

• UA can respond to ARIA roles inside Shadow DOM. Component authors who want
  to be "like native" can use this approach.

There are a few issues with that approach.

1. The end result would be an element with a role inside the generic parent
   element. If the custom element inherits its role from a native one (like the
   dialog example) there is no way to override it, except to tell all authors
   to explicitly use role="presentation" on the custom element.

Is that a problem?

Sorry, each instance is unique and I did not clearly describe the scenario. Imagine an the site's lead engineers set up a set of custom element for non-technical content providers to use.

The implication was that it some cases, it would be necessary to override the role, and therefore forcing each user of the tag to include role attribute and other related markup would be unacceptable, flaky, and defeat some of the purpose of using a custom element that should be including all of its own semantics and functionality.

The Custom Element can also set the role attribute in the created callback,
without adding additional machinery to the spec for this.

Perhaps I'm misunderstanding. Are you saying my example would work as-is?

…

Or are you saying the element author should use something like this.setAttribute('role', 'alertdialog'); in the custom element's constructor?

Or something else entirely? Thanks for clarifying. If this type of thing can indeed already be done, then all I'd request is an editorial note or example in the spec stating how that can and should be achieved.

1. I don't believe focus management for shadow DOM components is fully
   specified, which I hope to raise as an issue on that spec, but is
   nevertheless a blocker for this suggestion.

I think focus management in Shadow DOM is unrelated to Custom Elements.

I agree, but it's valid to point out why your suggestion of using the shadow DOM would not yet work in some cases, and therefore should not be used as justification for dismissing this bug.

[annevk]

While this could be useful, this requires low-level accessibility APIs to be created. I don't think that's really in the realm of defining custom elements per se.

[domenic]

I think it might be. It's an open question whether those low-level a11y APIs would be tied to custom elements, or something you could install on any element. I tend to lean toward the former since it makes it clearer how to explain native elements, without opening up weird possibilities like using script to override the default a11y behavior for all <button>s.

[annevk]

As with the defined promise, that would argue for something between HTMLElement and the custom element class, maybe?

[domenic]

I don't really understand what that means.

I was envisioning adding things like role to ElementRegistrationOptions plus getAccessibleName() and getAccessibleDescription() to the list of custom element callbacks. (They'd be a bit different than other callbacks since you never queue them; but you do perform the store-at-registration-time, call-when-needed dance.)

[annevk]

How would you change state?

[domenic]

I am not sure how to deal with accessible states and properties yet, but a callback might be sufficient for the cases where the AT "pulls" information from the element. I think there are cases where the element "pushes" information to the AT (announcements of important state changes) which might not be implementable that way.

[annevk]

Yeah, I thought that for those we'd need attribute setters / methods and those need to be made available to the class somehow.

[domenic]

Yeah, it might be true. But I think a lot of it would be done through the custom elements mechanism.

[annevk]

Right, but how would we do aria-checked, for instance? It seems important to consider the full picture here. Either, like with a potential defined promise, we do some kind of prototype munging, maybe based on the passed role value, or we have some kind of HTMLCustomElement interface inbetween.

[domenic]

I don't know how we'd do that yet. I don't think it would require either of those two things, though, and I don't understand why you think defined would either. (defined is just window.customElements.whenDefined("x-tag") or similar.)

[annevk]

I thought defined would be a property since it's state of the element. Observing state is usually not an external API (e.g., once we add <img>.loaded and friends). If not on the prototype, where else could we make these available? I guess you're thinking of some other external API that takes an instance and new state? Hmm.

[domenic]

No, as explained in #427 (comment), it doesn't make sense for it to be a property.

[annevk]

It only doesn't make sense if you don't introduce a CustomElement baseclass.

[domenic]

It still doesn't make sense: by the time you have the constructor to check MyElement.defined, the element is already defined.

[annevk]

I guess it would be a PotentialCustomElement then or some such. I dunno, it seems like there's some amount of internal state that's fairly specific to custom elements.

[domenic]

I suppose that's a potential proposal. It seems late in the game to bring it up, but if you'd like to bring it up in a new issue that seems reasonable.

[annevk]

I guess it doesn't actually work due to type extensions. Which means also that your suggestion of restricting this to custom elements might not quite work, given that custom elements are effectively everywhere type extensions are.

[annevk]

Anything we do here will need to integrate with https://github.com/wicg/aom/ somehow.

[rniwa]

The latest plan invokes adding ARIA related properties on ShadowRoot as well as Element.

[annevk]

There is interest here, but only as part of AOM. We'll keep this issue open so it's tracked in this repository.

[domenic]

There may be eventual work in this spec to add a shorthand, of the same style as was discussed for stylesheets, when defining the custom element. But we'd like to figure that pattern out first with stylesheets before trying it here.

[annevk]

Based on further discussion, this can be closed. We'll leave this entirely to AOM. It'll expose the appropriate ShadowRoot API.