Aria-pressed : Spec is unclear about the toggle button

[shirsha]

https://www.w3.org/TR/wai-aria-1.1/#aria-pressed Currently aria-spec says : Toggle buttons require a full press-and-release cycle to change their value. Activating it once changes the value to true, and activating it another time changes the value back to false. A value of mixed means that the values of more than one item controlled by the button do not all share the same value. Examples of mixed-state buttons are described in WAI-ARIA Authoring Practices [wai-aria-practices-1.1]. If the attribute is not present, the button is not a toggle button.

There are scenarios where two buttons can be used as toggle button. In these cases it will be useful to add aria-pressed attribute to the buttons. Examples: https://tink.uk/ https://design.fusionfabric.cloud/ui-elements/button-toggle

[scottaohara]

seems like either a situation where one should be using aria-current to indicate the currently active button in a set of buttons, or aria-pressed with an aria-disabled to indicate that the currently active toggle button cannot be unpressed. I personally prefer the former to the latter.

while i understand the point you're bring up here, the fusionfabric examples specifically seem more like they are just broken in not allowing the buttons to be unpressed. e.g., why would i not be able to unbold something without having to make it italic or underlined?

[shirsha]

I get the design aspect you are bringing up. I am only looking at the accessibility part now. As per Aria, aria-current attribute is used to indicate a visually styled current item. It doesn't convey that it is toggle button and it is disabled. So I lean towards using the aria-pressed with an aria-disabled as you mentioned above.

[JAWS-test]

In the tink.uk example, radio buttons should be used instead of buttons with aria-pressed. Alternatively, a toogle button, checkbox, or switch should be used whose pressed or checked state is identical to Dark and whose not pressed or not checked state is identical to Light

The buttons have two problems:

• I can't change the aria-pressed=true status to false.
• With the screen reader I can not perceive that changing the state of one button automatically changes the state of the other one. I don't perceive that both buttons are related (at tink.uk I can tell from the label, but there are other cases where this is not possible)

I think the specification is correct, but toggle buttons must be used correctly

[shirsha]

My opinion is, in this scenario toggle buttons and radio buttons can be used interchangeably. When one of the controls in the group is pressed the rest of the controls should be set to false. Another scenario where aria-pressed along with aria-disabled attribute is useful is when buttons have more than 2 possible states (pressed, unpressed, and mixed state). “Expand all” and “Collapse all” buttons are used to control a set of accordions’ states. The two buttons are contained inside an element with role="group". When the “Expand all” button is pressed then all accordions are expanded. Similarly, if the “Collapse all” button is pressed then all accordions will be collapsed. When a control is set to pressed, it’s aria-disabled attribute is set to true. User can manually expand/collapse the individual accordions. In this mixed state both buttons "Expand all and collapse all" (some accordions are expanded, and some are collapsed) will have aria-pressed set to false.

[scottaohara]

In this mixed state both buttons "Expand all and collapse all" (some accordions are expanded, and some are collapsed) will have aria-pressed set to false.

why false? sounds exactly like they should both have a "mixed" state.

[JAWS-test]

My opinion is, in this scenario toggle buttons and radio buttons can be used interchangeably.

I don't see it that way. There are elements that users assume are independently operable, such as.

• (toggle) buttons
• checkboxes
• input fields As a rule, operating one of these elements should not change the status or value of any other element on the page. Otherwise, this would be a violation of WCAG SC 3.2.2. The problem is that blind people cannot perceive when the status of other elements change when buttons, checkboxes, etc. are operated, especially if this happens in the reading order before the current element.

On the other hand, there are grouped elements where it is clear that the status of the other elements in the group changes when I operate one element, e.g.

• radio buttons in a group
• menuitem in the menu
• tab in tablist
• option in listbox

[StommePoes]

I can't possibly imagine what a mixed state could be. The word "toggle" to me tells me 2 states. But I am a stupid person who regularly has trouble with app-like interfaces. Still, of course, I haz opinions.

