Aria-practices: Develop example of select-only combobox

[carmacleod]

It would be useful to have an example of a readonly combobox in the APG.
The AccDC simulated readonly combobox example works well, if @accdc is ok with us using that as a basis for an APG example. (Note that "simulated" just means it doesn't use a text input).

[accdc]

Hi Carolyn,
Yes of course, you are welcome to use any of my code for any purpose you like. :)

If you need any help breaking this out just let me know.

Kind regards,
Bryan

[carmacleod]

Thanks, Bryan!
Much appreciated!
Carolyn

[mcking65]

Issue #1330 has some good discussion of implementation details and links to useful examples.

Based on both that discussion as well as the language in the pattern, I am changing the title from "read-only" to "select-only". A read only combobox would be a combobox where the value cannot be changed.

[carmacleod]

@mcking65

I am changing the title from "read-only" to "select-only". A read only combobox would be a combobox where the value cannot be changed.

I don't mean to hijack this issue, but I think an abundance of clarity is needed around the term "read-only" because combobox supports aria-readonly. Pain points are as follows:

• Windows platform has used the term "read-only" (since, like, forever) to describe what we are now calling a "select-only" combobox. Authors with a Windows background will need this new terminology explained in a big Note box.
• typically, applications use "disabled" (or aria-disabled) on a control to indicate that the value cannot be changed.
• so... what, exactly, does aria-readonly="true" mean on a combobox? Can the user invoke the popup? If so, can they select an item from the popup to change the combobox value? When you say "the value cannot be changed", does it simply mean _the value cannot be typed into the text field_? And if that is the case (i.e. if only the text part is read-only), then is there any difference between a select-only combobox (an example of which will be developed for this issue) and a combobox with aria-readonly="true"?
• how does a screen reader user know that they are in a select-only combobox? Would it be helpful to know that values cannot be typed into the combobox? Wouldn't that be indicated with aria-readonly?

Neither the combobox spec, nor the APG combobox pattern adequately clarify this concept.

[mcking65]

@carmacleod commented:

• Windows platform has used the term "read-only" (since, like, forever) to describe what we are now calling a "select-only" combobox. Authors with a Windows background will need this new terminology explained in a big Note box.

This is an MSAA hold over that impacts only screen reader users. It has forever been a source of user confusion. Saying something is read only but then having to teach people that you can change it because it is also announced as combobox is just frankly ridiculous. It is an oxymoron.

Fortunately, The native Windows world has seeme to migrate away from those widgets though so you rarely encounter them. Now, we instead get buttons named by a value chosen from a popup, e.g., a font menu button with the chosen font as the name of the button. Obviously, that pattern has another problem -- the input doesn't actually have a name because the value is the name. At least the ARIA combobox pattern addresses that issue quite nicely.

• typically, applications use "disabled" (or aria-disabled) on a control to indicate that the value cannot be changed.

Yes, if the control is not editable, so that is probably best for select-only combobox elements that cannot be changed.

• so... what, exactly, does aria-readonly="true" mean on a combobox? Can the user invoke the popup? If so, can they select an item from the popup to change the combobox value?

You cannot change the value -- that is what it means. It would be pretty weird to enable the popup if you can't change the value.

When you say "the value cannot be changed", does it simply mean _the value cannot be typed into the text field_?

No, it means that you cannot change the value of the input by any means, via typing or opening a popup.

is there any difference between a select-only combobox (an example of which will be developed for this issue) and a combobox with aria-readonly="true"?

An editable combobox that is read-only is in the tab sequence and can be read. It cannot be changed, so you can't open the popup. It is functionally identical to a input type text that is read-only.

A select-only combobox is functionally identical to an HTML select with size=1. So, you change its value by choosing from a list. And, that list typically supports typeahead. If you want to disable it, use aria-disabled=true, not aria-readonly.

• how does a screen reader user know that they are in a select-only combobox? Would it be helpful to know that values cannot be typed into the combobox? Wouldn't that be indicated with aria-readonly?

No, saying it is read-only is super confusing. Screen reader users just hear that it is a combobox, so they know that you can choose its value from a list thingy of some kind.

Neither the combobox spec, nor the APG combobox pattern adequately clarify this concept.

I think the ARIA spec is sufficiently clear. The spec for readonly says:

Indicates that the element is not editable, but is otherwise operable.

This means the user can read but not set the value of the widget.

