IRC log of aria-at on 2022-10-20
Timestamps are in UTC.
- 18:48:51 [RRSAgent]
- RRSAgent has joined #aria-at
- 18:48:51 [RRSAgent]
- logging to https://www.w3.org/2022/10/20-aria-at-irc
- 18:49:11 [Matt_King]
- MEETING: ARIA and Assistive Technologies Community Group
- 18:49:22 [Matt_King]
- CHAIR: Matt King
- 18:49:27 [Matt_King]
- present+
- 18:49:32 [Matt_King]
- rrsagent, make log public
- 18:49:41 [Matt_King]
- rrsagent, make minutes
- 18:49:41 [RRSAgent]
- I have made the request to generate https://www.w3.org/2022/10/20-aria-at-minutes.html Matt_King
- 19:00:23 [Sam_PAC]
- Sam_PAC has joined #aria-at
- 19:02:20 [michael_fairchild]
- michael_fairchild has joined #aria-at
- 19:04:24 [Matt_King]
- present+ James_Scholes
- 19:04:44 [jcraig]
- present+
- 19:04:50 [s3ththompson]
- s3ththompson has joined #aria-at
- 19:06:51 [s3ththompson]
- scribe: s3ththompson
- 19:06:53 [s3ththompson]
- TOPIC: VoiceOver support for Toogle Button
- 19:06:58 [s3ththompson]
- preset+
- 19:07:00 [s3ththompson]
- present+
- 19:07:24 [s3ththompson]
- present+ James Craig
- 19:07:40 [s3ththompson]
- present+ Matt_King
- 19:07:45 [s3ththompson]
- present+ Alyssa Gourley
- 19:07:55 [s3ththompson]
- present+ jcraig
- 19:08:04 [s3ththompson]
- present+ michael_fairchild
- 19:08:08 [s3ththompson]
- present+ Sam_PAC
- 19:08:13 [s3ththompson]
- present+ Seth Kovanic
- 19:08:23 [s3ththompson]
- present+ Isa Del Castillo Solis
- 19:08:29 [Seth_Kovanic]
- Seth_Kovanic has joined #aria-at
- 19:09:57 [s3ththompson]
- jcraig: Broadly, excited about ARIA-AT, my concerns with this issue don't have any impact on my support of the project at the whole. thanks for your work
- 19:10:33 [s3ththompson]
- jcraig: my understanding is that the goal of ARIA-AT was not to ensure complete uniformity in sonic interface design, but rather to ensure just that information was conveyed
- 19:11:09 [s3ththompson]
- jcraig: in the case of Toggle Button, the error was that we didn't output "not pressed" (rather we convey the absence of the button being pressed by not outputting anything)
- 19:11:33 [s3ththompson]
- jcraig: that was a conscientious interface design decision that has to do with our desire to cut down on verbosity in VoiceOver
- 19:12:26 [s3ththompson]
- jcraig: this reminds me a bit of an early html5 accessibility support matrix where dialog support was failing because it hadn't been implemented. based on my feedback, we were able to update matrix to distinguish between "failing" and "not implemented"
- 19:12:33 [jongund]
- jongund has joined #aria-at
- 19:13:21 [s3ththompson]
- jcraig: so i guess i have the same concern here. i want to focus on the ARIA-AT App bugs, and distinguish them as such from disagreements about interface semantics (like the "not pressed" vs not vocalized case)
- 19:14:44 [s3ththompson]
- jcraig: I think mike shebanek agreed, btw, about this project not being about screen reader homogeneity... he understands that the product marketplace allows for differentiation between featuresets and interfaces since specified homogeneity doesn't allow for much room for innovation or expansion beyond the norms
- 19:15:44 [jongund]
- jongund has joined #aria-at
- 19:15:58 [s3ththompson]
- Matt_King: i just want to underscore: no one is in disagreement about screen reader homogeneity. we all want to leave room for independent interfaces
- 19:16:13 [s3ththompson]
- Matt_King: i think ultimately it comes down to the list of considerations we wrote in the issue
- 19:16:33 [s3ththompson]
- https://github.com/w3c/aria-at/issues/784
- 19:17:57 [s3ththompson]
- Matt_King: let me try out an analogy / metaphor. i like to draw an analogy between aria attributes and how assistive technologies render them and css attributes and how browsers render them
- 19:19:13 [s3ththompson]
- Matt_King: we don't think everyone needs to implement the attributes in exactly the same way, but we think each attribute has a bounds for what is acceptable or not
- 19:23:06 [s3ththompson]
- Matt_King: for aria-at, we think in some cases simply not communicating information might be acceptable... but in others, the use case is important enough, that not communicating information is not acceptable
- 19:27:04 [s3ththompson]
- Matt_King: we thought this attribute needed to convey "not pressed": (1) because the status of the toggle is affected by activating the toggle itself (2) because we're considering a range of users (from beginner to expert) some of whom might not understand these patterns and (3) because there's currently an inconsistency with other binary patterns, incl. checkbox and even toggle button on iOS
- 19:27:49 [s3ththompson]
- jcraig: obviously, your usability feedback here is valid. i think i'm asking if there's a way to expand the capabilities of the reporting tool to perhaps allow this test to pass, with an asterisk.
- 19:28:28 [s3ththompson]
- Matt_King: we do have the ability to mark this issue as optional, but we thought this really should be a required test
- 19:31:40 [jugglinmike]
- jugglinmike has joined #aria-at
- 19:32:32 [jugglinmike]
- Hi folks; I just posted an issue that may be of interest to you, "The limitations of polling for vocalized text" https://github.com/w3c/aria-at-automation/issues/32
- 19:32:53 [s3ththompson]
- jcraig: for now, the main thing i can commit to is to file an issue requesting consistency between voiceover on macos and ios
- 19:33:04 [s3ththompson]
- jcraig: the best channel is to pass additional feedback through me
- 19:34:19 [s3ththompson]
- michael_fairchild: it sounds like explicitly conveying the "not pressed" state is more of a usability consideration than a bug. it's implicitly rather than explicitly conveyed
- 19:36:13 [s3ththompson]
- jcraig: one last point: it's true that checkbox is more verbose in this regard... but toggle button was expressed this way since before aria. since we wouldn't want to do something differently on the os vs. the browser, we really have a consideration that would be a big deal to change if we decided we need to
- 19:37:07 [s3ththompson]
- James Scholes: i do want to clarify: the comments that I posted on the issue were not my opinion, but rather the consensus of the people on the community group call that day... which included people who use screenreaders on a daily basis and people who test screen readers for a living
- 19:39:49 [s3ththompson]
- jcraig: thanks for clarifying, I also want to note that we have teams of screen reader users internally... this issue hasn't necessarily come up before, which leads me to conclude that it's not necessarily a large issue
- 19:40:23 [s3ththompson]
- Matt_King: just to interject, i want to also say that i would hope we don't limit the scope of our interoperability efforts to just those issues which are considered "large"
- 19:41:20 [s3ththompson]
- Matt_King: beyond that, i think one of the more salient concerns in the issue is that pressing the button doesn't necessarily announce anything even though a state change happens
- 19:41:25 [s3ththompson]
- jcraig: but there is a sound that plays
- 19:41:44 [s3ththompson]
- Matt_King: i think there are commands that don't play that sound, and it's a general voiceover confirmation sound that can be toggled off
- 19:42:20 [s3ththompson]
- James Scholes: i'm hoping there's a middle ground. obviously "mute button pressed" is too verbose... but surely some confirmation of state without restating the name of the button would be useful?
- 19:42:40 [s3ththompson]
- Matt_King: the issue for me is that sometimes i have to press the toggle 3 times to ensure that the state change actually happened
- 19:44:01 [s3ththompson]
- Matt_King: the problem is that the earcon (sound) is relayed even when the control is broken, since it's not dependent on the state change itself, it's just a response to the command being received
- 19:44:57 [s3ththompson]
- jcraig: it seems like we're in general agreement that some tests should be optional...
- 19:45:37 [s3ththompson]
- jcraig: i'm of the opinion that we should focus on getting core functionality working and reporting those results and then focus on the other usability issues on a case by case bases... but that we need some distinction in the failures to do that
- 19:46:13 [s3ththompson]
- Matt_King: it sounds like the most available middle ground is to mark some of these assertions optional... i am particularly interested in the ones that deal with announcing state change
- 19:46:54 [s3ththompson]
- jcraig: okay. i know the request to reduce verbosity came from users... in some cases though i understand the state change consideration
- 19:48:35 [jongund]
- jongund has joined #aria-at
- 19:48:45 [s3ththompson]
- jcraig: i hope it's clear that i'm not just saying no. i really want to argue towards the best outcome here
- 19:49:01 [jongund_]
- jongund_ has joined #aria-at
- 19:49:31 [s3ththompson]
- Matt_King: thanks for engaging jcraig. we hope this community group is a channel for those conversations
- 19:49:38 [s3ththompson]
- jcraig: thanks matt
- 20:02:38 [s3ththompson]
- TOPIC: Sneak peek at Candidate Test Review page
- 20:02:47 [Matt_King]
- rrsagent, make minutes
- 20:02:47 [RRSAgent]
- I have made the request to generate https://www.w3.org/2022/10/20-aria-at-minutes.html Matt_King
- 20:03:32 [Matt_King]
- scribe+
- 20:03:56 [Matt_King]
- Seth: shared screen showing current sandbox implementation of candidate test page
- 20:04:12 [Matt_King]
- Provided summary of functionality and objectives
- 20:04:51 [Matt_King]
- Community group testing of functionality is planned to begin at end of next week
- 20:04:58 [Matt_King]
- rrsagent, make minutes
- 20:04:58 [RRSAgent]
- I have made the request to generate https://www.w3.org/2022/10/20-aria-at-minutes.html Matt_King
- 20:29:28 [jongund]
- jongund has joined #aria-at
- 22:33:04 [jongund]
- jongund has joined #aria-at
- 23:48:55 [jongund]
- jongund has joined #aria-at