I don't feel radio controls are appropriate for expanded/collapsed states of things like an accordion widget. Similarly, I don't use checkboxes for disclosure widgets.

A group of aria-pressed buttons do in my mind act very similarly to a set of radio controls (just like car radio buttons, they each can have a pressed state and most of the time only one of the group can have the pressed=true state... but not always). But pressed-buttons' interaction is much better for non-forms in my view (see below).

As a rule, operating one of these elements should not change the status or value of any other element on the page.

This makes zero sense to me if you have "toggle" in the list. Toggle controls toggle states and content all the time. A disclosure widget IS a toggle widget. It is toggling the visibility of the related content. A light switch is a toggle switch. The room goes from invisible to visible. In fact, the point about failing 3.2.1 is why I wouldn't use radio controls for this. Radio controls, unlike pressable buttons, cannot differentiate between a focussed state and a selected state. Being a keyboarder, merely moving amongst the radios in a group, or exploring them with a screen reader, is no different from choosing them when developers make changes on the page based on focus (and I'd love to fail some of these with On Focus, however changing some content after a set of controls is apparently not the same as a change in context. Developers don't submit forms anymore, that's too old-fashioned now apparently. It's all JavaScript. Oh well). With pressable buttons, users can safely explore the button's names, or Tab amongst them, without changing anything. Users must make a clear effort to select a button. Also, unlike radios, users can (or should be able to) un-select it.

In this mixed state both buttons "Expand all and collapse all" (some accordions are expanded, and some are collapsed) will have aria-pressed set to false.

I mean, I guess this would just mean there are no "all-the-things" controls currently active. I can't possible see aria-current doing anything useful here. Just that, these controls are not currently activated.

[JAWS-test]

I don't feel radio controls are appropriate for expanded/collapsed states of things like an accordion widget. Similarly, I don't use checkboxes for disclosure widgets.

I also see it that way. However, I don't use toggle buttons for this, but buttons with aria-expanded and possibly aria-disabled (see https://www.w3.org/TR/wai-aria-practices-1.2/examples/disclosure/disclosure-faq.html, https://www.w3.org/TR/wai-aria-practices-1.2/examples/accordion/accordion.html)

I can't possibly imagine what a mixed state could be. The word "toggle" to me tells me 2 states

I see it that way, too. I don't know of any implementation with toggle buttons in mixed state. I also don't know how this should work visually. The screen readers JAWS and NVDA also have problems with this: they output the mixed state of the toggle button as checked and not as pressed, i.e. like a checkbox.

This makes zero sense to me if you have "toggle" in the list.

I see it differently: In a toolbar, e.g. for text formatting, I can operate the toogle buttons "Bold" and "Italic" independently. If two buttons in the toolbar depend on each other, another element should be used

A light switch is a toggle switch

That is correct. But as I already wrote, I don't need 2 toggle buttons (one for "on" and another for "off"), but only one toggle button or one switch or one checkbox, whose 2 states represent "on" and "off".

[shirsha]

I also see it that way. However, I don't use toggle buttons for this, but buttons with aria-expanded and possibly aria-disabled (see https://www.w3.org/TR/wai-aria-practices-1.2/examples/disclosure/disclosure-faq.html, https://www.w3.org/TR/wai-aria-practices-1.2/examples/accordion/accordion.html)

The reason for using aria-pressed instead of aria-expanded on the "expand all" and "collapse all" buttons is to remove confusion for the screen reader users. Adding a aria-expanded attribute to the controls that have same state name may add confusion to the screen reader users.

• When "Expand all" control is not triggered, the screen reader user will hear "expand all collapsed".

• Similarly for the "Collapse all" button when it is triggered, they will hear "collapse all expanded".

• If neither of them are selected then the screen reader would announce it as "Expand all collapsed", "Collapse all collapsed"

To provide the button state without creating confusion, aria-pressed attribute is a better approach here. The controls are contained within a div element with role="group" which does communicate to the AT that they are grouped and interact with one another.