One possible improvement to the combobox pattern might be to recommend aria-disabled for select-only combobox widgets that are not operable and to limit use of aria-readonly to editable combobox widgets that are not in an editable state.

[carmacleod]

One possible improvement to the combobox pattern might be to recommend aria-disabled for select-only combobox widgets that are not operable and to limit use of aria-readonly to editable combobox widgets that are not in an editable state.

That would definitely be helpful. I do still think that something along the lines of the following is also necessary, even if it's only to redefine read-only for the benefit of old Windows programmers: 😄

A read-only combobox is in the tab sequence and can be read, however its popup cannot be opened, and its value cannot be changed.

[mcking65]

We should probably also have a version of an editable combobox that restricts input to only allowed values and thus limits typing.

For example, we could make a version of the states combobox where the textbox behaves like the aria-autocomplete="list" textbox except that when typing, the visual focus automatically moves in the list to the firstoption that matches the input in the textbox. And, if you start typing an invalid value, nothing happens. For instance, if the edit field is empty and you type "b", nothing happens because there are no states that start with "b". If you type "n" in the empty field, the list would open and nebraska would be highlighted. If you then type "a", nothing would happen because there are no values that start with "na". On blur, the option in the list that is highlighted becomes the value. Thus, the only way to put a value in the textbox is to select it from the list.

If the combobox contains a value when it receives focus, delete and backspace would remove the entire value; it would not be possible to change the value without choosing a new one from the list. Typing would be the same as if the combobox were empty; it would replace the value and focus the first match in the list.

Because there is a textbox, you would still be able to arrow through the characters, select them, and copy to the clipboard. It is not a read-only edit field because you can change its value. It is an edit fieled where input is restricted.

This is functionally equivalent to a select-only combobox when it comes to value entry. However, it has the additional functionality of supporting delete, select, and copy. It also allows the user to type slowly. In a typical select, there is a time-out on typing. That is, if you want to scroll to "North Carolina", you have to type "no" quickly. In an editable combobox that restricts input to allowed values, you could type "n", wait for as long as you wish, then "type"o". When "n" is typed, "n" appears in the textbox and the visual focus is on "Nebraska". It stays that way until you type another character or until blur or backspace. Then, typing "o" appends "o" to the value in the textbox and moves visual focus to "North Carolina" in the listbox.

[carmacleod]

@mcking65
That's an excellent idea for an example.

In a typical select, there is a time-out on typing.

Ha - thank-you for pointing this out! Hilariously, I guess I usually type slowly enough in a select that I never consciously noticed the "type quickly" behavior with the timeout... other than occasionally thinking, "huh, this select seems a bit flaky. I typed a new character and it didn't do anything until I typed it again". 😆

I got used to those old Windows "read-only comboboxes". They have the same "first character selects" behavior as slow typing in a <select>.

Anyhow, I digress. I hope you had a good chuckle at my foibles. 😉

I've opened issue https://github.com/w3c/aria-practices/issues/1337 so that your example idea is not lost. I also opened https://github.com/w3c/aria-practices/issues/1338 to add a note about read-only to the combobox pattern.

[smhigley]

@mcking65 this:

Fortunately, The native Windows world has seemed to migrate away from those widgets though so you rarely encounter them. Now, we instead get buttons named by a value chosen from a popup, e.g., a font menu button with the chosen font as the name of the button

isn't really true. UWP XAML (the most modern Windows desktop framework, and the one I'd go to for looking at where desktop patterns are headed) includes a "select-only" combobox, as do many modern Windows apps. Check out Settings, or the standard <select> element in a browser, and they both demonstrate select-only comboboxes (though it is true that they no longer have a readonly property).

The Office ribbon has a good number of menu buttons, since the entire ribbon functions more like a menubar. I wouldn't take that as an indication that Windows is moving away from select-only combos (if that's what you were thinking of).

Regarding readonly, I would suggest not using aria-readonly on comboboxes at all, ever. If a combo is readonly, it should be a readonly input since, as Matt mentioned, there is no difference between the two.

Edited to clarify: I'm not suggesting forbidding aria-readonly on a combo, just that it makes no sense in practice, and we shouldn't demo it.

[smhigley]

btw, @mcking65 and @carmacleod what do you think of the first combobox in this codepen?: https://cdpn.io/smhigley/debug/gObMVzv

It currently only responds to one character at a time when typing, but that could be easily changed, with a reasonable timeout.

[carmacleod]

what do you think of the first combobox in this codepen?

