aria-checked on option and treeitem

[smhigley]

The option role includes aria-checked in supported states and properties, which inherits into treeitem.

Since aria-selected exists on both and already indicates selected state, it's unclear what additional meaning aria-checked could convey. E.g. is there a use case for either of these currently valid option states?:

<div role="option" aria-selected="true" aria-checked="false">Selected, but not checked</div>
<div role="option" aria-selected="false" aria-checked="true">Unselected, but checked</div>

If not, I believe it should be removed from option (and treeitem). I've already run across the above markup (odd as it seems) in a product. It resulted from some confusion reading the ARIA spec and thinking aria-selected indicated current focus and aria-checked indicated selection, so updating to a more strict set of allowed attributes seems beneficial.

[jscholes]

@smhigley

I think for your third example you could easily leave off aria-selected entirely, and just use aria-checked + focus/activedescendant.

I don't disagree in theory. I don't believe assistive technology support for such a pattern to be very good (although I would have to carry out exhaustive testing). The main issue is that at present, I would be going directly against the v1.2 Combo Box and List Box patterns in the APG.

For Combo Box:

For a combobox that controls a listbox, grid, or tree popup, when a suggested value is visually indicated as the currently selected value, the option, gridcell, row, or treeitem containing that value has aria-selected set to true.

For List Box:

In a single-select listbox, the selected option has aria-selected set to true.

It would certainly be a concern if there was no visual indication of which box a user would be checking and not checking, so aria-selected would still be needed in addition to aria-checked. If web authors must actively go against the APG to create the sort of pattern I've described, then that would be an argument for clarifying the attribute usage which seems to be the aim of this thread.

[smhigley]

@sinabahram I also have never come across a tree that has dual checked/selected state, so no, I don't have examples of that :). The basic problem I keep trying to raise is that having two separately controlled on/off states on the same item is not usable or understandable on a basic level.

@jscholes if you're using aria-checked instead of aria-selected it would already be a break from the APG examples, which seems completely fine if you've found an approach you think is better. Adding aria-selected to the currently focused option still would not be following the quoted description in the APG, since it would not be applied to the selected option, it would be applied to the current point of regard.

As far as AT support goes, I have not found any difference in support for focus/activedescendant when aria-selected is absent, nor have any effect on support for aria-checked. If anything, having aria-selected in addition to aria-checked is actively worse for that pattern, because you get confusing announcements like "selected, not checked." If you want to have checked semantics for a multiselect, the best implementation would likely be to leave off aria-selected entirely.

[craigkovatch]

So far we only have one very flawed real world example of this from Tableau, which on further investigation doesn't even use mixed aria-selected/aria-checked.

@smhigley You are right that the current public code is (even worse than previously described) a listbox container with checkbox items. This was a historical mistake of chasing screen reader behavior, rather than implementing a proper spec, and it's on me to fix it. My plan of action is as-described above. This is why I keep asking: if option+checked+selected is not the best way to expose this to AT, what is? I certainly don't want to ship something that the spec will soon drop -- but I don't see any alternatives yet. I have separate work pending on me to implement another multi-select listbox (without the weird pattern! 😁 ) which needs to also work inside of a dropdown, so this discussion is triple-relevant to me right now.

I want to bring up again that no one has been able to find another real-world example of dual state yet. I do want to establish whether there's actually a real-world use case for this, [...] we only have one very flawed real world example of this from Tableau having two separately controlled on/off states on the same item is not usable or understandable on a basic level.

This is very frustrating. I have provided a real-world use case. I'm struggling to understand why you're dismissing this as a case that somehow doesn't count. Hundreds of thousands of people use this control every day. They apparently use it and understand it just fine. It's admittedly a weird, quirky pattern. I concede again that it is not best practice, and I'm not asking anyone to like it or approve of it. But I don't understand why it being "flawed" disqualifies it as an "actual" case for this discussion. (Especially as @sinabahram has confirmed it aligns with his expectations, I don't think I'm being too crazy here 😞)

I'm trying to do the best thing by our users, making it better for everyone. And thus trying to provide the feedback on this Issue that at least one real-world example does want to use this. I'm frustrated that it has several times now been suggested that the onus is somehow on me to find more examples for code that neither I nor my company owns. I'm frustrated at your suggestion that ours is not "an actual real-world use case". Why?

[craigkovatch]

