Description of bug or feature request

This issue comes out of the combination of a few factors:

One relatively common way of working around the limitations of <input type="number"> is to recreate a spinbutton with <input type="text" role="spinbutton"> + some javascript to handle arrow keys and limit input to numbers. Ideally, when authoring this you could add the role and rely on the native value over defining an unnecessary duplicate aria-valuenow. However, this is currently against the authoring "SHOULD" guidance in ARIA, and how native value vs. aria-valuenow should be mapped is not clearly defined.

This is exacerbated by the fact that if an author chooses to explicitly set aria-valuenow on a native input and update it in response to user interaction, the update often happens one render cycle after the interaction, which causes practical bugs when using a screen reader (most commonly: the previous value is read instead of the new one). This is more common when using a framework like React.

Right now the default for an undefined aria-valuenow is 0, which is not ideal for spinbuttons that have a defined native HTML value. Even if we say this is an authoring error (which I don't really think it should be), checking the native value would be a better first fallback.

This came up because of a difference in UIA between how aria-valuenow and value are mapped on an <input type="text" role="spinbutton"> (ValuePattern vs. RangeValuePattern) which affects Narrator. In discussing it with the Edge team, we both agreed that the spec was counter-intuitive for authors and somewhat ambiguous for browsers on how that should be handled.

Suggested change

Right now we don't have very clear spec steps defined for value calculation (ref: w3c/accname#200, I don't remember why I'm assigned to this, apparently I didn't know how busy I'd be at the start of 2024). Core AAM already references aria-valuenow as the ARIA mapping for value, including value on input[type=text].

Given that, I think the best way to capture this in the spec would be to modify the author & browser guidance in ARIA, specifically referencing using native HTML value when available if aria-valuenow is not defined. And also that authors do not need to define aria-valuenow if a native value is defined and is a decimal number.

Browser implementors can correct me, but since aria-valuenow is already a string type for both the DOM and IDL attributes, my assumption is that the string value for e.g. input[type=text] could be handled in essentially the same way and with the same error handling as the string aria-valuenow.

Will this require a change to CORE-AAM?

No

Will this require a change to the ARIA authoring guide?

No, unless Matt or anyone else wants to add an additional example

Related to #1716