value of spinbutton

[JAWS-test]

ARIA spec for spinbutton::

Authors SHOULD set the aria-valuenow attribute when the spinbutton has a value.
Default for aria-valuenow is that there is no current value

I think this is problematic because if role=spinbutton is on the HTML <input>, then this can have a value and the HTML attribute always takes precedence over the ARIA attribute. I.e. an ARIA attribute is then unnecessary and if aria-valuenow and value have different values, it is theoretically so that value wins and aria-valuenow is ignored, but practically it is so that here every browser does something different and the screen readers in turn ignore the information of the browsers to the Accessibility API, so that a big chaos arises.

In addition, it could be considered whether a value could also result from the text content for spinbuttons that are not located at an <input>, and thus aria-valuenow would then also be superfluous. Like with role=textbox:
<div role=spinbutton tabindex=0>3</div> .
This is also interpreted differently by browsers (in Firefox this spinbutton has no value, in Chrome the value is 3).

[scottaohara]

is this not an author guidance issue (apg), or potentially an aria in html issue? if used on a native HTML element there will always be a value, so it's not really applicable there. But if someone is making a truly custom ARIA spinbutton then it's important. A visible value, at least a visible value reflecting a replica of a native html number field/spinbutton may not be always true for a custom aria spinbutton.

Worth noting that I did see chrome/edge return a value of '3' per your code example. the value returned was 0 and macOS VO announced the value as zero. (can't check other browsers presently).

As one action item i've already created the necessary ARIA in HTML issue to address this there. We can decide what else to do, if anything, during the next triage of issues.

[JAWS-test]

is this not an author guidance issue (apg), or potentially an aria in html issue?

I don't think so. My point is rather

• that the ARIA specification says nothing about how a value of an ARIA element is derived (this applies not only to spinbutton, but also to other elements, like textbox, see aria-valuetext would be useful on many more roles #711).
• that the ARIA specification says that a spinbutton should be marked with aria-valuenow, otherwise the value is undefined, although a spinbutton could get the value from the HTML element (value, text content). And if this is not allowed, it should be explicitly stated in the specification, so that not every browser and screen reader does what it wants.

Therefore, the following would be good:

• write in the specification for spinbutton that the value can come from a native attribute (like value in HTML) or from the text content.
• if neither is available, a value should be defined with aria-valuenow, otherwise the spinbutton has no value

And for all elements whose value can be determined from the text content, it would still have to be specified which rules apply when determining the text content, i.e. how does aria-hidden, aria-owns, aria-label etc. affect the text content (should there be similar rules there as for determining the accessibile name)?

[JAWS-test]

@scottaohara Looking at w3c/html-aria#409, I think it is a misunderstanding: I was not talking about <input type=number>, but about <input type=text> (short <input>).

[JAWS-test]

Test results: https://codepen.io/jaws-test/pen/RwxpjwP

Example 3 and 4, which do not work in Chrome, are based on the examples from @mcking65 at #812. Either they are no longer allowed or Chrome makes a mistake here. I.e. it should also be clarified whether it is allowed that a spinbutton is a widget role where a child element and not the widget itself gets the focus

[scottaohara]

Thanks for all the extra info there. I understand better what you mean now.

[jnurthen]

Can this be tackled as part of accname#184