@scottaohara I am really surprised to hear you say that Material example is "not a listbox". What is it? I'm asking about its conceptual function, not about it's current markup. I don't see how it could be described as anything but a multiselectable listbox with interactive children (which is why I first posted it, since @joanmarie had raised the question of whether allowing those in option should be reconsidered). I'm not clear on what you mean by "clickable nonsense div" but my assumption is that it only feels like nonsense since it's a demo page and not wired up to anything real.

[stes-acc]

Much of the confusion comes from the fact that we are talking about different things here.

Items could be flagged (="somehow checked") as a result of a previous operation on the dataset. In a subsequent step, some of them are to be selected for further operation.

The problem is that the "checked" checkbox visuals almost cry for setting a "checked" state, which is not appropriate sometimes.

In my opinion, the "checked" state should not be used for such "preselection", we would need a custom new attribute for that or indicate such a flagged state using aria-description which would be way better.

Accepting that would render the entire discussion above obsolete IMHO.

[scottaohara]

@craigkovatch

I am really surprised to hear you say that Material example is “not a listbox”. I don't see how it could be described as anything but a multiselectable listbox with interactive children...

Why? I'm not going to call it what it isn't. It’s a list (<ul>) of checkboxes and buttons. This is a pretty common pattern that doesn't touch on what we've been talking about. “Conceptual function” isn't applicable because then we're using a real example with different functionality to validate an argument for something it isn't. Two separate controls, no keyboard behavior similar to listbox > options, exposed to assistive technologies differently. Apples and pumpkins comparison.

If you want to go the route of saying they are visually similar looking... sure? But that can be said for many types of custom controls and content on the web. How it behaves and is exposed, e.g., an example of a selected and checked state for an option in the wild, is what matters here if we're to stay on topic. So, this example doesn't belong here.

And no, I mean “nonsense div” because it’s a div with a tabindex=0, no role, no accessible name (not directly at least, one will be cobbled together from its children), and a click event on it that triggers the nested checkbox which has been set to tabindex=-1. Screen readers/browser pairings all announce this pattern differently due to the current setup / them attempting to mitigate the awkward markup (some relatively fine, some with duplicate announcements of the content within, depending on your navigation method).

[jscholes]

In my opinion, the "checked" state should not be used for such "preselection", we would need a custom new attribute for that or indicate such a flagged state using aria-description which would be way better.

I disagree on both accounts. A new attribute would need to either have custom support in assistive technologies or map to an existing semantic in accessibility APIs across platforms. Not an easy or guaranteed feet. aria-description and aria-describedby are also not intended for surfacing state which should be semantically conveyed, and would introduce all sorts of problems like the inconsistent announcement of an accessible description by screen readers, a user's ability to turn it off, etc.

Regardless, I'm curious what you propose using as either a new attribute or text for aria-description? What could we tell usres that isn't already perfectly conveyed by checked/not checked, states users are completely familiar with?

[stes-acc]

In my opinion, the "checked" state should not be used for such "preselection", we would need a custom new attribute for that or indicate such a flagged state using aria-description which would be way better.

I disagree on both accounts. A new attribute would need to either have custom support in assistive technologies or map to an existing semantic in accessibility APIs across platforms. Not an easy or guaranteed feet. aria-description and aria-describedby are also not intended for surfacing state which should be semantically conveyed, and would introduce all sorts of problems like the inconsistent announcement of an accessible description by screen readers, a user's ability to turn it off, etc.

Regardless, I'm curious what you propose using as either a new attribute or text for aria-description? What could we tell usres that isn't already perfectly conveyed by checked/not checked, states users are completely familiar with?

Misunderstanding. We still have selected state but preselection means flagging with another info. The actual value for aria-description flag depends on that, it could mean "shipped to customer". These custom attributes are VERY common in business apps. But I won't use a checkbox in this case for visuals, designated "shipped" icons will do better here.

And in case you still dont' like aria-description used for that: give me a standardized thing in ARIA to express custom attributes. We won't have that until ARIA 2.0.

[jscholes]

it could mean "shipped to customer"

I understand what you're getting at, and aria-checked or aria-selected would absolutely not imply "shipped to customer". If either of those was ever used to indicate such state, it would be a pretty confusing UX. But I don't think that negates the usefulness of aria-checked and aria-selected in other cases which aren't highly domain-specific.

[carmacleod]

I've been trying to think of an example that would use both aria-checked and aria-selected. Perhaps this one will qualify.

Please note that:

• this example only exists as a thought experiment (I am not aware of any actual implementation)
• multiselect mouse/keyboard interaction would be intended for power users
• it relies heavily on context menu and/or app-specific shortcut keys and/or action/toolbar buttons (i.e. buttons/toolbar external to the list)

