Meeting minutes
VoiceOver support for Toogle Button
preset+
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
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
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)
jcraig: that was a conscientious interface design decision that has to do with our desire to cut down on verbosity in VoiceOver
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"
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)
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
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
Matt_King: i think ultimately it comes down to the list of considerations we wrote in the issue
https://
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
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
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
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
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.
Matt_King: we do have the ability to mark this issue as optional, but we thought this really should be a required test
<jugglinmike> Hi folks; I just posted an issue that may be of interest to you, "The limitations of polling for vocalized text" https://
jcraig: for now, the main thing i can commit to is to file an issue requesting consistency between voiceover on macos and ios
jcraig: the best channel is to pass additional feedback through me
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
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
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
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
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"
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
jcraig: but there is a sound that plays
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
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?
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
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
jcraig: it seems like we're in general agreement that some tests should be optional...
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
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
jcraig: okay. i know the request to reduce verbosity came from users... in some cases though i understand the state change consideration
jcraig: i hope it's clear that i'm not just saying no. i really want to argue towards the best outcome here
Matt_King: thanks for engaging jcraig. we hope this community group is a channel for those conversations
jcraig: thanks matt
Sneak peek at Candidate Test Review page
Seth: shared screen showing current sandbox implementation of candidate test page
Provided summary of functionality and objectives
Community group testing of functionality is planned to begin at end of next week