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.

[carmacleod]

@smhigley I agree completely that Orange and Lightning (good name for a band) are mixing up selection and focus, and they actually don't need to use aria-selected. I tried to make this clearer in https://github.com/w3c/aria/pull/1326 - please take a look. (Of course, an edge case came up that muddied the clarity a bit, but I think the new sentence will at least be somewhat helpful.)

I believe that in @craigkovatch's example, down arrow will select "2016" (or shift+down arrow will select "2014, 2015, 2016"), and then space will uncheck it (or, if shift+down arrow was used, space will uncheck "2014, 2015, 2016"). Another space would check again.

I think the idea would be to be able to batch up the filtering. I could see this potentially making a difference in the performance of the filtering code (i.e. only filter when things become checked or unchecked), e.g. the user could carefully select 27 contiguous and discontiguous years and then hit space to filter them all at once - which may involve only one round trip to a server or something like that.

Having multi-selection may also make it a bit more efficient for users to do "batch checking" by selecting first with typical mouse and/or keyboard multiselect actions, and then checking/unchecking many items at once with the space key.

Of course, if the checkmarks are just visual and are actually semantically identical to selection, then aria-checked would not be needed and the user's multiselect actions would cause the checking and filtering, which would be almost the same as having them as separate states... except for that performance thing.

I'm not saying that it isn't confusing to have selected and checked in the same container - it is. We should make sure the guidance is very clear about that, and ask authors to think carefully about their use case. We should also make sure to explain the concept that "focus does not equal selection". And we should tell authors to prefer aria-selected over aria-checked, even when their items have a checkmarky visual treatment. But I don't think we should make it a violation to have both.

@craigkovatch, please confirm my guess that down arrow selects and space unchecks, and please also let us know:

• is all of the keyboard behavior the same on Windows and Mac?
• is all of the mouse behavior the same on Windows and Mac?
• does Enter (aka Return) do anything on either platform?
• does mouse double-click do anything on either platform?

Thanks!

[craigkovatch]

Both the linked examples (Orange and Lightning) seem to be mixing up aria-selected with focus/aria-activedescendant.

@smhigley Agreed. But I think they are a strong illustration that even large engineering organizations from well-known companies are facing the same issues, and that whatever guidance is developed will need to speak to that confusion clearly and robustly.

I am very interested in what keys a user would press

@carmacleod's suppositions about the keyboard behavior of this control were 100% accurate :)

I agree with you that there are numerous ways this control could be improved. Nevertheless, it does exist, it has existed and worked this way for 10+ years, and it is unlikely to change any time soon. If we simply say "sorry, spec doesn't support that", we aren't going to help anyone -- not developers, and certainly not AT users.

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.

The fact is that hundreds of thousands of sighted mouse users use this control every day, and have somehow figured it out. So I think a good portion of your comments fall into the territory of opining about how things should be in an ideal world. I largely agree with you about how the ideal world should look -- I give opinions like this to the designers at my company very frequently :)

But I think we make no progress for anyone if we only support an ideal world. So, with apologies for some preaching to the choir here: moving the state of accessibility requires a certain amount of meeting the world where-it-is, and that includes controls and interactions like this which (we agree) are non-ideal but nonetheless need a way to expose themselves to AT. Our specs have to be both future-facing for building a better world, and able to support legacy controls like this one. @accdc's examples from proto-Windows show that this is very old prior art; we can't just pretend it doesn't exist and write a spec that will never support it.

[craigkovatch]

I think the idea would be to be able to batch up the filtering.

@carmacleod yes exactly. And our research has shown that keeping users "in the flow" is extremely important for the kind of exploratory visual analysis that our product enables. If I have to wait 4s for a round trip (whether to the server, or to the visualization engine) every time I change a checkbox, I lose my flow state quickly.

To be clear: the checkboxes are the real inclusion/exclusion of items in the data filter. The gray selected state is internal to the control, i.e. for batching operations as discussed.

