Scrollbar aria-orientation required property?

[iannightingale]

https://www.w3.org/TR/wai-aria-1.1/#scrollbar

The Scrollbar section states:

Elements with the role scrollbar have an implicit aria-orientation value of vertical.

However, aria-orientation is listed in the "Required States and Properties:" row of the Scrollbar characteristic table, suggesting that it is required and doesn't have an implicit value? These seem incompatible.

[joanmarie]

I'm not sure this is a bug or that the proposed fix is desired. Look at the text here: https://www.w3.org/TR/wai-aria-1.1/#state_property_processing:

WAI-ARIA roles have associated states and properties that are qualified as "supported" or "required". An example of a property supported by the combobox role is aria-autocomplete. The property is designated "supported" in this case because a given combobox might or might not implement auto completion. In contrast, the combobox role requires the aria-expanded state in order to indicate that it is expandable. Comboboxes have a descendant listbox that is either open or closed. If the listbox is open, the combobox is in its expanded state; otherwise it is collapsed.
[...]
However, required states and properties that are absent are an author error. Missing required states and properties are treated as if they were present and have an implicit neutral value that is not necessarily their default value.

aria-orientation is required; not merely supported.

[jnurthen]

Why is it required? The prose states clearly

Elements with the role scrollbar have an implicit aria-orientation value of vertical.

Compare to slider for example which has similar prose and specifies aria-orientation as supported not required.

[joanmarie]

Then I think slider is potentially incorrect.

Scrollbars (and sliders) move in a particular direction. Depending on the UI, knowing that direction matters. For instance, up/down might only work with vertical scrollbars; left/right might only work with horizontal scrollbars. Which one should a screen reader user guess? How can the AT inform the user what directions are relevant?

[jnurthen]

They both have defaults if aria-orientation is not specified. AT should communicate the default in this case.

[katiehockman]

Right, I don't think it should be listed as a required ARIA property if it says that scrollbar's have "an implicit aria-orientation value". As @iannightingale said, those seem contradictory.
We can all likely agree that an aria-orientation property is important for scrollbars, but if browsers are supposed to interpret role="scrollbar" to have an implicit aria-orientation="vertical", then it shouldn't be listed as required. Listing it as required seems to indicate that no default value exists.
It is also the only ARIA role that I could find that lists aria-orientation as required, rather than simply supported.

[joanmarie]

So how is this different from the text described here: #780 (comment)

[katiehockman]

Yeah, I see your point about default values.
My problem is with the line "required states and properties that are absent are an author error". Why are they indicating a reasonable default value (implicitly) if it is an author error to not include aria-orientation? That is atypical for required states and properties.

[katiehockman]

It also says that missing required ARIA properties "have an implicit neutral value that is not necessarily their default value". That wording confuses me a bit :)
What would a browser be expected to do if someone doesn't provide an aria-orientation value? How is implicit neutral value different than default value?

[joanmarie]

I think we might want to clarify the paragraph @katiehockman. Because, yeah, it's not the most illuminating. :)

Getting back to the opening report and proposed change: If we make aria-orientation a supported (but not required) property of scrollbar (and slider), then won't validators stop flagging its absence as an error?

[katiehockman]

Yes, ideally they would stop flagging the absence. It would depend on what the W3C expects browsers to do in situations where the implicit value is correct (ie. the default is "horizontal" and adding an aria-orientation="horizontal" is redundant). If they expect browsers to propagate that implicit value up to the a11y tree, then this shouldn't be listed as required, imo.

[joanmarie]

If we're going to make a change, I'd be more comfortable with keeping this as a required property, but changing the implicit value to "undefined".

In the case of scrollbars (and sliders), I think directionality matters and is a detail screen readers might wish to present to end users because directionality can be relevant to what keys/gestures are applicable. Because directionality matters, I think that authors need to provide it explicitly, and that failure to do so is (and should be flagged by validators as) an authoring error.

That said, because the implicit value is "vertical" screen readers don't know if the author provided the orientation (i.e. the information can be trusted and passed along to end users) or failed to do so (user agents fell back on vertical, hope it's right, might not be though so good luck!).

[katiehockman]

Sounds reasonable! We'll see what the W3C ends up deciding.

[jnurthen]

@joanmarie if you make this change you will have to change the note in the definition of aria-orientation too

