W3C

– DRAFT –
ARIA and Assistive Technologies Community Group

11 August 2022

Attendees

Present
Matt_King, michael_fairchild
Regrets
-
Chair
-
Scribe
s3ththompson

Meeting minutes

Should Toggle Button Not Presssed State Speech be Required

James Scholes: toggle button has two states: on and off. specifically, the fact that it has one of those states is what makes it a toggle button. a button if it has aria-pressed, becomes a toggle

James Scholes: in our tests for toggle button, we have assertions that say "when aria-pressed is false, the screen reader must convey that fact to the user"

James Scholes: we can debate how it says that (e.g. is it "off"?) but we must convey it. this is when reading it, and also when navigating a toggle button from somewhere else, and when toggling from pressed to not pressed and vice versa. the state must be conveyed

James Scholes: the input from James Craig on issue 784 https://github.com/w3c/aria-at/issues/784#issuecomment-1180982091

<Matt_King> Comment from apple: https://github.com/w3c/aria-at/issues/784#issuecomment-1180982091

James Scholes: is that it only announces "pressed" but that it's on the user to infer if a toggle button doesn't say anything, then it's "not pressed"

Alyssa_G: that sounds like a lot to infer

Matt_King: we should look at how this works with switch and checkbox for VoiceOver

Matt_King: i'm pretty sure when i checked previously it vocalized the non-state

James Scholes: it looks like "not pressed" is conveyed on iOS

Matt_King: interesting, sounds like those designers are not talking to each other

James Scholes: I want to make sure that no matter the outcome we have to acknowledge that the tests aren't exactly "wrong", those assertions were written for a reason

Matt_King: before we get to process, let's talk about substance. if we push back we should say: "we believe 'not pressed' should be conveyed, for these reasons...."

Matt_King: let's say we do that. what could be some of the tradeoffs?

Matt_King: need to balance what might come across as being overly pedantic (with two valid stances) vs. capitulating without sticking to our original rationale

Matt_King: looks like current temperature of those present is to stick to the existing assertion / behavior?

michael_fairchild: can you clarify why we think it should fail?

Matt_King: because the only reason the user can confirm the state is what they think it is is to press button (hear "pressed") and then press again to un-press

michael_fairchild: i guess it's not optimal in my view and potentially a usability problem, but i'm still unclear about whether it's inconsistent and whether it failed outright

Alyssa_G: I worry about users who might not know what a toggle button is

michael_fairchild: then i think we might be getting into a conversation about verbosity, experience, user feedback, etc.

Matt_King: the group decision, then, is that we would like to begin a discussion with Apple where our starting position is that we would like to keep the assertion as-is.

James Scholes: we're looking at a lot of inconsistencies here...

Matt_King: i think that's just an inconsistency between native iOS and the web. iOS has always had a smaller set of traits for something like roles...

Process for discussions on assertion feedback from AT developers

Matt_King: i would love for the community group to have a consistent voice... that we're not all just chiming in on an issue thread. on the other hand, i don't want to have too much process. for some topics it's fine if you just respond inline, james.

James Scholes: the other point is potentially inviting at vendors to the discussion convo directly

Matt_King: i can definitely see that happening... but i think even in that case i'd like to pre-discuss first

Matt_King: in terms of process, if we're comfortable with the discussion points here and the comment is mostly a summery therein, i will draft comment over email with ja,es

Matt_King: *with James

Summary of discussion points:

- cognitive load for users who have to infer state

- inconsistency in default settings on macOS with checkbox and switch

*on macOS in safari

- inconsistency with toggle buttons on iOS in safari

- lack of feedback with you turn a toggle button off

- inconsistency with non-apple screen readers

- if verbosity is a concern, then an advanced verbosity setting could be used (this is a subpoint under the default settings point)

Minutes manually created (not a transcript), formatted by scribe.perl version 192 (Tue Jun 28 16:55:30 2022 UTC).

Diagnostics

Maybe present: Alyssa_G