is all of the keyboard behavior the same on Windows and Mac?

Yes, kind of. I work only with our web product, and so our interactions are mostly identical between Windows and Mac, except for e.g. supporting CMD+ instead of CTRL+ for certain keyboard shortcuts. (There may be differences on our native-executable "desktop" product, where this control was originally birthed, but that's of course out of scope for ARIA specs.)

is all of the mouse behavior the same on Windows and Mac?

Yes, modulo CTRL/CMD as mentioned.

does Enter (aka Return) do anything on either platform?

Not in the screenshot shown. There is a version of this control, rarely used, which also has "Apply/Cancel" buttons, for the scenario that I have potentially hundreds of items that I want to manipulate before the server round-trip you mentioned. When these buttons are shown, ENTER commits, i.e. same as clicking the Apply button.

does mouse double-click do anything on either platform?

In terms of there being an onDoubleClick handler, no. Clicking the checkbox twice would of course cause it to "do a full 360" :)

I'm not saying that it isn't confusing to have selected and checked in the same container - it is. We should make sure the guidance is very clear about that, and ask authors to think carefully about their use case. We should also make sure to explain the concept that "focus does not equal selection". And we should tell authors to prefer aria-selected over aria-checked, even when their items have a checkmarky visual treatment. But I don't think we should make it a violation to have both.

💯 💯 💯

[sinabahram]

This keyboard behavior is exactly what I would expect as a blind user and matches mine and others' descriptions on our various calls. I very much do not want it to be forbidden by the spec. That would be a huge step backwards. Thanks for sharing this example.

[smhigley]

@craigkovatch how do you select multiple non-continguous items if the spacebar is reserved for checking? How does this work with a touch-based screen reader? Or voice control? If the checkbox is the main action, do people who use touch or a pointer with less fine control really need to aim exactly for the checkbox to perform that main action? If all selection does is allow you to check multiple items at once for better performance, how would you convert a selection into a checked state without the keyboard?

Disallowing both checked and selected at the same time on the same control isn't just an opinion -- it comes from the basic impossibility of making that dual state and dual interaction accessible. Essentially, if you have a single non-editable interactive item (a button, a link, an option within a listbox, etc.), you're limited to one single action a user may perform on it if you want to make it accessible and work across platforms and input modalities (leaving aside context menus at the moment).

This is one reason why controls with both a primary action and a dropdown like comboboxes and splitbuttons are so hard to make accessible to touch, touch-based screen readers, and other pointer interactions. To make them work, you need to expose an additional button to allow everyone to both perform the primary action and also separately expand/collapse the dropdown. This case is similar: if you want to allow everyone to separately toggle two different states on your listbox option, then you need two separate controls.

[craigkovatch]

@smhigley Yup, as I said, I agree with you. This control falls over in several big ways that you illustrate. (But not all -- we have a separate implementation for touch/mobile devices, and clicking a checkbox applies the action to all-selected items.) Unfortunately it's not likely to be improved on those axes. Nonetheless, we still need a way to expose what it does do -- whether its UX patterns are good, bad, or mediocre -- to AT in a sane way.

My purpose in joining this thread is not to ask "what are the myriad of issues with this UI?", but to offer a case study of the unfortunate reality that for legacy software like this, we're always going to be retrofitting as much AT support as possible while also balancing other business priorities and resource constraints. Not everything can be perfect. We cannot make perfect the enemy of good. The spec is not useful if it only applies to ideal software.

[smhigley]

@craigkovatch you can continue marking up your control in any way you want to; the ARIA spec isn't going to make your current control suddenly break, or even change how screen readers treat checked + selected when the two do occur in tandem.

We shouldn't constrain the ARIA spec to support legacy patterns that are fundamentally inaccessible; if there are no valid, accessible use cases, then it should not be supported. We used to support aria-expanded on role="dialog" for example, and removed it because an expandable role="dialog" would be inaccessible by design. Having both aria-checked and aria-selected on the same option is similarly inaccessible by design, for all the reasons I mentioned + some cognitive accessibility concerns.

