updates per discussion in #1598

[jnurthen]

resolves #1598

---

Diff

[jnurthen]

@domenic @annevk
Can folks please review this and let us know if this will work.

[domenic]

So I think the reflection text looks good. However it exposes a confusion that makes the spec kind of hard to understand, which is that you talk a lot about "ARIA enumerated attributes". But these do not match HTML's notion of enumerated attribute.

This is most stark in how the new reflection text says

If a reflecting IDL attribute is a nullable DOMString attribute whose content attribute is not an enumerated attribute

but then apparently the goal is to apply this reflection algorithm to the various ARIA attributes, per

When the ARIA attribute definition includes a table enumerating the attribute's allowed values, that attribute is a nullable enumerated attribute

Another confusing issue is that "nullable enumerated attribute" is confusing content attributes and IDL attributes. IDL attributes can be nullable, and content attributes can be enumerated, but which does "nullable enumerated" apply to?

It would be best to remove all mention of "enumerated attribute" and "nullable enumerated attribute" from this document, I think. Maybe replace it with a new term like "multi-value ARIA attribute"?

[domenic]

Stated from another perspective: HTML already defines reflection algorithms for nullable IDL attributes that reflect enumerated content attributes. They perform validation/canonicalization.

You want to use a different algorithm that does not perform validation/canonicalization. And you want to use a nullable IDL attribute. Thus, your content attributes must not be enumerated attributes; they must be some new category of thing (which I proposed calling "multi-value ARIA attribute").

[domenic]

If I search https://pr-preview.s3.amazonaws.com/w3c/aria/pull/1633.html for "enumerated attribute" 18 instances remain. I think all of them need to be changed...

[domenic]

Love it!

[cookiecrook]

I see why you moved the "Multi-Value" section down to an H3 sub-section, but should this higher-level section get a new IDREF? (No strong preference. Approving as-is.)