Imagine a To Do list.

• "checked" on an item means "done"
• mouse/keyboard user can select multiple items in the usual ways
• mobile/touch user has an "Edit" button that puts the list in a mode that allows them to select multiple (i.e. tap selects/deselects)
  • a set of action buttons (or a toolbar) is available in edit mode
  • user cannot check/uncheck with tap when in edit mode, but they can use use "mark done" and "mark not done" buttons
  • when not in edit mode, tap checks/unchecks items (i.e. does not select/deselect)
• once multiple items have been selected,
  • mouse/keyboard users can use context menu or shortcut keys to choose an action
  • all users can use action buttons/toolbar to choose an action
  • possible actions might be "move up", "move down", "priority", "due date", "remove" (which can have delete key shortcut)
• whether or not to support space key to toggle "checked" state when there are multiple items selected would be up to the design
  • might want to only support if one item is selected, or if multiple items with the same checked state are selected
  • if space is not supported (probably even if it is), then actions for "mark done" and "mark not done" would be in the context menu/shortcuts/toolbar

Another example (same interaction, different use case) might be a list of breakpoints, where "checked" means "enabled". User can select multiple to "enable", "disable", "delete", "export", etc.

In these thought experiments,

• the "checked" state is permanent, likely saved somewhere in the app. It takes an explicit user action to change it.
• the "selected" state is transient, and is only used to indicate the set of items that will participate in an action. The "selected" state changes as soon as the user changes their point of regard.

I'm not saying this is necessarily a good design. The app would want to make it clear, either through documentation, labelling or describing, that "checked === done" and "selected === ready for action".

Space key requires extra design thinking because if the user selects some checked and some unchecked items and hits space, then what? Error message? Toggle anyhow? Always check? Do nothing? I'll let the design team decide what makes sense for the app. :)

[mcking65]

@jscholes wrote:

As a practical example, the sidebar on this GitHub issue contains several "dropdowns" (for lack of a better term) for applying assignees, labels, etc.

James, That input in the side bar shouldn't be a combobox because when you choose an item from the list it is not setting the value of the input. A combobox is an input that has a popup that helps set the value of the input. Choosing items in the popup should close the popup and put that value into the input.

The edit field that appears with the label chooser in GitHub is simply a filter. It filters what appears in the list of tags. That list is basically a multi-select listbox where selection means that tag has been applied to the issue.

Since the tags chooser widget is a multi-select, selection should not follow focus. Instead, the user moves focus to a tag and should then press space to toggle the selected state. In that implementation, it is also perfectly valid to use aria-checked instead of aria-selected to represent the state of the tag. There is no need for both. Personally, in multi-selects like that, I prefer aria-checked. For some reason it seems more clear to me. But, I probably only have that bias because of my background. I would strongly suggest using aria-checked if the state is visually represented with a check mark.

I believe the most appropriate ARIA patterns for the GitHub label chooser are a disclosure button that shows/hides the filter textbox and a multi-select listbox. Three very simple patterns that are all well-supported -- nothing tricky.

At this time, it is using a menubutton and a menu ... and it does not work well. That combination could possibly work without the filter. But, ARIA does not support textboxes inside of menus.

[jscholes]

@mcking65

That input in the side bar shouldn't be a combobox ... That list is basically a multi-select listbox

Agreed on these semantics. But they would still need to use aria-checked on role="option" in a list box implementation.

In that implementation, it is also perfectly valid to use aria-checked instead of aria-selected to represent the state of the tag. There is no need for both. Personally, in multi-selects like that, I prefer aria-checked.

We also agree on this. But I don't believe the support for aria-checked on role="option" to be in a good state across assistive technology. That is, of course, not the direct responsibility of the ARIA Working Group or APG Task Force, but it's also not surprising given the focus on aria-selected in virtually all discussions of list boxes.

For example, with NVDA/Chrome, a checked state is announced but not an unchecked one, meaning that users have no idea they can toggle the current item. On MacOS with VoiceOver, neither checked nor not checked are announced. So while the pattern may be valid, it would be irresponsible to actually suggest that anybody implement it.

Again, I'm mindful of the title of this issue, aria-checked on option and treeitem. In the first post of the thread, @smhigley asserted the following:

I believe it should be removed from option (and treeitem)