@sinabahram I know we discussed this in more depth on the deep dive, and if I remember correctly using aria-current + point of regard + constraining options to only one of checked or selected addressed all the use cases raised. You would still be able to have the keyboard behavior you mentioned without needing to introduce the accessibility problems of dual checking/selecting.

[craigkovatch]

or even change how screen readers treat checked + selected when the two do occur in tandem.

Surely that is not true in the long term -- otherwise what's the point of having a spec?

We shouldn't constrain the ARIA spec to support legacy patterns that are fundamentally inaccessible; if there are no valid, accessible use cases, then it should not be supported.

I think we can agree that accessibility is a spectrum, right? That there are experiences that are "more" or "less" accessible than others. I am trying to present a use case that, yes, falls over in some scenarios that you illustrate, but still derives clear value out of the two properties, even occurring in tandem. (Again, happy to hear suggestions about a better way to structure this in the current world.)

I agree with you that this is not a best-practice pattern, not in the slightest. But if we change the ARIA spec to disallow it, it will be flagged by e.g. accessibility auditors as Wrong, and thus lead to a situation where we create a less-useful experience because of a (forgive me) artificial constraint in the spec.

Perhaps I am misunderstanding you, but what you're proposing sounds very rigid to me -- either it's All or Nothing. I feel there's middle ground to be found here, along the lines that @mcking65 and @carmacleod have suggested. If not, then I think we might need to discuss bigger changes here. If enough people have gotten this wrong already, then there's a lacking in the tools we have available that will not be solved by just deleting aria-checked from option.

[sinabahram]

@smhigley

you can continue marking up your control in any way you want to; the ARIA spec isn't going to make your current control suddenly break, or even change how screen readers treat checked + selected when the two do occur in tandem.

I don't agree with that. The screen readers will happily point to the ARIA spec in order to justify something being unsupported. So, you are of course technically correct that the spec won't immediately break anything, but it certainly can/does/will affect software choices in the future that will break things.

We shouldn't constrain the ARIA spec to support legacy patterns that are fundamentally inaccessible; if there are no valid, accessible use cases, then it should not be supported.

May I please ask for the official definitions of both valid and accessible as used by the spec? These are both heavily overloaded terms. What exactly must they mean in the specific context of the ARIA spec? I feel like without precise shared definitions, that assertion will mean different things to different people.

I know we discussed this in more depth on the deep dive, and if I remember correctly using aria-current + point of regard + constraining options to only one of checked or selected addressed all the use cases raised. You would still be able to have the keyboard behavior you mentioned without needing to introduce the accessibility problems of dual checking/selecting.

I'm confused because that is not my understanding. To help me understand, are you stating that with the above pattern, as you have highlighted it, I can use my arrow keys to navigate, shift+arrow keys to select, control+space to do noncontiguous selection, and hit space on a selection to check multiple items at once? I can with the above pattern, which is very similar if not identical to what I was talking about on the call in terms of use cases. My understanding, just to be clear, is that what you are suggesting will unequivocally not allow for what I just said. If I am wrong about this, please let me know.

[smhigley]

Perhaps I should clarify what I mean when I said this pattern isn't accessible: this pattern is fundamentally impossible to make operable by someone who doesn't have access to a keyboard. This includes the following scenarios and AT:

• Anyone on a touch-only device, including touch-based screen readers
• Pointer-emulating AT like eye gaze or switch + mouse grid
• Voice Control

It also causes additional problems in the following cases:

• Low vision/use of color: you now need to differentiate between for states -- rest, checked, selected, and active
• Limited dexterity: a mouse user is going to have trouble clicking the checkboxes without accidentally changing the selection instead
• Cognitive accessibility: introducing two separate on/off states on the same control also introduces a lot of guesswork and lack of clarity around what each of those states means and how to interact with them
• The shift/control + arrow key selection behavior is not well known in practice, particularly for non-contiguous selection

