Meeting minutes
Review agenda and next meeting dates
Matt_King: Requests for changes to agenda?
Matt_King: Hearing none, we'll stick with the agenda as planned
Matt_King: I'm thinking about not meeting next week because IsaDC and James_Scholes are both out
Matt_King: I propose skipping next week and meeting on the next scheduled date, September 11, instead
Dean_Hamack: works for me
howard-e: That works for Bocoup, as well
Matt_King: Alright then; I will cancel the meeting scheduled for September 5
Matt_King: Next AT Driver Subgroup meeting: Monday September 9
Current status
Matt_King: The same set of test plans are in candidate review
Matt_King: We are making one decision: we're definitely putting the draft review of "disclosure navigation" on hold
Matt_King: We received a lot of feedback there, so IsaDC and I want to make sure that all the changes that need to be made actually ARE made before we move forward
Matt_King: We have the "action menu button" that we're working on right now, and then we'll be adding the "navigation menu button" to the test queue soon--possibly as early as today or tomorrow
Matt_King: It looks like Dean_Hamack is not assigned to anything right now, so we might assign some test plan runs for "navigation menu button" when we get that started
IsaDC: We're also going to be working on the "radio group" based on the feedback from Vispero, but that will be for a later day
Matt_King: Yeah; hopefully we'll have made some progress on that by September 11th
Testing action menu button with activeDescendant
Matt_King: It's almost done!
Matt_King: Two people have completed their runs on NVDA and VoiceOver. Those don't have any conflicts
Matt_King: I think IsaDC can publish the reports for those two runs
IsaDC: Okay, I'll mark them as "final"
Matt_King: That leaves us just with the JAWS report. Murray has run one test; IsaDC has run all 11
Matt_King: If Murray completes this while IsaDC is out, then I'll publish it. It doesn't seem likely to happen before next week's e-mail with Vispero, though
Matt_King: IsaDC could you send Murray and e-mail?
IsaDC: Sure
IsaDC: JAWS doesn't "convey menu item" but it does now. I think we discussed this last week. Every time you go to a menu item, it says "menu" every time you press "down arrow" or when you read the menu item
Matt_King: We could code this as excess verbosity
Matt_King: This could be two issues. One, it failed the assertion related to the "menu item" role, and two, it said the role "menu" two times which is excessively verbose
Matt_King: In this case, they aren't doing the "menu item" role.
Matt_King: Let's look at another test--how about test number seven, "navigate to the first item in a menu"?
Matt_King: That has "convey 'menu item' role" as a SHOULD assertion
Matt_King: I think that once you're inside the menu and navigating within it--I think Vispero and Apple will argue that conveying the "menu item" role as optional
Matt_King: We marked it as "should", though...
Matt_King: I think James Craig already raised an issue related to this, but maybe that was for the other menu
Matt_King: We actually don't have a test for navigating to "next" or "previous". We only have navigating to "first" and "last"
Matt_King: Maybe we should
IsaDC: I think it's because we have the arrow key commands for navigating to the first and last items
Matt_King: Ah, yes, maybe that's sufficient
James_Scholes: When you move from one menu item to another menu item, I think conveying the "menu item" role should be a "may" assertion
Matt_King: What about the number of items?
James_Scholes: I believe the number should be vocalized by default. Even though I have it switched off, I don't think it can be understated how useful that information can be
James_Scholes: My issue is that there is no pause between the item content and that information
Matt_King: In general, we have not made assertion like this "MUST" because you can still use the menu without this information
Matt_King: If you can make a commit that only changes the priorities, then we should be able to keep the results we've collected so far
IsaDC: Got it
Matt_King: So we're saying that the assertion is a "MAY" for those three tests
Matt_King: I believe Vispero has recognized this as excess verbosity and are tracking it with a bug
IsaDC: Okay, then I will mark those as "excess verbosity" and leave the "menu item" role assertion unchecked
New conflict resolution experience
Matt_King: I believe anybody with a GitHub account can look at the stuff in the sandbox instance
howard-e: That's right
Matt_King: If you follow this link to the sandbox and then make sure you're signed in with GitHub and then go to the "Test Queue" page...
Matt_King: https://
Matt_King: There's a whole bunch of stuff in the test queue on the sandbox right now. The final one is "toggle button"
IsaDC: It says "10 conflicts"
howard-e: Right. That's a link which brings you to a "conflicts" page
howard-e: You will also notice that the status for tests without conflicts, it says something like "x percent complete with zero conflicts." That felt a little verbose, so I removed the part about "zero conflicts"
howard-e: On the "conflicts" page, we were wondering about the title--is it too verbose or too short?
howard-e: We were also wondering about the heading structure
howard-e: The page has a number of disclosure elements. If you open one, you'll find a table
howard-e: The first column describes the testers, the second describes the assertions
howard-e: And here in this table, visually, it shows all the assertions which conflict with bold. We wanted to make these more prominent to AT users as well
howard-e: Should we just remove the rows which have no conflicts?
Matt_King: I was imagining to have a little more. This is just the pass/fail, but sometimes we can have conflicts in things like whether or not testers checked side effects
Matt_King: In our standard GitHub issue, we normally have a certain amount of information for each person. We have their output, the assertion, the command, and information about undesirable behaviors
Matt_King: I'm kind of wondering if we should have a table for each command, just like we do in the report
Matt_King: Maybe there's still a column for each person, but then there's rows for command, output...
howard-e: The assertion table I mentioned here is just for the "pass/fail" of the assertions themselves
howard-e: Elsewhere, there is a table for unexpected behaviors
Matt_King: But we don't have anything for the AT response right now, correct?
howard-e: That's correct; we do not
Matt_King: It feels like there is less information here than what we normally get in a GitHub issue. Or at least, that the information is more spread out
Matt_King: Maybe there could be a heading for each command. Isn't that how we normally structure it?
howard-e: Yes, it is
Matt_King: When you see a conflict, then if there is an issue, that's great. But I think we need to tie the issue to each conflict...
howard-e: This presents the same issue template that you would get from the "test run" page
howard-e: One last item: when viewing this page as an admin, there is also a button to open the test as a tester. It will now bring you directly to the relevant test rather than the first test in the test plan
Matt_King: I think we only want to show were there are conflicts--we don't want to show where there is agreement
Dean_Hamack: I agree with that
IsaDC: I agree, too. Otherwise, it's over-crowded and you don't have an easy way of finding the conflicts, as a screen reader user
[Matt_King proposes a detailed alternate design]
Matt_King: this is going to be awesome!