Define how custom elements are exposed to AT

[annevk]

w3c/accname#170 is a good first step by @nolanlawson regarding the ARIAMixin mixin, but ElementInternals also includes ARIAMixin and as such we need to define how that ends up mapping to AT as well.

https://html.spec.whatwg.org/#accessibility-semantics

Note that this is not straightforward as these are essentially "native semantics" that can then be overridden by actual content attributes on the custom element.

There's also still some problems to be sorted here on the HTML side (probably by @mrego and I with help from @domenic), but I thought I'd start the conversation about this now as this feature has been in HTML for a while.

[jnurthen]

Discussed in AOM meeting and decided this was probably more appropriate to be filed on core-aam

[domenic]

https://html.spec.whatwg.org/#wai-aria is intended to answer this question. I'm not sure there's more to do here, but maybe I'm misunderstanding.

[annevk]

@domenic how does that work for element-reflecting attributes?

[domenic]

Ah, yeah, it doesn't particularly. I believe both base ARIA and that part of HTML are vague about how element-to-element relations are exposed to AT.

[annevk]

WAI-ARIA doesn't really define user agent requirements as far as I can tell. Just requirements on developers. There is an issue for that too as it doesn't acknowledge the empty string: w3c/aria#1842.

I believe the idea is that core-cam would define the user agent requirements.

@domenic looking at that section and the general idea that the content attribute holds the semantics, shouldn't attr-associated element(s) use the reflected content attribute name for attr instead of the reflected IDL attribute's identifier? I think that would make some things easier. E.g., we could check if such a field exists and then return that instead, for instance, without having to map from IDL attribute to content attribute again.

[domenic]

looking at that section and the general idea that the content attribute holds the semantics, shouldn't attr-associated element(s) use the reflected content attribute name for attr instead of the reflected IDL attribute's identifier?

I don't understand what this is asking. The attr-associated element(s) definitions do use the reflected content attribute name, via how they call "get the content attribute". They don't use the reflected IDL attribute's identifier anywhere, as far as I can tell.

without having to map from IDL attribute to content attribute again.

I don't see where this is done, either in the definition of attr-associated element(s) or elsewhere.

[annevk]

@domenic what's the value of attr in attr-associated element(s) in your mind? I thought it was the IDL attribute identifier. I think it should be the reflected content attribute name.

[domenic]

Ah, yeah, I understand now. It could go either way depending on what's convenient, I guess. I could see how maybe the content attribute name would be convenient, but it's not obvious without a written-out algorithm for the attr-association processing model.

[annevk]

Well, if we start with https://html.spec.whatwg.org/#wai-aria, how would we modify that?

1. We would need to get from the custom element to ElementInternals. We could change attached internals to hold null or an ElementInternals object. Solved.
2. Then, if that is non-null we'd want to check that the ElementInternals object holds an attr-associated element(s) where attr is the IDL attribute identifier corresponding to the attribute name stateOrProperty, right?
   1. I'm not sure how we feel about checking whether an internal slot exists. If we don't like that we'd first have to check if stateOrProperty is element(s) backed I suppose, but I don't see any downside with an existence check so I hope we can go for that.
   2. If instead of finding the IDL attribute identifier we could use stateOrProperty directly that would be much nicer. Other places that use this infrastructure don't care much I think as they are one-offs and don't really need generic infrastructure.

Then ARIA gets one of these values for a given stateOrProperty:

• A string.
• An element.
• An element list.
• The default value for stateOrProperty.

Does that help?

[domenic]

I don't see any downside with an existence check so I hope we can go for that.

Yes, seems fine.

If instead of finding the IDL attribute identifier we could use stateOrProperty directly that would be much nicer.

Cool, yeah, I see it now.

[annevk]

I consider the HTML side to be ready now. @spectranaut let me know if you or the other editors have questions about this.