As far as I'm concerned this isn't "accessible on a spectrum". These are deal-breakers.

The extensive usability and accessibility problems with this pattern are the reason I don't see it anywhere in the real world. Other than Craig's screenshot, I have literally never come across a UI that made me separately check and select the same control. And based on our discussion, it seems clear that that example has all of the accessibility problems outlined above, so it seems to me like an accessibility validator would be correct to flag it. There's even a very clear accessible alternative: add an "apply" button.

Again, this isn't some minor "less than ideal" quibble. The issue is that this pattern, by its very design, is actually impossible to make accessible to multiple common input methods. We also have yet to come across a use case that could not be solved in another way. In my opinion, patterns like that should not be supported by the ARIA spec.

[craigkovatch]

Thank you for the very clear thoughts @smhigley . Again I can’t help but say I understand and agree with where you’re coming from. But I am also faced with a lot of other real-world constraints that I feel you are ignoring.

To address some of your points: The control is already operable by the two most common input methods. It may not be 1-to-1 identical experience for both, but it does work. You bring up touch, but I’ve already said that there is a separate UI entirely presented for touch. You bring up visual state differentiation — but it already does have four visual states (again, not all pictured). You say you’ve never seen this anywhere else, but there are several other linked examples provided by myself and others. You might hate them as UX patterns, and I wouldn’t argue, but saying they don’t exist is not true 🤷‍♂️ “I’ve never seen it” is not the same as “it doesn’t exist”.

Much more importantly I think the discussion misses the forest for the trees. I don’t think we should continue debating this particular control, because I am only intending it to be illustrative of a scenario which is going to be very common in extant, real-world software, and will apply to many Issues beyond this one.

Ignore for a second this particular funky listbox, because we’re talking about philosophy now. I am faced with the real-world constraint that this example — like many more in other pieces of software and companies — represents UI that exists, has existed for a long time and serves thousands/millions of users, and for some reason or another (be those good or bad, fair or unfair, inclusive or shitty reasons), will not be changed.

If that is the scenario, the spec change you are suggesting means less information is able to be provided to AT. Yes, there is a spectrum of accessibility. You can’t throw the baby out with the bathwater and say that, because you see issues with it (issues which you are quite right about), there is no value whatsoever in exposing as much as possible. Isn’t it better for it to mostly-work than mostly not-work?

There are always going to be tradeoffs made, especially by businesses attempting to improve legacy software. I believe very strongly that spec-writing of this kind should encourage and document best practices, but also attempt to provide a path for graceful degradation.

But the arguments I’m understanding from you seem to suggest that this is too cursed of a control and so the spec shouldn’t even try to allow for it. I can’t agree with that philosophy. I think that attempting to provide access to as many users is possible is better than simply giving up on it — even if it’s still not perfect for everyone.

TL;DR: yes, maybe this particular control sucks. Still, and always: what’s the best thing we can do for as many users as possible?

[smhigley]

@craigkovatch I work on practical accessibility problems for hundreds of products, including ones as complex as Tableau. Saying I'm ignoring real-world constraints is a bit... odd. Additionally, misrepresenting what I've written by saying I "hate" the pattern is unhelpful, untrue, and verges on sexist.

The reason I raised this issue and the reason I think it's important is because allowing both aria-checked and aria-selected on options and treeitems confuses developers in practice, who then mix up selection and focus/point of regard. The linked Orange and Lightning listboxes are excellent examples of exactly this problem in the real world.

If, as you say, there are "many more in other pieces of software and companies," could you provide links to some of those examples? Particularly ones that are public and that we can inspect and interact with. So far, yours is the only example to come out of this discussion that uses dual selected and checked states -- all the others only have one selected or checked state + point of regard.

[scottaohara]

Would agree with Sarah here. I'm finding the responses to her to be rather unfortunate and diminishing of how much experience and knowledge she has with real world software here. Please, be mindful of that and stop insinuating she is coming from a place of purely opinion.

