Spinbutton: What should aria-valuenow be when a user gives invalid input, when should it update?

[0ddfell0w]

We're developing an example ARIA spin button, and we're hoping for a clarification around aria-valuenow.

From the APG:

"The slider element has the aria-valuenow property set to a decimal value representing the current value of the slider."

What should the value of aria-valuenow should be when a user (for example) pastes in some invalid input. Should aria-valuenow simply not change? Should it be set back to some default when the spinbutton loses focus? Should the paste be undone by reverting to the previous value?

Thanks!

[0ddfell0w]

Addendum: What should aria-valuenow be when the user deletes the text in the spinbutton? If it should be the empty string, can we adjust the following language to include a reference to that case?

"The spinbutton element has the aria-valuenow property set to a decimal value representing the current value of the spinbutton."

[jnurthen]

(this is not a WG response - just some additional information)

The native spinbutton in Firefox does not use valuenow but it does expose valuetext.
When an invalid value is specified valuetext is set to ""
When the value is deleted from the spinbutton valuetext also gets set to ""

IMO I would envision valuenow working in the same way to mozilla's valuetext implementation.

[0ddfell0w]

Firefox also adds an invalid state when the input has either

• a non-numerical value
• a value outside of the range specified by min and max.

Chrome also adds an invalid state when the value is outside the range. However, Chrome does more to prevent non-numerical input. The input filters out the non-numerical characters and writes the numerical characters (including hyphens, periods, and even the letter e for scientific notation)

Would the WG consider adding instructions to set aria-invalid on spinbuttons when the value is invalid, either because it's nonsense or because it's outside of the specified range?

[mcking65]

@0ddfell0w, The APG TF discussed this in today's teleconference.

The aria-valuenow, and if used, aria-valuetext, attribute should represent the current state of the control. That is, whatever is displayed should be reflected by the aria value attributes even if the displayed value is invalid. If the displayed value is invalid, then aria-invalid should be set.

Note that some spinbuttons are implemented so that inputting invalid values is not possible. For instance, numeric inputs will not allow letters to be typed.

So, the answers to your questions:

1. What should the value of aria-valuenow be when a user provides invalid input? Should aria-valuenow not change? Should it be set back to some default when the spinbutton loses focus? Should the input be undone by reverting to the previous value?

The aria-value-now should be set to whatever value is displayed in the spinbutton, regardless of its validity.

2. What should aria-valuenow be when the user deletes the text in the spinbutton?

Good question. I would say empty based on our discussion, but a closer look at the spec reveals that an empty value is not allowed for a required property, and aria-valuenow is required on spinbutton. The simplest solution is to change the spinbutton role so that aria-valuenow is supported rather than required. To address this possibility, I have raised w3c/aria#797.

3. Would the WG consider adding instructions to set aria-invalid on spinbuttons when the value is invalid, either because it's nonsense or because it's outside of the specified range?

Yes, I've proposed such a change in pull request #825.

[jongund]

Maybe we are making this more complicated than it needs to be.
The reason designers use spin buttons is to avoid user input errors and therefore do not allow text input, they constrain user input by allowing them to only Increase and Decrease values. So a typical spin button does not allow text input or any invalid values since users can only increase or decrease the value of the control. So suggest our examples should only support increasing and decreasing values, no paste or text input operations.

Jon

[mcking65]

@jongund, sliders have those limitations. Spinbuttons do not.

I agree that an example that is the simplest possible could be helpful. But, at least in my experience, there is more variety than that. I have frequently encountered spinners that accept text input. Some are better than others at limiting input.

Regardless, the APG needs to answer the questions that are not obvious from the spec ... in this case, we have several that need answers.

[mcking65]

This issue was resolved with the merge of pull request #825 yielding commit 4992388.