Clarify "undefined" assignment for a state/property as the value (not the string)

[rahimabdi]

Describe the change

In order to address #2156, @spectranaut /@smhigley /@aardrian suggested clarification in the spec of how to assign undefined for states and properties; namely, to clarify that undefined represents a value (e.g., aria-expanded=undefined) rather than a string (e.g., aria-expanded="undefined"). This change may also involve explicitly stating the absence of a value is equivalent to undefined.

It's unclear where this should be documented (perhaps Section 6.2 Characteristics of States and Properties).

Unconventional techniques for assigning an undefined value

There may need to be additional clarification on the following assignment methods:

• Empty string: stateOrProperty = "" (this one is referenced in the aria-current section as being allowed via the empty string, i.e., "If the attribute is not present or its value is the empty string...")
• Null: stateOrProperty = null

Potentially erroneous spec examples of "undefined" string value

The following two undefined references use the string value which may be confusing and require updating:

1. Section 9.2 States and Properties:

When exposing as a platform API Boolean state:
For values of "" (empty string), "undefined" or no attribute present:

2. aria-hidden state description section:

NOTE
As of ARIA 1.3, aria-hidden="false" is now synonymous with aria-hidden="undefined".

Validator testing of undefined vs. "undefined"

W3C HTML Validator shows the following parsing results when undefined is assigned as a value (stateOrProperty=undefined) vs. a string (stateOrProperty="undefined").

For states/properties that support explicit assignment of undefined:

State/property	"undefined" string	undefined value	Tested elements
aria-checked	passes	passes	role="checkbox", role="radio"
aria-current (may be missing undefined in its Values table, see #2176)	fails	fails	<button>, <a>, role="button", role="link"
aria-expanded	passes	passes	<button>, <a>, role="button", role="link"
aria-grabbed	Not tested	Not tested	None (deprecated element)
aria-hidden (very recently added as part of #2090)	fails	fails	<button>, <a>, role="button", role="link"
aria-orientation	passes	passes	role="scrollbar", "role="slider", role="tablist"
aria-pressed	passes	passes	<button>, role="button"
aria-selected	passes	passes	role="tab"
aria-multiselectable (may be missing undefined in its Values table, see #2176)	fails	fails	role="tablist", role="listbox"

Link to the version of the specification or documentation you were looking at

Link to documentation: https://w3c.github.io/aria

Does the issue exists in the editors draft (the editors draft is the most recent draft of the specification)?

Yes.

[smhigley]

@rahimabdi could you clarify how you're testing the not-string undefined value with the W3C HTML validator? I'm definitely not getting failures for HTML like <button>some text</button> (i.e. with no attribute defined), and I don't believe the validator is looking at scripting or setting of IDL attributes. Some of the things you have marked as failures under the "undefined value" column are kinda throwing me a bit 😅

[smhigley]

Also dropping this here as well (I posted it in a reply comment in a PR, but thought it'd be easier to find here too):

I made a test page to output the browser-mapped values when ARIA attributes are set to the string "undefined", not set at all, or set programmatically to undefined: https://jsfiddle.net/pobwvgs9/

I checked it in Chrome, Edge, Safari, and Firefox on macOS and Windows (Safari only on mac), and all of them had the same not-undefined results for the string "undefined". The results for not-defined and programmatic = undefined values are what I'd expect & what matches the spec, while the string "undefined" are not.

[spectranaut]

Discussed briefly during the ARIA working group meeting: https://www.w3.org/2024/05/16-aria-minutes#t09

Consensus that the string "undefined" should not be considered undefined.

[rahimabdi]

@rahimabdi could you clarify how you're testing the not-string undefined value with the W3C HTML validator? I'm definitely not getting failures for HTML like <button>some text</button> (i.e. with no attribute defined), and I don't believe the validator is looking at scripting or setting of IDL attributes. Some of the things you have marked as failures under the "undefined value" column are kinda throwing me a bit 😅

@smhigley For the undefined assignment (not the string), I took each of the state/properties and set it as follows: stateOrProperty=undefined, e.g., aria-expanded=undefined. I've never implemented these in this manner, or seen them implemented this way, but the spec language (and HTML Validator) seem to be OK with it.

I think the spec may benefit from greater clarity on what it means for a state/property to be undefined, and to delaminate all the ways something can be undefined. I counted the following techniques:

• stateOrProperty="undefined" (the ARIA WG agrees this is invalid)
• stateOrProperty=undefined
• stateOrProperty=null
• stateOrProperty="" (empty string)
• stateOrProperty (without an assignment, e.g., aria-current). Does this one need a default value?

[aardrian]

I am on board with consistency within the spec itself. Are you proposing a PR to do so?

Otherwise I cannot tell from your comment what you feel the next step should be.

[MarioBatusic]

Do I understand it correctly: PROPERTY=undefined and PROPERTY is not set results in the value undefined; and PROPERTY="undefined" or PROPERTY="" is not undefined.

If so we should correct it in the specs.