I would personally like to see other working examples, as I also find the Orange and Lighting, as well as other linked demos thus far, lacking in accurately demonstrating what was otherwise outlined in this comment. And as Sina summarized:

I can use my arrow keys to navigate, shift+arrow keys to select, control+space to do noncontiguous selection, and hit space on a selection to check multiple items at once...

Unless I just don't understand what keys to use, or if they're somehow windows specific, I haven't been able to select more than a single item to check/uncheck at once.

Furthermore, I do think there is a larger conversation that should be had here (but not necessarily in this thread) regarding the "philosophy" of what a spec should/should not entail, and whether or not a spec should support potentially problematic practices because "they're in the real world".

I'm all for not breaking things, but advocating not to break things that are also inadequate / broken, and to not recommend other alternatives to achieve more robust solutions .... well. I'm not going to go further on that right now because we're already enough off topic.

[jnurthen]

@craigkovatch I'm really interested in how you present a different UI to users using touch on a Windows laptop.... I didn't think there was a way to do this.

[sinabahram]

@scottaohara RE the keystrokes, I think I understand your question to be one of two possible things. Are you asking about selection, which is just hold down shift key and use arrow keys, or are you asking about noncontiguous selection, which is hold down control and then you can use space and arrow keys to select and navigate without selection. I wasn't referring to anything knew, just what's been true for the last 20 years or so of my computer usage. Please note that multiple screen reader users on our last depe dive call confirmed this expectation of keyboard usage. I'm not claiming people said it was easy or good for novices, but I did not hear any disagreement on the technical correctness of the above description of how continguous and noncontinguous selection occur. Please note that yes I'm referring to Windows specific keystrokes. @cookiecrook confirmed, I believe, that noncontinguous selection with keyboard wasn't/isn't a thing on Mac. I just wish to humbly point out, that doesn't mean it shouldn't be a thing, full stop. @cookiecrook if I have that wrong, my apologies, and maybe you can provide @scottaohara the keystrokes for noncontinguous selection with keyboardthe .

It would be good to know where to discuss the off-topic spec stuff. I must admit to complete and utter confusion at this point about the rules under which we operate. I really don't understand the model we are operating under here, clearly. It feels to me like @smhigley is applying the constraint that an interface only can count as an example if it itself is fully accessible, but I did not know this to be the operating constraint of the ARIA WG. Just on a call a week or two ago, it was stated that ARIA needs to make what exists out there accessible, but now I am getting the sense that ARIA should only try to facilitate fully accessible interfaces, even when lots of affordances may not rely upon ARIA what-so-ever. I'm not taking a position on the above. I sincerely desire to know what rules exist so I can contribute more effectively. To contextualize my confusion, I understand the argument to be as follows; we should not allow both selected and checked.because to do so implies an inaccessible interface. I simply wish to know if this constraint applies to every single affordance available in ARIA. If so, I need to calibrate my understanding.

@smhigley if I have not understood the above clearly, please let me know so that I may better understand your position. I strongly believe we have the exact same goals here, which is to make the web better for everyone. As someone who benefits directly from that work, you only have my gratitude. I simply don't understand why we are wanting to forbid something that does exist and is helpful, even if it is for a small subset of users. That inaccessible interface is not going to be made accessible if the spec changes to forbid checked and selected being used together, but it is very likely that screen readers will have no impetus to support checked and selected together if we forbid it. This feels to me like a net-negative; hence why I keep pushing on it.

[craigkovatch]

@smhigley

I work on practical accessibility problems for hundreds of products, including ones as complex as Tableau. Saying I'm ignoring real-world constraints is a bit... odd.

I am not insinuating anything about your depth of experience. I am aware of it, and have told you many times how much I appreciate and respect it. I’ve reached out to you personally for advice on many occasions. But I feel your comments on this topic are too focused on “it has to be perfect or it can’t be saved”, and I still feel that way.

