search

w3c / aria

Accessible Rich Internet Applications (WAI-ARIA)
https://w3c.github.io/aria/
Other
621 stars 118 forks source link

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

Open rahimabdi opened 4 weeks ago

rahimabdi commented 4 weeks ago

Describe the change

In order to address https://github.com/w3c/aria/issues/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:

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:

  1. 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 https://github.com/w3c/aria/issues/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 https://github.com/w3c/aria/pull/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 https://github.com/w3c/aria/issues/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 commented 2 weeks ago

@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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 1 week ago

@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:

aardrian commented 1 week ago

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.