Why is spinbutton limited to having a textbox and/or two buttons as children?

[liamdebeasi]

Describe your concern

I am trying to create an interface similar to the date wheel picker on iOS:

The image above shows three picker columns: One for month, one for date, and one for year. Screen readers should focus each column as a whole instead of each individual button within a column. Users can then change the selected value by dragging with one finger.

The closest role I can think of spinbutton, but adding role="spinbutton" to the column container is not correct according to the spec because each column has more than two buttons.

Additionally, screen readers do not announce that this spinbutton is adjustable, so users do not know that they can drag to change the value.

Why is spinbutton limited to only two buttons in this case? Is this an area where the spec could be improved to account for scrolling gestures, or is a different role more appropriate?

Link to the version of the specification or documentation you were looking at at.

Link to documentation: https://www.w3.org/TR/wai-aria/#spinbutton

Does the issue exists in the editors draft (the editors draft is the most recent draft of the specification)? Yes: https://w3c.github.io/aria/#spinbutton

[chlane]

Hi @liamdebeasi have you seen the example that uses a group of three spin buttons for date selection at https://www.w3.org/WAI/ARIA/apg/example-index/spinbutton/datepicker-spinbuttons.html?

[liamdebeasi]

Yes, I have seen that example. The spinbutton document I linked to states the following:

Authors MAY create a spinbutton with children or owned elements, but MUST limit those elements to a textbox and/or two buttons. Alternatively, authors MAY apply the spinbutton role to a text input and create sibling buttons to support the increment and decrement functions.

The date picker spin buttons example you linked to follows this guidance because the spinbutton has two sibling buttons (the increment and decrement buttons).

---

My use case does not follow these guidelines even though this practice is implemented elsewhere (on iOS, for example). I am trying to understand why the guidance does not allow for the spinbutton to be placed on a scrollable container with more than 2 child buttons. Alternatively, is there a role that is better suited for the pattern I am trying to implement?

Here is a rough example of what I am trying to accomplish: https://codepen.io/liamdebeasi/pen/jOzpWXx

The example above mostly works, but I noticed that screen readers do not announce that the spinbutton is adjustable via scroll, which I think is important information to convey to users.

[scottaohara]

are you saying that you are interpreting each of the potential values/options to be a button?

i would have anticipated a up/down button to allow users to choose the appropriate value for the spin button, rather than require them to swipe through each month,day,year as individual buttons.

or am i misunderstanding your intent?

[liamdebeasi]

Your understanding is correct. I am trying to implement a pattern similar to what iOS does here: (this video has sound with VoiceOver)

spinbutton.mp4

When I activate the month or year columns, VoiceOver highlights the entire column rather than each button. I can then swipe up/down to adjust each column.

An important piece in that demo is that VoiceOver announces a) that each column is adjustable and b) how to adjust each column.

---

In my own code, I can get each column highlighted, but screen readers do not announce that the column is adjustable via scroll presumably because the spinbutton guidance does not allow for that.

[scottaohara]

it seems like you may be trying to treat a spinbutton as one would expect a listbox to behave. A spinbutton should not contain multiple buttons representing different values... the reason it's called out as saying 2 buttons is that there should be a button to step up/down the possible values. the various values aren't expected to be buttons themselves. again, this sort of expectation would be more inline with a listbox where each interactive option element represents a value for the listbox. Maybe that is the control you should be using to align with your expectations?

Note, in your commentary about the video - you did not actually swipe up/down to adjust the value. If you had, the swipe up / down behavior would have moved up or down a value - which would have correlated to the 2 possible buttons that similarly allow such behavior in an <input type=number>.

I'm going to close this issue, as the WG does not see a reason to change this based on the intent of the role. Again, if you would want each item to be an interactive element, it seems a listbox > options is what you're likely looking for. Please respond if you have any other questions. Thanks

[liamdebeasi]

Thanks for the reply, though the listbox role is not really useful here. I attached comparison videos to better demonstrate the issue I am running into.

with listbox	with spinbutton
listbox.MP4	spinbutton.mp4

The problem with listbox is that it makes it impossible to swipe over columns without accidentally selecting values within the columns. Notice in the video that in order to move to the days column, I first need to swipe through each item in the month column. This means that I will always end up with "December" selected even if I am just trying to move to the next column with a swipe right gesture.

The spinbutton role avoids that issue by making each column highlighted when swiping left or right. In order to select a value within the column, I can double tap and then scroll up or down on iOS. This means that I can easily jump between columns without accidentally selecting the wrong value.

I realize spinbutton may not be an exact match, but I do think there is an opportunity for improvement here within the aria spec. This kind of user interface is very common on iOS and is also implemented in web-based projects such as https://mobiscroll.com/. Perhaps a separate role such as role="spinner" may be useful?

[scottaohara]

The reason I suggested the listbox was because you had mentioned wanting the different values to be represented as buttons. If this were the case, then the behavior you find to be unwanted with the listbox (each option being focusable) would be the behavior that would likely be expected if all the values represented buttons.

[liamdebeasi]

If the <button> elements were something else such as a <div>, would that then be considered valid usage of spinbutton?

edit: I decided to explore tweaking my component's layout to better work with spinbutton. Thanks for the help!