It is completely baseless to suggest the concerns I am raising are motivated by sexism. I’m not sure how the suggestion that you “hate” a pattern would signify that — based on posts and presentations of yours, I would say you “hate” tooltips as well, but that’s got nothing to do with anyone’s gender. Regardless, my apologies for the choice of words that misrepresented your perspective.

It was not my goal to discuss this specific control in depth, but to illustrate the practical ramifications of the problem it presents, and others like it, as we attempt to craft good specs as a community.

I am motivated by trying to find a solution that works for both best practice and not-best practice. I would still welcome your ideas on how this situation, and thus others like it, might be solved alternatively if your suggestion of removing aria-checked is adopted. I understand your opinion is this control should just not exist, but it does, and I still want to know how to do best for our users if this spec change is made. My opinion is still basically what @carmacleod and @sinabahram have suggested: recommend against combining them, for the reasons you’re calling out, but don’t disallow them. Instead document them verbosely so that confusion is avoided in the future.

If, as you say, there are "many more in other pieces of software and companies," could you provide links to some of those examples

I was talking about the general problem of retrofitting here, not saying there are many more funky listboxes.

[craigkovatch]

@craigkovatch I'm really interested in how you present a different UI to users using touch on a Windows laptop.... I didn't think there was a way to do this.

@jnurthen Our support for “desktop touch” is poor. We assume if we see touch events that the user is on a mobile device and show different UI with larger tap targets and other touch accommodations in that case.

[craigkovatch]

@scottaohara I’m on board with everything you said. I don’t have examples outside my own scope, but it does seem to me there is other prior art here, eg the old WinForms screenshot that was offered.

I enthusiastically agree that we should probably figure out a discussion venue for “philosophy” of spec. I think we will have a hard time coming to a consensus on specific problems like this one without nailing down broader questions of approach and what’s “in” and “out”. My understanding has been the same as @sinabahram .

To further echo @sinabahram (whose other comments I also agree completely with) — we all have the same goal here. We all want the web to be better for everyone ❤️

[scottaohara]

@sinabahram i was specifically just trying to get provided examples to allow me to hit Shift under the assumption that up or down arrows would let me "select" additional options. They did not. I tried control instead and that just initiated the macOS function of showing all the open windows on my screens for re-ordering. I then threw up my hands.

[joanmarie]

Some brief observations / opinions (and admittedly vast oversimplifications):

• If it can be selected (in the highlighted sense of that word), then it seems to me that aria-selected should be supported.
• If, independent of its selected state, it can be toggled (e.g. it has a visible checkbox or radiobutton), then it seems to me that aria-checked should be supported.
• Authors gonna author. Whether we support aria-checked on options/treeitems or not, some author is going to decide that their option/treeitem needs to have a checkbox. Screenshots of examples have been provided. So.... If we were to remove aria-checked support on these roles, the aforementioned author might decide to cram the checked state into the accessible name to make the screen reader do the author's bidding. This strikes me as making things worse; not better.
• If we really, really don't want to support aria-checked on options, then we probably should make options not children-presentational so authors can add checkable descendants. This constraint does not seem to be present on treeitem.
• If there is confusion about what aria-checked means versus what aria-selected means with respect to an option and/or tree item, maybe that is the thing to fix in the spec and address in the APG.
• If there is lack of support for the "checked" state in screen readers for the option and/or treeitem role, let's file bugs against the screen readers.

[craigkovatch]

If we really, really don't want to support aria-checked on options, then we probably should make options not children-presentational so authors can add checkable descendants. This constraint does not seem to be present on treeitem.

Without speaking to how easy/hard/possible this would be, I think this is a GREAT idea to discuss. I have found no matter how many warnings and constraints I put in our library, “authors gonna author” and want to have interactive children in their options.

[scottaohara]

per Joanie's points, I would lean far more towards:

