Need clarity on missing/invalid ARIA attribute values

[minorninth]

@domenic left some comments on ARIA reflection here: WICG/aom#117 - I'm going to try to copy the relevant sections.

Enumerated attributes and missing/invalid value defaults
The first is that the existing ARIA spec isn't clear on how these attributes behave, i.e. it does not specify the missing and invalid value defaults, or what the case-sensitivity of each value is, etc.

I think the ARIA spec clearly says that attribute values are not case-sensitive, and that empty strings should be treated the same as missing strings.

However, I can't find any clear language on how invalid values should be treated.

For example, https://w3c.github.io/aria/#aria-busy lists two values: "false (default)" and "true". A way to formalize this so that it works with the reflect infrastructure would be to add something like the following prologue before the definition of all attributes:

Various content attributes defined herein have a table listing their valid values. Such attributes are enumerated attributes, whose states and corresponding keywords are given by the first-column of the values table. One row in the value stable will have the suffix " (default)"; this suffix is to be excluded when determining the state/keyword name. The state given by the row marked as " (default)" is the invalid value default and missing value default for such an attribute.

The consequences of this would be that, for example, the browser must interpret aria-busy="TRuE" the same as aria-busy="true". And, aria-busy="", aria-busy="asdf", or no aria-busy="" attribute at all, must all be interpreted the same as aria-busy="false". Hopefully that is already how browsers behave, and it's just the case that nobody ever wrote it down?

I believe this is what was intended and how most browsers behave now, but we should maybe clarify this.

Limited to only known values?
For the enumerated attribute cases, where there's a Values table, you can choose between three models: "limited to only known values", nullable, and default. These correspond to paragraphs 4, 5, and 6 of the reflection section. They differ in how they treat invalid, default, and null values.

Consider the element

. Note that aria-invalid's default is also "false", and aria-live's default is "off". The models then give:

Limited to only known values: div.ariaInvalid === "false", div.ariaBusy === "false", div.ariaLive === "off". Setting to null is the same as setting to "null".
Nullable: div.ariaInvalid === null, div.ariaBusy === null, div.ariaLive === null. Setting to null removes the attribute.
Default: div.ariaInvalid === "asdf", div.ariaBusy === "false", div.ariaLive === "". Setting to null is the same as setting to "null".
The most popular choice among existing reflected HTML enumerated attributes is "limited to only known values". Nullable seems to only be used for crossOrigin, and default seems to be used for older things like textarea.wrap and marquee.direction.

In this case, you'd want to remove the ?s from the IDL, and add something to the above-mentioned prologue stating that these are all limited to only known values.

It's not clear whether we want these properties to "validate" and limit themselves to only known values. My main concern there is that some browsers like Firefox pass through many ARIA attributes unmodified, allowing authors to try out new proposed attribute values before they're official. Forcing the browser to validate these attribute values would possibly be a departure from past expectations. So I might lean towards not validating.

Non-enumerated attributes
Not all of the reflected attributes are enumerated attributes.

For example, aria-valuemin's "Value" is described as a "number". Probably the type should be double, not DOMString?.

For the ones listed as "integer", it should probably be unsigned long. Also, for example, aria-posinset says authors must set it to something greater than or equal to 1; perhaps you should use limited to only non-negative numbers greater than zero? (Aside: why did we not call that "positive numbers"??)

For the ones whose value is "string", like aria-roledescription, it appears that we currently don't have the technology in HTML for reflecting as a nullable string, i.e. DOMString?. For example, given const u = document.createElement("ul"), there is no way to use u.type to distinguish between "has a type attribute with the empty string value" vs. "does not have a type attribute". This seems pretty lame, and I'm happy to add something to HTML to allow you to reflect as a DOMString? in the way you're probably expecting. But, it'd be good to confirm that this is worthwhile: are there string-valued ARIA attributes that have different behavior when you do e.g. aria-roledescription="" vs. just omitting aria-roledescription entirely? If empty-string is the same as omission for these cases, maybe we should just go with the flow.

I think this one is easy: the ARIA spec already says that empty strings are the same as no attribute.

[jnurthen]

I think the ARIA spec clearly says that attribute values are not case-sensitive

I can't find any reference to case sensitivity in the ARIA spec. If you think it is there can you point me to where? ARIA in HTML states clearly that values ARE case sensitive https://www.w3.org/TR/html-aria/#case-sensitivity when using ARIA in HTML.

and that empty strings should be treated the same as missing strings.

This is covered at https://w3c.github.io/aria/#state_property_processing
"Sometimes states and properties are present in the DOM but have a zero-length string ("") as their value. This is equivalent to their absence."

However, I can't find any clear language on how invalid values should be treated.

Nor can I - we need to deal with this - unless someone else can point to the text.

[minorninth]

The ARIA in HTML reference is a requirement for authors, not for user agents. It'd be nice to see a clear requirement for user agents.

I know that both WebKit and Blink do case-insensitive comparisons for ARIA attribute values like "true", "false", "mixed", "inline", etc. - if this is wrong we should clarify it and report it as a bug. It looks like Firefox is case-sensitive in most cases but I'll have to do more checking.

[stevefaulkner]

The ARIA in HTML reference is a requirement for authors, not for user agents.

@minorninth is correct, the author requirement was added when I found interop issues amongst browsers/AT with non lower case values. At the time I also filed bugs (can' remember details at this time).

[jnurthen]

@stevefaulkner I agree. This should be defined. I can’t find a logged issue against the aria spec (other than this one). If there is a previous issue can you please point to it as there might be important history there.

[stevefaulkner]

I can’t find a logged issue against the aria spec (other than this one). If there is a previous issue can you >please point to it as there might be important history there.

@jnurthen don't think i filed a bug against ARIA spec, think it was on browsers/AT to better support mixed case values.

[stevefaulkner]

@jnurthen here is a related JAWS bug and this Firefox bug has further details, which may be of interest

[pkra]

Copying #976 (closed as duplicate of this one) so we don't lose sight of it:

https://w3c.github.io/aria/#aria-atomic

The algorithm seems to leave undefined what happens when the attribute is present but the value is not one of the keywords "true" or "false".

https://w3c.github.io/aria/#typemapping says true/false ARIA attributes map to HTML enumerated attributes. These can have a defined "missing value default" and "invalid value default". If they are not defined, invalid values end up in no state.

Since ARIA doesn't define its processing in terms of states of an attribute, it's unclear what is intended. Is aria-atomic=foobar equivalent to no attribute? Or equivalent to aria-atomic=false? Something else?

[cookiecrook]

Is this issue irrelevant now that we have this section deferring to the HTML processing, or are there remaining problems like case-sensitivity? https://w3c.github.io/aria/#idl-reflection-attribute-values

[domenic]

I believe this is still relevant. This is entirely about the content attributes, not about the IDL reflection.