I see it that way, too. I don't know of any implementation with toggle buttons in mixed state. I also don't know how this should work visually. The screen readers JAWS and NVDA also have problems with this: they output the mixed state of the toggle button as checked and not as pressed, i.e. like a checkbox.

Currently, aria-pressed can have values as follows: If aria-pressed="false" is used the button is a toggle button that is currently not pressed. If aria-pressed="true" is used the button is a toggle button that is currently pressed. if aria-pressed="mixed" is used, the button is considered to be partially pressed.

[StommePoes]

However, I don't use toggle buttons for this, but buttons with aria-expanded and possibly aria-disabled (see https://www.w3.org/TR/wai-aria-practices-1.2/examples/disclosure/disclosure-faq.html, https://www.w3.org/TR/wai-aria-practices-1.2/examples/accordion/accordion.html)

I do as well; it may be a personal thing but I think of disclosures as usually showing more content in general. A toggle would switch between, say, page settings. The example being used in this ticket has a "red herring": it has buttons called "expand" and "collapse", but in the context of an accordion thingie, I see this as users choosing between mayo or ketchup with their fries; a mostly visual style setting.

I'm thinking of a graphical mail "indexer" type page where it seems nice, simple, and useful to have separate Collapse All (only shows mail subject) and Expand All (shows subject, sender, and first sentence or so of the mail) as separate controls, because I'm assuming the users can also expand individual ones they want to see as needed.

if aria-pressed="mixed" is used, the button is considered to be partially pressed.

I'm sorry but what in hell is a mixed pressed state? It sounds like a dry cleaning setting. (And so I believe THIS is the crux of this ticket, and that this is Siri's question. What the hell is partially pressed? Why don't we have this on aria-expanded? You know, so things could be partially expanded?)

Is this like when we were kids in those cars with the radio buttons and we discovered if we sorta half-pressed on the other (non-pressed) radio buttons, the currently-pressed button would pop back up so that they ALL looked un-pressed? That was a pretty cool trick, but the radio was still playing just one station.

Siri I think we'd both agree that the typical disclosure widget with an aria-expanded attribute doesn't make sense for the state of your accordion. I do understand how it could seem confusing to some to have two pressed-buttons (Expand All and Collapse All) however if the idea is users can independently expand little parts on their own, now the purpose of each control makes more sense: I may have expanded 10 of 15 and just want to close them all at once with the Collapse All... or realise I want to see everything and Expand All. Having a single control for that would pretty much require the same series of extra click steps I have to go through for minimising/maximising windows, in Windows. If I want to take a non-maximised window (the kind where you can change the sizes or grab the edges) and change it with Win+Up or Down Arrow, it seems to cycle first between the various size states instead of only jumping between the two (I assume so that the shortcut can allow access to that middle state). ...and now I'm wondering if, after a user has expanded just a few items and the rest are collapsed, if those buttons are supposed to now be aria-pressed="mixed"? It's still confusing to me though.

but in the context of an accordion thingie, I see this as users choosing between mayo or ketchup with their fries; a mostly visual style setting.

Oh is "mixed" like when you turn ketchup and mayo into that pink slime by mixing them together?? Is... is that legal in polite company?

I dunno, I would just ignore that mixed stuff. If you turn your head sideways after breathing in a good whiff of glue, you can kinda make some sense of a "tri-state checkbox", but I think with pressed buttons it's just looking for trouble. Pretend there are only "true" and "false" pressed states. This is how I am currently surviving the pandemic.

[smhigley]

I think the specific example at the top is a bit of a red herring for the entire discussion; or rather, because it was brought up in the context of aria-pressed, we're all trying really hard to figure out how to assign a state properly to each button, when it isn't clear that those buttons need to convey either state.