If there is confusion about what aria-checked means versus what aria-selected means with respect to an option and/or tree item, maybe that is the thing to fix in the spec and address in the APG.

again, the feedback I've had on patterns like these, is that people don't understand the difference between checked and selected. to non-spec-savy people (e.g., users and devs) these can mean the same thing. hence, if we're going to continue to support things like this, we need to be clear to implementors and authors when/why/and how to use these states. Also, I would personally love to see the future guidance indicate about how authors don't need to just reach for a pattern like this. e.g., just because there's visually a checkmark, that doesn't always mean it needs a checkbox, if that checkmark is just another way to visually indicate a selected state.

I would also want to lean as far away from the following as possible:

If we really, really don't want to support aria-checked on options, then we probably should make options not children-presentational so authors can add checkable descendants.

[craigkovatch]

I would also want to lean as far away from the following as possible

@scottaohara could you kindly elucidate your concerns on this? I expect there is much here that I "don't know I don't know", would love to understand why you feel strongly against it.

[scottaohara]

A number of concerns, really.

1. Blurring the lines of what interactive roles allow for nested interactive children more than there already is. Re: treeitem, an argument could be made that since there's no host language (HTML) equivalent then there is more leniency for allowances. That hypothetical argument falls apart for other roles which have HTML equivalents, where an allowance like this would be in opposition to the requirements of its host language counterpart.
2. further distancing the allowances/expectations of role=option vs <option> (which again, does not support a checked state in native HTML, but at least neither ARIA or HTML are currently in misalignment regarding allowed children).
3. The general usability of nested controls, e.g., the difficult click/touch areas nested controls create, ensuring each control has an adequate accName without producing an overly redundant accName of either... etc.

i think that's enough for now.

[craigkovatch]

Thanks @scottaohara. Numbers 1 and 2 are more persuasive to me than number 3; please see e.g. a whole bunch of Material UI examples of list items with nested/secondary controls: https://material-ui.com/components/lists/#list-controls (@smhigley too, I think this qualifies as more examples you requested). Lots more examples of "authors gonna author" and so I think we should try to determine what the best modeling is. They seem to be getting around this whole debate by using <li> rather than <option>, although that seems wrong in a different way to me (correct me if I'm wrong but my gut feeling is that li/role=listitem shouldn't be interactive?).

Also, and I'm a hypocrite for saying so, but I think we should start at least one new thread as this Issue has several different lines of discussion to follow now. I'm not sure the right way/place(s) to do that, though.

[jscholes]

I think @joanmarie has summed up my thoughts in the most straight-forward, sensible way. I'm mindful of the fact that the title of this issue is, "aria-checked on option and treeitem". The overlap with other ARIA attributes is appropriate, but I feel has slightly derailed the discussion.

Speaking in practical terms, I'm interested in many use cases for having a checkbox-style look and feel within a list box and tree view where selection follows focus. This has come up with multiple client projects, some of which are public and can be discussed here, some of which can't.

It is a fact that screen readers do facilitate traversal through options or tree items which, in such cases, wouldn't cause selection or focus to move, but would still allow the checked state to be queried. As an example, object navigation in NVDA would permit such exploration inside both list boxes and trees.

As a practical example, the sidebar on this GitHub issue contains several "dropdowns" (for lack of a better term) for applying assignees, labels, etc. Currently, expanding those sidebar sections reveals a search input and menu, which is a semantic hack to force a screen reader to recognise the checked semantics via role="menuitemcheckbox". But it poses several issues, and I'm sure many in this thread have concerns about the UX which aren't strictly relevant. Here's what I'd love to see:

1. An editable combo box with list box pop-up, where the combo box is editable to search for labels, users, etc.
2. A "list autocomplete with automatic selection" pattern (in APG terms).
3. aria-selected being used to follow focus/aria-activedescendant.
4. aria-checked on each option to explicitly communicate applied state.
5. An apply button.

I suspect that in the above, point #4 is what people are going to have trouble with. Why not just use aria-selected to indicate applied state? These aren't multiselect controls, after all.

