Meeting minutes
Review agenda and next meeting dates
https://
Matt_King: Requests for changes to agenda?
Matt_King: Hearing none, we'll stick with the agenda as scheduled
Matt_King: Next Community Group Meeting: Thursday October 31
Matt_King: Next AT Driver Subgroup meeting: Monday November 4 (Note: Matt not available due to travel)
Current status
Matt_King: We'll skip this topic this week. Please see the agenda for the latest information
Testing action menu button with activeDescendant
Issue 1144: Priority of posinset and setsize assertions in test 5 "Open a menu to the last item"
github: w3c/
Matt_King: Apple does not think the assertion in question should be a "must" or a "should". They believe it should be fully optional
Matt_King: I've been giving this a lot of thought, and I actually was just about to make a change to the test plan, but the community group needs to weigh in, first
Matt_King: Do folks think screen readers "should" exhibit this behavior? Or just that they "may"?
Matt_King: I think the default would be toward consensus among vendors. In this case, the most straightforward path to consensus is "may"
Matt_King: In the action menu button, we have a test that opens the menu. Once the menu is open and focus is on the first item, you press the "end" key or the "arrow" key to move to the final item. The question is, when you press one of those keys, should it say "action 4" or "action 4, 4 of 4"?
Matt_King: Apple doesn't think that VoiceOver "should" convey the position ("4 of 4" in this case)
Michael_Fairchild: Did Apple share their rationale?
Matt_King: They shared their rationale in a comment on the issue
Matt_King: For context, VoiceOver does do this for tabs, radio buttons in a radio group, and items in a list (which they sometimes call a "table")
Matt_King: VoiceOver does not do this in folders or menus. Additionally, in their verbosity settings, they don't offer a way of changing this behavior
Matt_King: VoiceOver does allow users to toggle announcement of "name", "status", and "type"
Michael_Fairchild: My initial reaction is in line with Matt_King--that it makes more sense to convey it than to not convey it. But I'm still processing...
James_Scholes: The implication that the information shouldn't be conveyed because it isn't onscreen makes me uncomfortable. I'm sure we can all imagine a huge number of cases where a screen reader conveys information that isn't immediately present in visual form
James_Scholes: A sighted user certainly can see that a given collection has a large number or small number of items
James_Scholes: There's also an argument to be made for consistency
James_Scholes: And also weighing on my judgment is the fact that they don't let you opt in or opt out of receiving this information
James_Scholes: To be honest, I disable this kind of information in my screen reader of choice. I'm partly speaking for the many screen readers who I know rely on this information as essential to their way-finding
Michael_Fairchild: the more I'm thinking through it, the more I agree. Visually, you have a sense of the size of a menu and your relative position within the menu
Michael_Fairchild: Also, whenever you loop around, there could be some ambiguity as to whether the looping occurred--especially with longer lists
Michael_Fairchild: I think it makes more sense to convey it than not
Michael_Fairchild: Would it be sufficient to say that there should be a mechanism to convey something like this?
Matt_King: We don't have any testing related to what users could do by changing settings. That would be a level of complexity that I don't think we would want to add to the project
Matt_King: Stepping back a bit, I've been observing lately some of the conversations we've been having with Vispero about "should" versus "may".
Matt_King: It seems more and more common that leaning toward "may" for things that are... If you were to build a brand-new screen reader from the ground-up, and you had to prioritize functionality toward things that are going to enable people to work with your software. That's what "must" is about
Matt_King: I think Vispero is starting to regard "should" as a reasonably high bar, as well, because ATs get dinged for not satisfying those
Matt_King: So we have to be fairly confident when we use "should" that failing to implement the behavior actually degrades the experience in a meaningful way
James_Scholes: I think many people would argue that the high bar is met by wayfinding information. Cena is one
James_Scholes: I don't believe Vispero has raised any concerns about this particular information
Matt_King: They have not
Matt_King: When you're moving through the menu, I think we're aligned on the information being a "should"
Matt_King: Not getting this information remains the hardest thing for me as a VoiceOver user on a Mac
Matt_King: When I go to the desktop on the Mac, the fact that I have no idea how many icons are on the desktop (especially when there are many)--that's really hard!
James_Scholes: You gave the hypothetical about if you were building a new screen reader. Well, PAC did build one, and we never even considered not including this information in menus
ChrisCuellar: Maybe "should" could be conveyed as more of an interop nudge
ChrisCuellar: If all other vendors agree that this is a "should" and we can capture sentiment that end-users find this really valuable, then that becomes part of advocacy for interoperability--about one implementation being a bit of an outlier
Matt_King: I started drafting a comment to James Craig to request clarification on his words about what appears on the screen, what doesn't appear on the screen, and what ARIA has to say about this
Matt_King: I could also ask about the data behind the design of conveying this information in some circumstances but not other circumstances
Matt_King: This would also be a good topic to include in the agenda for my next meeting with Vispero
James_Scholes: We've had many discussions of this sort over the years, and the CG has historically been willing to compromise. That doesn't appear to be the case for this issue
Conflicting results for test 6 "Request information about a menu item"
github: w3c/
Matt_King: This may have been resolved already (in fact, many of these may have been resolved already), but I want to verify
Matt_King: IsaDC raised this conflict in VoiceOver testing back in August
Matt_King: The conflict is between Joe's results and IsaDC's results
Matt_King: The assertion for "name of the menu"
IsaDC: We solved it because the test plan has been marked as final. We just need to document the reason. I'll review the minutes for that meeting and then close the issue
James_Scholes: It says "'actions menu' is in the VoiceOver cursor" but for Joe, it says "'menu' is in the VoiceOver cursor"
Matt_King: We finalized this report
IsaDC: That's right
Matt_King: Okay. I'm going to say this is resolved and close it
Testing Disclosure Navigation Menu
IsaDC: We decided to run the bot and start from scratch
Matt_King: Not all these issues are equivalent. Several of them had to do with the "Fn" key issue
Dean: Apologies. I figured out the issue with my external keyboard.
Dean: I had intended to this prior to today's meeting, but I got side-tracked this week due to circumstances beyond my control. I will have it done by next meeting
IsaDC: The bot has reported some incorrect AT responses for some tests, so please watch out for that. It isn't much--just some small details
Dean: Yeah, otherwise, it looks like the bot is doing a pretty good job
Matt_King: Should we add any of this information on external keyboard setup in the wiki?
Dean: My situation might not be too weird. I'm using an Apple keyboard, after all
Matt_King: If the wiki page isn't discoverable, it might not be worth the effort
Dean: Ah, it's right at the top of the article on how to use VoiceOver
Dean: https://
Matt_King: Do you want to review these issues to determine if they are still valid, IsaDC?
IsaDC: Sure
Testing navigation menu button
Matt_King: The first is issue #1136
Conflicting VoiceOver results for test 3 "Request information about a menu button"
github: w3c/
Matt_King: On this one, Dean is 9 out of 10 tests complete
Matt_King: Are we going to take the same approach for this one as we did for the disclosure navigation menu? After disclosure is done, do you want to do the same thing?
Matt_King: I ask because there are 14 conflicts between IsaDC and Dean
Matt_King: Basically just start over and run the bot
IsaDC: Sure, if Dean agrees on restarting that test plan as well
Matt_King: How many tests is this across? Test 3, 4, 5, 7, 8, 9... There's conflicts in basically all but 1, 2, and 6, it seems like
Matt_King: That is--more than half
Matt_King: It might actually be faster to wipe out the results and start over with the bot
Dean: I think it will be the same amount of work for me, in the end, anyway.
Dean: Let's just leave this one as-is and I will correct my results without the assistance of the bot
IsaDC: Okay!
Testing radio group
Matt_King: Vispero and Apple gave us feedback on conveying the "not selected" state
Matt_King: We made these changes to the test plan based on their feedback
Matt_King: The system automatically copied the results for anything that didn't change from the previous test plan version
Matt_King: For JAWS, everything is complete. You could publish that report, IsaDC
Matt_King: For NVDA, I'm not sure why it says "13 of 15 tests". That needs some attention. It was originally assigned to Alyssa and IsaDC
Matt_King: I don't remember adding extra commands to this
Matt_King: For VoiceOver, everything is 100% complete, so that one can be published
Matt_King: Something is going on with NVDA, I'm not sure what that is. It might be a bug
Matt_King: This is mostly how it ought to work. If we change a test plan, and it doesn't change anything about how results are collected, then the system should just take the prior results and copy them in. It's really cool because it saves us a bunch of time