It's very nice, but you need to add "Blueberry", and then "bb" needs to go to Blueberry. :)

[shleewhite]

I'm super on board with the idea of a select only combobox.

@mcking65 I like the solution you proposed! I made a codepen example: https://codepen.io/shleewhite/full/dyoXqgQ

[sinabahram]

Cool demo on this select-only concept.

Just to point a few things out:

This is far less accessible than a regular select for keyboard users. No first-letter navigation exists, which means that a list of 55 items will take forever to scroll through.

There’s also no ordinality conveyed on the items in the combobox, only when exploring outside of it in the list that is after it. Sometimes, I got multiple items to appear in that proceeding list, not sure how to replicate. Same for up-arrow stopping to work, but can’t replicate reliably.

I have a question about this, but also the other examples. Why do all of these examples expose the list afterwards? This is very verbose from a screenreader perspective and I argue harder for novices that now interact with two distinct elements, but all of which are one UI component. Is it possible to have aria-hidden on that list?

In my opinion, the perfect example of any of these, editable or otherwise, is one component for the screenreader user to interact with, a combobox. Whether it’s editable, sortable, disabled, whatever, there should just be one thing, but maybe I’m missing another reason?

The above was with Jaws 2020 and latest Chrome, and I love that you did this as a way for us to talk about it, so thank you very much.

[curtbellew]

I'm very on board with this. I just wanted to reiterate what I said in the call today. The big issue we have when we try to use the combobox role on a div is how to get the current select value read out. There doesn't appear to be a way at this point to set the value in the accessibility tree when you use a div. Love the examples above from code pen though.

[a11ydoer]

@smhigley provided code pen example https://codepen.io/smhigley/full/gObMVzv

[sinabahram]

A few observations about the read-only combobox. All are with Jaws 2020 and latest Chrome.

Before I begin though, this is some excellent work. Seriously, we’ve got timeouts on multiple letters being entered, ordinality announcement, the whole nine yards, so props!!!

1: Pressing a letter that does not correspond to the first letter of any item in the box, results in the first item being highlighted, which is not expected behavior to me as a screen reader user. If I hit ‘k’, and nothing starts with ‘k’, either nothing should happen, or an optional system bell or tone goes off and then nothing happens. Either way, the first item should not be selected.

2: when I hit down arrow, the combobox expands, but this feels weird to me, because why bother? I understand if I want to expand it, I can do so with alt+downArrow, but I don’t need to do so as a screen reader user, so this breaks muscle memory patterns because a native combobox allows me to focus it, and then just hit down arrow to move to the next item, but this one has this expanded/collapsed state first, which I think is confusing. Not exactly to me, but it just doesn’t feel like a native combobox.

3: There’s no way to remove my selection. Is this intentional? If so, it’s fine, but if the question is required and this control is used, then I argue there “must” be a way to unselect, or to go back to no selection, because otherwise, one is forced to make a choice by default, just to use a survey context as an example.

Again, though, hat tip.

The editable combobox breaks more expectations. That one may be easier to talk through by voice? I’m willing to hop on a Zoom call, share my screen and even TTS output, and drive this with Jaws and NVDA across Firefox and Chrome if that is helpful to anyone. It currently doesn’t announce characters being erased, backspace returns to the first item, the way to edit is a bit unclear, etc.

[carmacleod]

@aleventhal forked @smhigley's codepen in https://github.com/w3c/aria/pull/1225#issuecomment-611492852
Here's that fork: https://codepen.io/aleventhal/pen/MWaWpbb

[smhigley]

@carmacleod Aaron actually forked a different codepen that I'd made to test browser support for different ways of calculating value. It has some semantic differences and missing behavior from the one linked above; I think the first combo in the pen linked here is still the most canonical reference till the PR is ready :)

[smhigley]

@sinabahram thanks for the thorough review! I'll try to respond in order below:

1. Fixed, thanks for noticing that! I don't think there's any way I can add a system bell, but now typing a not-found letter or string will not change options
2. This one is interesting! Particularly since the down arrow behavior on a native <select> varies by operating system. I had chosen this particular behavior because Windows & macOS don't agree on whether the listbox should open on down arrow, so my tiebreaker was matching the behavior of our other combobox examples. I wrote a bit more about system inconsistencies in <select> behavior (among other things) here: https://www.24a11y.com/2019/select-your-poison/. I'm certainly not opposed to switching, though we'd likely need to document why this example differs, or revisit that behavior in other examples.
3. It is intentional that there's no way to completely remove a selection. Even in the pre-interaction state, the first option is selected by default (which matches native <select> element behavior). However, if you open the listbox and arrow around, then hit Escape, it will revert to the prior selection.