As an example of why that is problematic, screen readers have inconsistent support for conveying selected versus not selected state. Both in terms of when they do and don't convey it, and in the speech patterns that they use. I mention both of these points fully aware that exact assistive technology output is somewhat outside of the scope of the APG, but also because it supports the spec being explicit about support for various attributes in mark-up. It has also been my experience that users understand checked versus not checked a lot more than selected or not selected versus screen reader silence (for example because on something like the Windows desktop, select state isn't usually spoken/brailled).

Note: point #4 above is also why I wouldn't disagree with some explicit new roles of "optioncheckbox" or "treeitemcheckbox".

[scottaohara]

@craigkovatch i would submit the the material component you linked to is not at all what's being discussed here. As far as that not being a persuasive argument, fine? I mean, pointing to bad ux to say "see it's ok!" doesn't make it ok. "authors going to author" yes. but i highly disagree that a spec is the place to introduce bad practices as if they aren't going to have implications somewhere else (html, wcag, etc.).

[craigkovatch]

@scottaohara I see (what is functionally) a listbox with items which have a secondary, interactive child; in one case having both checkboxes and buttons as children. So relevant to both "items which can be checked and/or selected" discussion and also @joanmarie's suggestion "then we probably should make options not children-presentational so authors can add checkable descendants", i.e. your immediately previous reply's point number 3...?

[scottaohara]

It's not a listbox. Those are separate controls taking up space on the same horizontal plane. Just doing basic keyboard tabbing you will notice there are two stops (one unfortunately on the parent wrapping div that then targets down to the visually hidden checkbox input, and the second on the button). Looking at the DOM, while they are nested within a clickable nonsense div, they are not invalidly nested in a way that would be in misalignment to HTML or ARIA right now.

[smhigley]

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, because otherwise there should be a pretty simple path forward. Dual on/off state (persistent state, not focus) is not a thing I've encountered (again despite working with hundreds of apps), which is part of what makes this discussion so weird to me. I also reached out to other UX folks and control pattern developers to ask if they're familiar with it, and they are not. In fact, the common reaction was along the lines of "WTF, how does that work?".

@jscholes the point about preferring checked state announcements is well made, though I think for your third example you could easily leave off aria-selected entirely, and just use aria-checked + focus/activedescendant. It still sounds like an example with only one on/off state (checked) in addition to the point of regard.

I 100% agree with @joanmarie and @sinabahram that "Authors gonna author," and we should support accessibility, even if not perfect, for common and emergent patterns that address actual UI needs. The thing is, I haven't seen any evidence on this thread that dual independent selected/checked states is actually a thing that authors need or even create in practice. Earlier I was trying to demonstrate why that is the case (i.e. all the accessibility and usability problems it introduces). Maybe I should be more direct: do we have any examples to show that allowing separate dual state a) addresses a user need, or b) is a common pattern?

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. Can anyone find other examples to support this being something people do? If we can't find those, we could continue to support both aria-checked and aria-selected on option and treeitem in the spec, but specify that they cannot both be defined for the same control.

Also, because the question about WinForms and other Windows selection/checking patterns has been raised before, I did some research on it for one of the past deep dives. I'll paste the specifics below, but the TL:DR; is that while Windows has used both checked and selected states in the past, it has not enabled independent control of them as two separate on/off states on the same option. In more detail:

• Winforms: the "Checked List" control implements both checked and selected semantics, but you cannot separately control checked and selected state
• WPF: The selection list has visual checkboxes, but only implements selection under the hood
• UWP XAML: Does not have visual checkboxes, and only implements selection under the hood

[sinabahram]

@smhigley In the spirit of providing examples, may I please ask for an example of a treeview that allows for multiple selection and checked state in the way that you think is best/ideal e.g. with buttons or however else you feel addresses all of the concerns you have brought up, but still allows for multiple items to be acted upon at once in terms of their states being toggled?