Both "Expand all" and "Collapse all" are buttons that perform a single action somewhere else on the page when you activate them. A normal button, not a toggle button or expand/collapse button, should work perfectly well, IMO. Sometimes you can't activate one of the buttons (e.g. you can't expand all accordions if they're all already expanded), and in that case the button can be disabled. I don't think there's any reason that example needs to be more complicated than that. I also don't really think the "expand all" and "collapse all" buttons would be expected to convey the current state of the accordions below them. Either you want to expand them all, or you don't; it doesn't depend on whether they're currently all collapsed or in a mixed collapsed state.

Léonie's example is a little more interesting, since the theme toggle actually does need to hold and convey on/off state. On the other hand, a lot of other theme switches are implemented as a switch or checkbox, both of which seem like potentially better fits for binary state controls.

[smhigley]

also, @StommePoes,

Pretend there are only "true" and "false" pressed states. This is how I am currently surviving the pandemic.

I feel tagged 😂

[jnurthen]

Has anyone ever seen a mixed state button in the wild? I can't find the concept in any design system. I propose to strike the sentence "A value of mixed means that the values of more than one item controlled by the button do not all share the same value. Examples of mixed-state buttons are described in WAI-ARIA Authoring Practices [wai-aria-practices-1.1]." from the spec

[carmacleod]

Would be nice to remove it, but apparently a couple of the platforms allow it, and there may have been one use case. See: https://github.com/w3c/aria/issues/1258#issuecomment-624638889 https://github.com/w3c/aria/issues/684#issuecomment-556127071

If we remove this, we would also need to:

• change the Characteristics table for aria-pressed from Value: tristate to Value: true/false/undefined,
• remove the row for mixed | Indicates a mixed mode value for a tri-state toggle button. from the Values table.

Note that there are no mixed state buttons described in the APG... but that sentence was removed after previous discussions on this topic. ;)

[scottaohara]

A year and 3 days later (3 representing the 3 states of a toggle button - i 'definitely' planned this) I've re-reviewed this issue multiple times. I essentially see a few tasks / pathways forward here:

1. Do nothing here, but rather create content in aria practices to handle situations like those brought up here.
2. potentially deprecate the mixed value for toggle buttons? Or, per #684 provide editorial on why they should be allowed? Two different directions seem to be on the table depending on which issue you look at.
3. close this issue and work on the concept of a toggle group or checkbox group (oh hi i made an open ui issue about such a thing as well).

[clshortfuse]

My understanding is the difference between a checkbox and button applies to same way to mixed state toggle. Checked is supposed be a YES/NO rather ON/OFF. Checked makes sense for forms, but for actionable items. With that in mind, I'm probably going to redesign my "Switches" to be aria-pressed buttons instead of aria-checked checkboxes. Taking the guidance of Google's Material Design:

Use switches to turn an item on or off, especially on mobile instead of a checkbox.

I can definitely consider this situation for smart switches. If I have a light that's on, I'd use a switch to show on. Off would be off. As for the room itself, I would also have a toggle that can represent a state that is composed of all lights in it. If all are on, it's on. All off, off. Mixed would be mixed.

• Bedroom Lights <toggle: on/off/mixed>
  • Ceiling Light (toggle: on/off)
  • Desk Lamp (toggle: on/off)
  • Nightstand Light (toggle: on/off)

I can easily design a mixed state Switch by putting the circle in the middle. It also makes sense for a switch to be a button because it's not a form item. If a user toggles the light on, it should immediately take effect, which is the intended result of a real life button.

Edit: Completely forgot about role=switch. 😆 Though I guess the guidance is near the same. If a button can manipulate all others in a group, it's like a switch toggling all items. Though, with role=switch I really don't like expressing something is actionable with aria-checked.

[jnurthen]

we should decide on which of these is the best way forward https://github.com/w3c/aria/issues/1406#issuecomment-1078543613

My vote is (1)

[aardrian]

My vote is (1)

[scottaohara]

same - 1. actually just came across some useful instances for a mixed toggle button state in a rich text editor... so, definitely has it's place.