NOTE In ARIA 1.1, the default value for aria-orientation changed from horizontal to undefined. Implicit defaults are defined on some roles (e.g., slider defaults to horizontal; scrollbar defaults to vertical) but remain undefined on roles where an expected default orientation is ambiguous (e.g., radiogroup).

[joanmarie]

@jnurthen Understood. And as was pointed out earlier, the language about supported vs. required is not especially clear. I think the originally-reported issue and subsequent observations are a discussion we need to have with the working group (perhaps today?).

For the record, I am willing to consider that I am wrong. :) But as a screen reader developer who doesn't like bogus values, I'm not convinced of that yet. I will live with whatever the group decides, of course.

[mcking65]

5.2.2 Required States and Properties says:

States and properties specifically required for the role and subclass roles. Content authors MUST provide a non-empty value for required states and properties. Content authors MUST NOT use the value undefined for required states and properties, unless undefined is an explicitly-supported value of that state or property.

5.2.3 Supported States and Properties says:

States and properties specifically applicable to the role and child roles. User agents MUST map all supported states and properties for the role to an accessibility API. Content authors MAY provide values for supported states and properties, but need not in some cases where default values are sufficient.

With the above definitions, I agree with the original assertion that the specification should not define a default value for a required state or property.

With these definitions, we have only two options: make aria-orientation supported rather than required for scrollbar, or leave it required and remove the default value. The only path I see out of this either/or situation is to change the definitions, and I don't think this situation justifies doing that.

The lowest risk option is make aria-orientation supported for scrollbar; that will not break existing content that currently is invalid because it does not specify a value for aria-orientation but happens to work because the default value is being provided to users and is correct.

Leaving it required and removing the default value has the potential to make some future content better quality because validators will call out when aria-orientation is not set. Depending on what specific browsers do when the value is not specified, this option may or may not impact existing content.

Neither of these options is very high risk or high impact. The aria-orientation property is most useful to screen reader users, and screen reader users very, very rarely use scrollbars. Because of the way screen readers work, they are not a very necessary widget.

I lean toward leaving aria-orientation required and removing the default value for the scrollbar simply because I do not think there is a clearly good default value and the impact of the change to end users is likely to be minimal or non-existent. This should have no impact on validators because it was already required. It would impact user agents because they should expose it as undefined when not specified.

[accdc]

Personally I'm in favor of moving this to 'Supported' and not 'Required'.

If any attribute has an implicit value, as this one does, there is no need to include the attribute explicitly in the markup because it already has a valid implicit value. If we make this one an exception, it will throw all others into question, and if all of those are made required they will start failing validators all across the web due to this line in the definition of required: "required states and properties that are absent are an author error."

So, if left required, we are saying both of these things at the same time, that this value is implicit (meaning explicitly including the attribute is not necessary), and also that this attribute is required and not including it will fail validation because you have to include the attribute in all cases regardless, which is a contradiction.

[mcking65]

@accdc, if we leave it required, we would remove the implicit value, eliminating your objection. As I stated above, I lean toward leaving aria-orientation required and removing the default value for the scrollbar simply because I do not think there is a clearly good default value and the impact of the change to end users is likely to be minimal or non-existent. This should have no impact on validators because it was already required. It would impact user agents because they should expose it as undefined when not specified.

[joanmarie]

Discussion during the meeting: Scrollbar and Slider should be treated separately, even if they are technically the same issue, the functional implications are likely different.

Resolution with respect to scrollbar is: Leaving it required but removing the implicit default value.

Let's do that in a pull request (if it's not already done) and then do a new issue if appropriate for slider.

[iamrafan]

Here are a few browser/AT test results which might be helpful

	Browser/AT	aria-orientation= "horizontal"	aria-orientation= "vertical"	No 'aria-orientation' attribute	Does aria-orientation default to some value?
1	Edge/Narrator	Not announced	Not announced	Not announced	N/A
2	Edge/JAWS	Not announced	Not announced	Not announced	N/A
3	Edge/NVDA	Not announced	Not announced	Not announced	N/A
4	Chrome/NVDA	Not announced	Not announced	Not announced	N/A
5	Chrome/JAWS	Horizontal	Not announced	Not announced	Default behavior same as vertical
6	IE/JAWS	Horizontal	Not announced	Not announced	Default behavior same as vertical
7	IE/NVDA	Not announced	Not announced	Not announced	N/A
8	Safari/voiceover	Horizontal	Vertical	Vertical	Defaults to vertical
9	Firefox/NVDA	Not announced	Not announced	Not announced	N/A

[jnurthen]

covered by #858