The editable combobox in that codepen isn't part of this issue or PR, but I'd personally be interested in your feedback! Probably not in this issue thread, though :)

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed Select-only combobox.

The full IRC log of that discussion

<carmacleod> Topic: Select-only combobox

<carmacleod> github: https://github.com/w3c/aria-practices/issues/1026

<carmacleod> sarah_higley: still adding tests

<carmacleod> sarah_higley: doc changes are still rough

<carmacleod> sarah_higley: ready for functional and accessibility review of example itself

<carmacleod> mck: anxious to get this in and tested

<carmacleod> jongund_: simon had feedback on datepicker high contrast mode - is it ok to not have a border in HCM and just have border for date that has focus?

<carmacleod> jongund_: if anybody has any ideas for this, please let me know

<carmacleod> carmacleod: the Windows date picker doesn't have grid lines - there's a border only on the current date

<carmacleod> sarah_higley: sina had a comment on the down arrow behavior on the select-only combobox

<Jemma> https://github.com/w3c/aria-practices/issues/1026#issuecomment-588023657

<Jemma> https://github.com/w3c/aria-practices/issues/1026#issuecomment-610575881

<carmacleod> mck: right now, down arrow - if you don't automatically select - just makes it possible to navigate the list without changing the value

<carmacleod> mck: if you press Esc, it goes back to the previous value

<carmacleod> sarah_higley: the windows combobox doesn't do that, but I added that behavior because people prefer it in usability studies

<carmacleod> sarah_higley: if you press down arrow and then tab, it changes the value

<carmacleod> mck: it would be good to add a "Choose a value" option as the first option

<carmacleod> mck: I will respond to comment 2 in 1026

<carmacleod> jamesn: was just playing with it - the typeahead seems ok until you hit a wrong letter

<carmacleod> sarah_higley: I was trying to decide what to do there - if you type 2 letters and the second one is wrong, you don't want to jump somewhere else

<carmacleod> mck: maybe try cancelling the timeout

<carmacleod> sarah_higley: that might work

<carmacleod> mck: and making an "error" sound

<carmacleod> sarah_higley: not sure if that's possible?

<carmacleod> carmacleod: you used to be able to print ^G to do system beep

<carmacleod> sarah_higley: would be better to trigger an error or notifications api event or something

<Jemma> mck: I wish I could work on aria-live

<Jemma> james: I wished the screen magnifier developers would work on this error alert on top of aria-live.

<Jemma> s/of aria-live/with aria-live

<Jemma> the solution for James testing is ...

<carmacleod> sarah_higley: I still have to add tests

<carmacleod> mck: simon can review tests when you say they are ready

<carmacleod> rrsagent, make minutes

<RRSAgent> I have made the request to generate https://www.w3.org/2020/05/05-aria-apg-minutes.html carmacleod

<Jemma> https://github.com/w3c/aria-practices/issues/1392#issuecomment-623282227

<carmacleod> rrsagent, make minutes

<RRSAgent> I have made the request to generate https://www.w3.org/2020/05/05-aria-apg-minutes.html carmacleod

<carmacleod> rrsagent, make minutes

<RRSAgent> I have made the request to generate https://www.w3.org/2020/05/05-aria-apg-minutes.html carmacleod

<carmacleod> regrets+ Mark_McCarthy

<carmacleod> rrsagent, make minutes

<RRSAgent> I have made the request to generate https://www.w3.org/2020/05/05-aria-apg-minutes.html carmacleod

[jamime]

2: when I hit down arrow, the combobox expands, but this feels weird to me, because why bother?

I think this is also true for the Printable Characters neither Windows or MacOS opens the dropdown on the native Select.

It would be great to see this behaviour of the following explicitly defined in a spec not just the example.

1. Arrow Keys Should they opening open the dropdown?
2. Arrow Keys If they open the dropdown, should selection should move with the first keypress?
3. Printable Characters Should they open the dropdown?
4. Printable Characters Should they work when the dropdown is closed?
   I raised https://github.com/w3c/aria-practices/issues/1412 to discuss these issues before I knew of this PR.

I've found this behaviour differs between Windows, MacOS and the APG Example.

@smhigley your articles provided a great insight on this subject 👏