(where "it" refers to aria-checked). If having aria-checked on both of these roles is valid, and a pattern that should be recommended to web authors once assistive technology support is improved, then the actual matter under discussion is whether aria-selected and aria-checked should be allowed in tandem, not whether aria-checked should be removed from option and treeitem. I can forgive AT developers and web authors not having consensus when this issue exists suggesting it should be removed entirely from these roles.

[craigkovatch]

@jscholes

For example, with NVDA/Chrome, a checked state is announced but not an unchecked one, meaning that users have no idea they can toggle the current item. On MacOS with VoiceOver, neither checked nor not checked are announced. So while the pattern may be valid, it would be irresponsible to actually suggest that anybody implement it.

That sounds like some bugs need to be filed on screen readers, then 🙂

[jscholes]

@craigkovatch

That sounds like some bugs needs to be filed on screen readers, then

I agree. But the aim of this thread seems to be to make a determination about whether aria-checked is valid on role="option" and role="treeitem". It would help in making a case to AT developers if consensus was reached here, given that the thread is proposing disallowing it altogether.

To be clear, I have an interest in aria-checked being consistently supported by AT. I agree with the assertions that having dual-toggleable checked and selected states on something could be confusing, although can see a place for it in a specialised UI. But I also feel that the core question being tackled here has been lost and overrided by, should we allow aria-selected and aria-checked, together? I don't think the answer to that question is to disallow aria-checked on option and treeitem.

@smhigley What are your thoughts? In the first post of this thread, you wrote:

updating to a more strict set of allowed attributes seems beneficial

But in response to my GitHub sidebar example, you wrote:

you could easily leave off aria-selected entirely, and just use aria-checked + focus/activedescendant.

These two don't necessarily work together, if you're proposing that aria-checked be disallowed on option and treeitem. So the answer seems to be, allow aria-selected and aria-checked, but in a mutually exclusive relationship.

[smhigley]

For use during the call today, I put together a working example of each of the patterns we've been discussing: https://quirky-meitner-4a68e8.netlify.app/. I added an alert() to simulate the idea of something "happening" on check/uncheck for the first one, and on confirmation for the second.

@jscholes I know the original proposal was to disallow aria-checked on option (I think treeitem has been pretty thoroughly dropped by now), but I think it would also make sense to specify that checked and selected can't co-exist (what Leonie suggested much earlier: https://github.com/w3c/aria/issues/1052#issuecomment-536018316). That would solve the issue where devs confuse selected with point of regard, and accidentally implement both :).

[cookiecrook]

I mouse clicked the first checkbox, then after clearing the JS alert, shift+clicked the fifth, resulting in this:

I'm not sure why there is a both a multi-selection state and a multi-checked state. What does this UI mean: to have multiple selections here that are different from the multiple checked states?

[jscholes]

@smhigley Thanks for clarifying your position and the samples. Will this URL remain active so that it can be used in AT/browser bug reports if necessary? Or can it be forked?

Everyone will have a different dog in this fight based on what they need to support, or would like/participate needing to support in the future. I've made it clear that my priority is consistent support for aria-checked on option and treeitem, because I find it to be a useful paradigm in many UI patterns, and have encountered a number of client requirements which couldn't be properly semantically supported because of the current lack of consistency. I am satisfied that many other people here seem to feel the same.

Having said that, it is my strong opinion that web authors should not be constrained based on what the ARIA Working Group believes to be a usable or pertinent pattern. We've all been around the block enough times to know that if a web or native control doesn't provide exactly what a web author or other stakeholder feels is required, somebody will invent their own. ARIA exists to ensure that, good or bad ideas aside, users of assistive technologies can at least be supported or taken into account. If the users of that pattern find it to be frustrating, inappropriate or even blocking, it is for them to raise that with their employer or other applicable entity, and not for the ARIA Working Group to dictate what should be done. That's my understanding, anyway; happy to be corrected!

Anecdotally, I would happily implement a dual-state list box or tree view if I could guarantee accessibility or the availability of training for the target audience, particularly if one of those states was a convenience factor and not strictly necessary to complete a task. For instance, inside an accessibility test reporting tool, I may want to claim that an issue fails multiple contiguous criteria. The checked state would determine whether a given criterion was applicable, but it would also be helpful to be able to press Shift+Down Arrow a few times and check all of the selected criteria in one go. Necessary? No. But certainly helpful.

I understand that there are concerns with a UI like the one outlined above. It may be extremely difficult to make accessible for speech recognition users, and surfacing the dual state visually without relying on colour alone may be a challenge. But real-world constraints mean that somebody may implement such an UX regardless, and we shouldn't deny support for their endeavours purely from an ARIA perspective. When we work with them on a voluntary or professional basis as accessibility practitioners, or provide them with feedback as customers, that's when fundamental design concerns can be raised.

[stes-acc]

There was a question why we have selected AND checked states for treeitems.

I remember having "checked" on treeitem to reflect mixed states like for example in MS software installation trees like below:

[*] All

• [X] Item 1
• Item 1
• [X] Item 1

You can't map that properly with selected state. And selected was in because every tree item is selected implicitly when focused as list definition says.

[jscholes]

@stes-acc I think GitHub's Markdown renderer interfered with what you were trying to convey there, but an installer is certainly a great example of where aria-checked on treeitems and options is useful and familiar to users. I don't know how aria-selected would enter into the equation; there is some related discussion over on https://github.com/w3c/aria/issues/1311 where at @carmacleod correctly pointed out:

NVDA verbosely says "not selected" for every treeitem with aria-selected="false"

If this is also the case for items with no aria-selected application whatsoever, it would be an argument for aria-selected to follow focus inside an installer, with aria-checked being used to opt in/out of specific items.

[mcking65]

@jscholes wrote:

If this is also the case for items with no aria-selected application whatsoever, it would be an argument for aria-selected to follow focus inside an installer, with aria-checked being used to opt in/out of specific items.

If aria-checked is used to indicate the opt in/out state in the installer, why would selection follow focus? Why should there be a selected state at all?

[jscholes]

@mcking65

why would selection follow focus? Why should there be a selected state at all?

I agree that there shouldn't need to be. My comments were specifically in line with those over at the related issue (#1311) where it was pointed out that there is currently confusion about when aria-selected is and is not required, which is in turn causing assistive technology support to be inconsistent. And in NVDA's case, overly verbose to the point where I could not, in good faith, tell somebody to only use aria-checked in a tree.

[jscholes]

Also note: the verbosity of NVDA was explicitly observed for treeitems with aria-selected="false". I noted in my comment:

If this is also the case for items with no aria-selected application whatsoever

In other words, if NVDA announces "not selected" for every treeitem with no aria-selected attribute, assuming the value of a missing attribute to be "false", selection would need to follow focus right now to make for a pleasing speech and braille experience. This may not be the case and would need to be tested.

[smhigley]

@jscholes wrote:

Will this URL remain active so that it can be used in AT/browser bug reports if necessary? Or can it be forked?

I'll probably be experimenting a bit with that URL, so it's not the best to use to file bugs. If you want, the source code is here: https://github.com/smhigley/aria-mocks. You don't really need a working example like this to file bug reports, though; just some static HTML with the roles/attributes should be plenty.

The issue here is still the conflict between checked and selected. Asking authors to always set selected to the currently focused item is not a good spec solution as @mcking65 mentioned, since selection is conceptually not the same thing as focus. You're also not consistently reducing verbosity by setting it, since multiple screen readers will read the selected state in addition to not selected. VoiceOver will even only read "selected" but not "not selected," so there isn't really even a good practical workaround there.

re the ARIA spec adding constraints to authors: there are plenty of constraints already in the spec. Most of the characteristics table directly deals with adding constraints; aria-checked is not supported on tab items, for example. This isn't really about opinions on whether the pattern is subjectively good or bad, the issue here is that logistically, especially for options, checked is poorly defined, inconsistent, and poorly supported. It's also not just a matter of pushing browsers and screen readers to add support; the desired behavior is not even defined in the spec.

[mcking65]

@smhigley, @aleventhal, and I have been meeting offline to work on proposals that we hope will lead to consensus.

I have started to draft some language in PR #1340. Keep in mind, this is draft that is inspired by on-going conversation; it does not represent conclusions from that conversation.

In the spirit of looking for middle ground that avoids placing constraints on authors that might not be essential, here is draft authoring guidance for the option role that is included in the pull request.

The option role supports both aria-selected and aria-checked because it is common for authors to use selection in single-select list boxes and check marks in multi-select list boxes. However, authors SHOULD NOT specify both aria-selected and aria-checked on option elements contained by the same listbox except in the extremely rare circumstances where all the following conditions are met:

• The meaning and purpose of aria-selected is different from the meaning and purpose of aria-checked in the user interface.
• The user interface makes the mening and purpose of each state apparent.
• The user interface provides a separate method for controling each state.

I include a bit more color on the rationale as well as explanation of other changes in my comment in #1340.

[mcking65]

I think there may be an assumption underneath some comments in this thread that I'd like to bring to the surface in the hope that clarity about assumptions can help inspire understanding of differing perspectives.

I think the gist of the assumption is something like the following.

The ARIA specification should only allow for semantics that work for all users in any user interface. Or conversely, if some semantics could create problems for some users in some circumstances, then they should not be supported by the specification. Example: it is not advisable for the specification to support semantics that would be useful to users who can use a keyboard but impractical for users who rely on touch. Or, it is not advisable to support semantics that could create a user interface that would be problematic for users with cognitive disabilities.

I think the spirit of the assumption is good. But, I'm hesitant to endorse the ARIA specification as a tool for limiting authors abilities to serve a specific audience with a specific solution or even to enforce good design principles.

To use a building construction analogy, I've thought of the scope of ARIA to be most comparable to the specifications for building materials, e.g., it specifies the dimensions and load baring capacity of a specific truss. ARIA does not tell you how far apart you should space your trusses in a specific circumstance. For that, we turn to the building code -- WCAG. It is also important to recognize the limits of WCAG. If you were to design a home using a building code as your definition of good design, it would be unsurprising if the home were unliveable. For instance, you might find the toilet positioned between the kitchen stove and sink, and from what I know about private residential codes, most would permit it as long as spacing requirements are met.

[sinabahram]

I just want to express sincere gratitude to @smhigley, @mcking65, and @aleventhal for your work on this RE the above that Matt posted as a working summary. Also Matt, thank you for the clarification around purpose as that matches my original understanding of the ARIA specification.

[craigkovatch]

@mcking65 really appreciate the effort, commentary, and summaries here. Thank you and everyone else who contributed.

Would like to ask a clarifying question via scenario: say I have a combobox, with a multi-select listbox popup. DOM focus of course remains in the <input>, while "item focus" (AT focus? visual focus? what's the term of art here?) is indicated using aria-activedescendant. I have seen past posts from @smhigley which indicated that VoiceOver doesn't read aria-activedescendant updates unless aria-selected is also updated on the focused option. (Not sure if this is still current, I think I remember reading that ca. 2018.)

This is a scenario in which I would expect to use aria-checked (against my semantic instinct) to indicate "membership in the set of options which the user has selected", while using aria-selected + aria-activedescendant for indicating the "active" item for keyboard interaction. Does this track? Is there a better way? I think this still works within the draft constraints laid out, but seems like a useful case for the testing the assumptions of whatever gets drafted.

(Looks like this is exactly what SalesForce does in Lightning comboboxes, FWIW: https://www.lightningdesignsystem.com/components/combobox/#Multiple-selections)

[mcking65]

@craigkovatch wrote:

I have seen past posts from @smhigley which indicated that VoiceOver doesn't read aria-activedescendant updates unless aria-selected is also updated on the focused option.

This would be a VoiceOver bug. If it is still present, we'll catch it in the aria-at project.

However, this bug would only negatively impact a free-standing listbox. If a listbox is a combobox popup, selection follows focus so that bug would be inconsequential.

This is a scenario in which I would expect to use aria-checked (against my semantic instinct) to indicate "membership in the set of options which the user has selected", while using aria-selected + aria-activedescendant for indicating the "active" item for keyboard interaction. Does this track?

As of ARIA 1.2, combobox is a single-select widget. The value of the combobox is one item chosen from the popup.

If a future version of combobox were to support choosing multiple items for the value of the combobox, you would still only use either checked or selected, not both. The VoiceOver bug would have to be fixed if VoiceOver were to support a multi-select combobox.

I think this still works within the draft constraints laid out, but seems like a useful case for the testing the assumptions of whatever gets drafted.

The constraints in the PR would definitely permit a future version of combobox that supports multi-select. But, again, as described in the PR, you would use only checked or selected, not both.

As of today, it is not a useful test case because of current combobox constraints.

[craigkovatch]

@mcking65

As of ARIA 1.2, combobox is a single-select widget. The value of the combobox is one item chosen from the popup.

Reviewing https://www.w3.org/TR/wai-aria-1.2/#combobox, I don't see anything that speaks to this. Is this not yet reflected in the current Working Draft?

[JAWS-test]

I also think that the ARIA specification for combobox does not currently prohibit multiple selection. In the APG it becomes clearer that only one value can be selected. I.e. the specification should say here more clearly that multiple selection is not allowed.

In the future, multiple selection should be possible with combobox and I am in favor of implementing this as soon as possible. Many frameworks have been offering comboboxes with multiple selection for a long time now, but they all don't work well because the corresponding ARIA support is missing