ARIA attribute reflection uses DOMString? but they are not enumerated attributes about html HOT 3 OPEN

1B Allow DOMString? reflection for attributes starting with aria-* only, as a legacy exception.

Should this include role as well? role is the only prop in ARIAMixin which does not start with aria, but it does behave like the others in browsers.

from html.

For ARIA's token, tristate, true/false and true/false/undefined, I think we can tweak the ARIA specs to more clearly assert on what the missing value/invalid value states are.

Depending on implementer appetite we could also make a change to ensure the reflections are limited to only known values. I suppose this would be a breaking change but I don't know what the impact would be.

This is mostly right. However, there's a dilemma which makes it more annoying: currently in HTML DOMString? is always limited to only known values. So if we go down the 4 route, either:

• ARIA has to change to DOMString. This is a somewhat breaking change, e.g. el.ariaLive = null would no longer remove the attribute, but instead set it to "null". Similar to 3. (And thus, would trigger the invalid value default instead of the missing value default... which is maybe fine, if they're the same. But still a breaking change for anyone reading the values back in JS.)

• We have to loosen up HTML to allow DOMString? enumerated attribute reflection that is not limited to only known values. This ends up looking like some version of 1 or 2, i.e., we have to decide the scope of this change and what precedent it sets.

Am I correct in saying that we could/should alter freeform reflected properties such as ariaDescription to be USVString? Again is this something that is possible? (I'm vaguely aware of there being some differences between USVString and Strings, but I'm not well versed enough to know if this is breaking).

No. USVString in this context is generally used for URLs. More info at https://w3ctag.github.io/design-principles/#idl-string-types .

The question is whether we should change them from DOMString? to DOMString. To be consistent with our freeform reflected properties such as HTML's existing title="", abbr="", content="", etc., they should just be DOMString. But that's again a backward-incompatible change, so we need to decide whether we value consistency or compatibility for these.

from html.

On pursuing number 4, I presume it would consist of the following:

For ARIA's token, tristate, true/false and true/false/undefined, I think we can tweak the ARIA specs to more clearly assert on what the missing value/invalid value states are.

Depending on implementer appetite we could also make a change to ensure the reflections are limited to only known values. I suppose this would be a breaking change but I don't know what the impact would be.

Am I correct in saying that we could/should alter freeform reflected properties such as ariaDescription to be USVString? Again is this something that is possible? (I'm vaguely aware of there being some differences between USVString and Strings, but I'm not well versed enough to know if this is breaking).

from html.