Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make aria-valuenow supported instead of required for spinbutton role #797

Closed
mcking65 opened this issue Aug 6, 2018 · 1 comment
Closed
Assignees
Milestone

Comments

@mcking65
Copy link
Contributor

mcking65 commented Aug 6, 2018

The spinbutton role requires aria-valuenow to be set. Not setting aria-valuenow is an author error, and if not set, the implicit value of aria-valuenow is 0.

Section 5.2.2 Required States and Properties says:

Content authors MUST provide a non-empty value for required states and properties.

This means that a spinbutton with a textbox cannot be empty. Is this a reasonable limitation on spinbuttons? Does this mean that it is a requirement to disable delete and backspace on spinbuttons with text fields when there is only one character left in the field? Or, does it mean that pressing delete or backspace has to show a default value, e.g., 0.

Does this mean that it is not possible to make a spinbutton that is initially empty and has aria-required set to true in order to force the user to choose a value?

If it is reasonable to enable authors to make a spinbutton that can be empty, then it seems we need to remove the requirement to set aria-valuenow and instead change aria-valuenow to a supported property for the spinbutton role.

This approach would be supported by the aria-valuenow description, which says:

If the current value is not known (for example, an indeterminate progress bar), the author SHOULD NOT set the aria-valuenow attribute. If the aria-valuenow attribute is absent, no information is implied about the current value.

@jnurthen
Copy link
Member

jnurthen commented Aug 9, 2018

Agree that initial state is certainly a problem in the current spec. I'm in favour of making aria-valuenow not a required attribute. Indeed if someone specifies aria-valuetext this would be used instead of aria-valuenow and should certainly be allowed. requiring valuenow in this instance doesn't seem to add any value.

@jnurthen jnurthen added this to the ARIA 1.2 milestone Aug 16, 2018
mcking65 added a commit that referenced this issue Aug 31, 2018
…th sibling steppers

For issue #797, allow empty spin buttons by:
1. Changing aria-valuenow to supported from required property.
2. Changing prose to author SHOULD from author MUST specify value for aria-valuenow.
3. Adding aria-valuetext as supported property.

For issue #642, allow min and max to be undefined:
1. Change aria-valuemin and aria-valuemax from required to supported properties.
2. Revise prose of paragraph with normative statements.

For issue #812:
1. Change description to clearly state that a text field with sibling buttons outside the spinbutton is permitted.
2. Related editorial change to consolidate keyboard requirements into a single paragraph.
3. Other related editorial revisions for clarity.
jnurthen pushed a commit that referenced this issue Oct 5, 2018
…th sibling steppers (#813)

For issue #797, allow empty spin buttons by:
1. Changing aria-valuenow to supported from required property.
2. Changing prose to author SHOULD from author MUST specify value for aria-valuenow.
3. Adding aria-valuetext as supported property.

For issue #642, allow min and max to be undefined:
1. Change aria-valuemin and aria-valuemax from required to supported properties.
2. Revise prose of paragraph with normative statements.

For issue #812:
1. Change description to clearly state that a text field with sibling buttons outside the spinbutton is permitted.
2. Related editorial change to consolidate keyboard requirements into a single paragraph.
3. Other related editorial revisions for clarity.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants