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.

[scottaohara]

yeh. seems to me aria-checked on an option should not be a supported property?

i'm less familiar with treeitem allowances but do think it's weird to have both.

Interested if there's something I'm missing here though?

[accdc]

Hi, aria-checked is supported on the option and treeitem roles to support tri-state checkability using the "mixed" value, which doesn't exist using aria-selected. There are indeed cases where this is necessary, and it does map to equivalent roles within the accessibility APIs for both of these roles.
All the best,
Bryan

[smhigley]

I've run into the tri-state use case before, but I don't think that's a good reason to support both aria-checked and aria-selected. If anything, that seems to be a reason to remove selected in favor of checked.

If they're both supported on the same element, it seems to me that they would need to mean different things, and be able to be individually added to the option or treeitem independent of each other. If we go that route, there should probably be some definition of what it means if an option or tree item is selected but not checked, and vice versa.

[scottaohara]

agree with Sarah here. it's confusing that both are allowed, and anecdotally can say it's resulted in some issues I've seen where developers have argued they needed both.

I can think of situations where this might be necessary for tree items, so again, don't have as much of an opinion there. But less so for options where a more straight forward pattern of checkboxes / a single tri-state checkbox to indicate a mixed state wouldn't have been preferable. But, I'm interested in learning about patterns that would require a deviation.

[JAWS-test]

aria-checked: ... or represents a group of other elements that have a mixture of checked and unchecked values (mixed). https://www.w3.org/TR/wai-aria-1.1/#aria-checked

• I would remove aria-checked from option, because in my understanding no entry in a select list displays a checked status for child entries.
• For the same reason I would leave aria-checked at treeitem, because in a tree structure exactly this is possible. aria-checked should only be used if parent entries show the status of child entries. Otherwise aria-selected should be used. This is quite confusing, but I think the danger is that you suddenly invalidate currently valid implementations if you change that.

[accdc]

You can't remove aria-checked from option without breaking current implementations like the following one.
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Comboboxes/ARIA%20Comboboxes%20(Native%20Inputs,%20Multiselect%20Editable%20with%20Substring%20Match)/demo.htm

In this case, after typing a string like "hum" then pressing the down arrow to enter the listbox, the spacebar is required to toggle checkability. Implementing this using aria-selected doesn't work, I've tried this.

Option checkability is also used to indicate when all controls in a subsequent section are checked or selected, set to "true" if all are, "false" if none are, or "mixed" is some of them are. Whe have enterprise clients using this within complex UIs right now.

If you pull this out, it will break all of these.

[smhigley]

In general I think it makes sense to prioritize creating a clear and logical spec in the long term over maintaining support for all existing implementations, but in order to be considerate to existing implementations we could add a deprecated note and reserve breaking changes for major version changes.

Specifically regarding the use case you linked to: I'm not sure I understand why that's an argument for aria-checked over aria-selected on role="option". It seems like a case where aria-selected actually has better support. Using that link, I get some unexpected screen reader output: in JAWS/Firefox, I hear "not selected, checked", VoiceOver on iOS doesn't seem to read the checked state at all, and Narrator seems to have some unrelated issues that make it difficult to test.

I put together a quick example with aria-selected (https://www-ukpsneijli.now.sh), and I seem to be hearing the selected state correctly in JAWS and NVDA on FF and Chrome, Narrator on Edge/Edge Chromium, and iOS/VoiceOver. The only potential quirk is that both JAWS and NVDA read when an option is not selected and do not explicitly say "selected", but this matches behavior on native <select multiple> elements, so I'd consider that expected.

The mixed selection state does seem compelling to me for tree items, but I still think we shouldn't allow both attributes to coexist. If we do find a compelling reason to support both, we likely would need to define how both would map if they were independently defined on the same node.

[scottaohara]

yeh, can confirm the double state announcement quirk with Firefox+JAWS, as well as no selected items announced, regardless of how many are checked, with VO+Safari with the whatsock example.

Sarah largely summed up everything else I'd want to say here. Regarding noting something as deprecated, seems there's precedent.

[JAWS-test]

@accdc: For the example http://whatsock.com/tsg/Coding%20Arena/ARIA%20Comboboxes/ARIA%20Comboboxes%20(Native%20Inputs,%20Multiselect%20Editable%20with%20Substring%20Match)/demo.htm your explanation that aria-checked must be used because of the mixed status does not apply. Therefore I would also say that aria-checked should not be applicable at least for option, but possibly for treeitem

[mcking65]

In general, we try to avoid putting limitations into the ARIA spec unless they are necessary. This is because we cannot anticipate every possible use case.

There are definitely use cases for both listbox and tree where checked is a more appropriate semantic than selected and vice versa. Ruling out either semantic is not really a necessary limitation.

I think there might be a potential argument for not allowing both at the same time in the same widget. However, is that something that should be warned against or prohibitted? Is it really the case that there is not a scenario where both could be useful?

Imagine a scenario where the checked state represents a persistent state that gets stored. And, in the same list or tree, there may be operations that can be performed on the items, e.g., remove, move higher in the list, etc. The selected state could represent selection for operation while the checked state represents the persistent state of the item. Maybe the instructions say check all items that you want stored offline. Additionally, you could manipulate the order of items. So, you could use standard selection keys to select one or more items for an operation like move up.

I am not convinced that putting a prohibition in the ARIA spec is appropriate in this case. Perhaps a middle ground approach is to consider an "authors "MAY" statement that says they "May" use both but "SHOULD" be careful to ensure users are able to discern the meaning of each state.

We can also add clarifying information to the guidance for aria-checked and aria-selected in the APG.

[scottaohara]

In HTML option elements do not allow the checked state/attribute. In regards to parity with the host language, I do not understand why aria-checked would be allowed (in HTML) as it would create a deviation from native behavior, and allows for the introduction of author and potentially user confusion.

Please don't take this as an argument to me not understanding there being a potential use case to indicate that some / all / none of the options within a listbox have been selected. I just question if this is the way to do it, again noting that even the provided example doesn't expose this information consistently.

That said, if such allowances for both states continue then I would fully agree with your mentioning of a middle round, as I do think the specification should document why this diverges from HTML, and guidance of when both states would be appropriate could then make it's way into APG.

[accdc]

Hi,
Regarding role parity, there is a checkable listbox windows class, which is what aria-checked already ties into on the Windows OS going back many years.
https://docs.microsoft.com/en-us/dotnet/api/system.windows.forms.checkedlistbox?view=netframework-4.8

This is true in UIA as well, and can be seen every time you open My Documents. If you look at the accessibility tree properties for every item listed there, you will se a checkable state option on each option listed.

[smhigley]

@accdc it's an interesting example, but I'm not sure WinForms is the best framework to use as a blueprint going forward. Here's the same control in UWP, where you can see selection is handled with the SelectionPattern, and not the TogglePattern: https://docs.microsoft.com/en-us/windows/uwp/design/controls-and-patterns/listview-and-gridview#item-selection-and-interaction. For context, WinForms (or Windows Forms) is an older framework and its UIA support is less robust than the newer WPF or UWP. It might also be worth noting that aria-checked is not currently mapped to anything in UIA or AX API for either option or listbox in Edge or Safari.

Regarding Matt's suggestion that we continue allowing both checked and selected:

I'm still concerned about allowing both aria-selected and aria-checked on the same element. For one, how would a user toggle each property separately? Even if there were a custom keyboard shortcut that could be communicated to screen reader and keyboard users, would it be possible to support switch devices or touch-based screen readers?

I've actually run into real-world use cases where tree items were both selectable and supported actions like move, delete, edit, etc., but none of those were implemented using dual checked/selected states. I don't think that's a good use case for needing both properties supported at once, since more usable implementations already exist.

I feel like maybe I could use some clarification on what would make a limitation necessary vs. not necessary. From my perspective, the risk of developer confusion and misuse combined with a lack of practical support are a compelling reason to limit this in spec, though I'm not sure how that matches up to a bar of necessary. Should we also be applying that bar to revisiting whether e.g. prohibiting dual checked/selected states on tab or a treegrid row is necessary?

[LJWatson]

Part of the problem seems to be that both attributes can be used without constraint. Enabling something to be simultaneously selected and unchecked (or vice versa) seems like something we should avoid.

Unless we can find a reasonable number of production examples in the wild, where there is a clear case for needing both attributes simultaneously, I suggest we make it a clear requirement that only one of these attributes can be used at a time.

[smhigley]

Just as a bit of a reality check, this is code I ran across today in a popular third-party UI framework that makes grand claims about accessibility (ids, classes, and text modified or removed so as to not call anyone out):

<li role="treeitem" aria-checked="true" aria-selected="false" aria-expanded="false">
  <div>
    <span role="presentation">
      <input type="checkbox" tabindex="-1">
      <label role="checkbox" aria-checked="true"></label>
    </span>
    <span>tree item text</span>
  </div>
</li>

Obviously they haven't implemented the treeitem well, and on some level we can't control that. On the other hand, this is actually a pretty tame misuse of ARIA compared to what I come across daily. When I'm able to ask the original developer why those choices were made, it's often "I saw this was supported in the ARIA spec" or "I saw this in the APG."

I know it's not our job to prevent developers from abusing ARIA or using APG examples without testing support, but I would really love to see the spec move to where a developer who has no specialist knowledge or context making a good-faith effort can take it at face value and end up with something reasonably accessible.

In this specific case, I think adding a requirement that aria-checked and aria-selected cannot both be present within the same tree, and removing aria-checked from option would aid in that without limiting any known or likely future valid use cases.

[craigkovatch]

Imagine a scenario where the checked state represents a persistent state that gets stored. And, in the same list or tree, there may be operations that can be performed on the items, e.g., remove, move higher in the list, etc. The selected state could represent selection for operation while the checked state represents the persistent state of the item. Maybe the instructions say check all items that you want stored offline. Additionally, you could manipulate the order of items. So, you could use standard selection keys to select one or more items for an operation like move up.

Here is a real-world case in Tableau where we have a listbox with options that are both checkable and selectable, just as you've described:

  listbox name="Year" aria-multiselectable={true}
    option name="(All)" aria-checked={false} aria-selected={false}
    option name="2014" aria-checked={true} aria-selected={true}
    option name="2015" aria-checked={true} aria-selected={true}
    option name="2016" aria-checked={true} aria-selected={false}
    option name="2017" aria-checked={false} aria-selected={false}

In this case, three of the five options are checked, which indicates the user wishes to filter on those three years. Two of the options are selected, which allows a user (via either mouse or keyboard) to batch-toggle a large number of items.

To answer @smhigley's question about how the toggling works in this particular control -- selection follows focus, with SHIFT modifier expanding a contiguous range. Ctrl-click is supported for creating non-continguous selection ranges, which is unfortunately not available for keyboard users but follows the legacy behavior of this control in our pre-web product. SPACE toggles the checked state of any/all selected items. For a mouse user, clicking the check box toggles checked state, while clicking the label text changes the selection state.

Not saying this is perfect, but I present it as an "in the wild" example of a listbox that uses both properties. If there is another pattern that would be better for representing this, I'm happy to hear about it -- I will be the first to admit that it's weird to have a multi-select listbox whose "really actually selected items" are checked rather than selected. But this seemed like the sanest of the ARIA primitives available.

[craigkovatch]

Speaking of "in the wild" examples, here's a couple more:

https://a11y-guidelines.orange.com/web_EN/exemples/check-listbox/index.html

https://www.lightningdesignsystem.com/components/combobox/#Listbox-markup

[stes-acc]

Imagine a scenario where the checked state represents a persistent state that gets stored. And, in the

listbox name="Year" aria-multiselectable={true}
option name="(All)" aria-checked={false} aria-selected={false}
option name="2014" aria=checked={true} aria-selected={true}
option name="2015" aria=checked={true} aria-selected={true}
option name="2016" aria=checked={true} aria-selected={false}
option name="2017" aria=checked={false} aria-selected={false}

This is very common in Business UIs (Material selection scenarios etc,)

[smhigley]

Both the linked examples (Orange and Lightning) seem to be mixing up aria-selected with focus/aria-activedescendant. Using aria-selected to denote the current option is not correct ARIA usage, and is exactly the sort of misconception I think could be cleared up by disallowing both checked and selected at once. @stes-acc all the cases I've come across in common UI libraries fall into this bucket, so they're more of an argument for fixing this than leaving it as-is :).

@craigkovatch for your example, I am very interested in what keys a user would press if they were on e.g. the checked-but-not-selected "2016" option in your example if they wanted to a) uncheck, or b) select that option.

I'm also interested in how you communicate that separate keyboard interaction for checked vs. selected to the user, and also how you communicate the different in-app meanings of checked vs. selected. I don't even think this works visually -- as a sighted mouse user, if I'm able to separately check and select by e.g. clicking on the checkbox vs. the option name, I would have no idea which one I need to do in order to accomplish any given task. And then there's the added problem of awful pointer target sizes with a checkbox nested within a larger option hit target, and the problems go on...

I really think having multiple on/off states on any one item like this fails along multiple axes, and shouldn't be supported in the spec.

[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: #1052 (comment)). 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

• Item 1
• Item 1
• 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 #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