I think this sentence adds more confusion than it resolves. Especially since you cannot just leave it out at the moment without hitting an assert.

Part of this could be an informative note for authors/implementors, rather than in the normative text of the Enumerated Attribute definition.

Do we ever anticipate a time where the explicit "undefined" content attribute values would need to map to an Undefined state, separately than the Null state? For example, I think the only scenarios where anundefined is allowed are with theundefined/true/false/[/mixed] enumerated values, but since the Missing Default and Invalid Default are the same one those, there is no impact... Can we foresee any scenario where those would be different? For example, ifundefined was an allowed token value ofaria-invalid? (Presumably we just need to always avoid that, which seems okay.)

See@keithamus' related comment inhttps://github.com/w3c/aria/pull/2484/files#r2084175913

@annevk@cookiecrook Got it, I've removed this sentence: "User agent implementations may omit the Undefined state since the lack of an explicit state results in the same behavior."

@keithamus Hopefully the link to the HTML spec (which defines the state computation algorithm) is sufficient.

Do we ever anticipate a time where the explicit "undefined" content attribute values would need to map to an Undefined state, separately than the Null state? For example, I think the only scenarios where an undefined is allowed are with the undefined/true/false/[/mixed] enumerated values, but since the Missing Default and Invalid Default are the same one those, there is no impact... Can we foresee any scenario where those would be different? For example, if undefined was an allowed token value of aria-invalid? (Presumably we just need to always avoid that, which seems okay.)

As@keithamus also mentioned, the "undefined" content attribute value will map to the invalid value default (effectively treated as invalid), and fortunately there's no need for any ARIA attribute to have an explicit "undefined" keyword (nor an Undefined state mapping to "undefined" the keyword). I plan to add a note on this in this PR.

Here are all the attributes which currently support a value of "undefined" per spec, all mapping to their respective invalid value defaults and equivalent with behavior currently defined in spec:

• aria-checked ("undefined" maps to null)
• aria-expanded ("undefined" maps to null)
• aria-hidden ("undefined" maps to False state)
• aria-orientation ("undefined" maps to null)
• aria-pressed ("undefined" maps to null)
• aria-selected ("undefined" maps to null)

Note: Each of these 6 attributes also supports the empty string as a keyword, so"" and "undefined" are the same.

Only two enumerated ARIA attributes have differing invalid/missing value defaults and they don't support "undefined" however, any invalid value provided to them should result in a value of "true" per spec (now that they're enumerated, this is handled by the invalid value default):

• aria-current
  • invalid value default = True state
  • missing value default = False state
• aria-invalid
  • invalid value default = True state
  • missing value default = False state