Meeting minutes
Review agenda and next meeting dates
https://
Matt_King: Requests for changes to agenda?
ChrisCuellar: There's an open issue (#1349) that was filed by james. I wanted to remind folks to check on it
Matt_King: We'll do that first
Matt_King: Next CG meeting: Thursday August 21
Matt_King: Next AT Driver Subgroup meeting: Monday September 8
Lack of screen reader feedback after pressing "Submit results" button
github: w3c/
ChrisCuellar: This behavior is somewhat confusing; we do we do it?
Matt_King: We do it to allow testers to confirm that their submission was correct
James: I would be in favor of a button which saves your results and also moves on to the next test
Matt_King: Another reason for "submit" is that, if there is errors, it prompts you to go back and correct them
Matt_King: We have a "next" button so Testers can advance without losing what they've done
Matt_King: It always saves what you input regardless of which button you press, but it doesn't validate the input if you press "next"
ChrisCuellar: I had some proposals in that issue, so I wanted to remind folks to revisit that discussion
Running vertical temperature slider test plan
Matt_King: I think people simply haven't had time to do the work we assigned last week
Matt_King: Last week, we had conflicts with NVDA and resolved them, and then published the results
Matt_King: For JAWS, we noted that IsaDC was using an older version than Joe_Humbert. She was going to re-run that to resolve the conflicts
IsaDC: I haven't found the time to do that, yet
Matt_King: Okay, that's fine
Matt_King: Then for VoiceOver, we had a bug where if we had already saved results, there were still assertions that were being checked. It didn't automatically unchecked the "yes"/"no" radio buttons when you designated "untestable"
Matt_King: Is that bug resolved?
jugglinmike: It is not resolved
Carmen: But it is ready for release, and we're aiming to release the fix this afternoon
Matt_King: Okay, then that's as far as we can go with the "vertical temperature slider" test plan
Running accordion test plan
Issue 1269: Conflicting JAWS results: "Navigate backwards to an expanded accordion header" (Accordion, Test 2, Command "'Shift Tab' (PC cursor active)"
github: https://
Matt_King: Ah, Louis closed this issue last week. This is an agenda mistake
NVDA
Matt_King: Both your browser and NVDA versions are different. Louis is using a newer release of both pieces of software than Joe_Humbert is
IsaDC: I got the same responses as Louis when I tested with the latest release
Joe_Humbert: I'll re-test, then
VoiceOver
Matt_King: All of the tests related to navigating backwards with the quicknav key--those are all going to be affected by this bug in marking as "untestable"
Matt_King: Are there any other problems?
dean: I don't think so
dean: At least, not for the "navigate backwards" test
dean: But as for "navigate forwards", there seem to be some other kinds of discrepancies
dean: In test 3, we got the same AT response, but I marked it as "pass" while the other tester marked it as "fail"
<Joe_Humbert> NVDA conflicts resolved for Accordion
Matt_King: Are you supposed to navigate forward to the personal information? Or to the one after that?
Matt_King: I think that it might be failing because that might be the wrong heading. As in, it didn't actually move..
Matt_King: It's supposed to go to the "billing address"
dean: ...but it's going to the wrong one
dean: Okay, I need to revisit some of my tests. That should resolve some of these conflicts
Matt_King: The command failed which made the assertions untestable
Matt_King: You'll have to wait for the upcoming app fix regarding the "untestable" feature before you can report that, though
Matt_King: We might have a bug in the conflict report, because the conflict report may be showing "fail" instead of "untestable"
Running tabs with automatic activation test plan
Matt_King: There were some issues opened, but I didn't get them added to the agenda
Matt_King: The issues that I looked at weren't related to conflicts; they were related to the test plan and to the app
Matt_King: For JAWS, we have four conflicts. For VoiceOver, we have 3 conflicts. It appears that NVDA is all the way done--awesome!
IsaDC: Hadi posted a question about the "tab list" role announced as a group
louis: I don't think any of the screen readers actually say "tab list", right?
Matt_King: JAWS used to
louis: That's a point of confusion that I'd like to clear up
Joe_Humbert: There are some things that I didn't change despite agreeing with your verdicts because I wanted to discuss them here in this meeting
Matt_King: You did raise some issues, Joe_Humbert, and I did want to get to those.
Joe_Humbert: Let's start with the conflicts because I think those can be resolved
Joe_Humbert: The conflict I had in test 1: we had the same output, but the assertion is that the name of the tab list is conveyed. It is not. The heading before the tab list is spoken
Matt_King: That is a really good question.
Matt_King: You press the "down arrow" once, and it reads the heading. When you press the "down arrow" again, it reads the tabs without indicating that it is in a tab list
Matt_King: I wonder if we should change this test. Should we move the navigate forward from here after the heading?
Matt_King: I think that would make the output a lot more clear
Matt_King: I think if you were reading the report and not looking at the test case, you would be very confused about the failure here
Matt_King: We can fix that by moving the link
Matt_King: There's also a surprising bug in VoiceOver when you are navigating backwards
Joe_Humbert: The other question I have is about the same conflict with unexpected behaviors
Joe_Humbert: Louis reported that reading all the tabs is an unexpected behavior
Joe_Humbert: I agree that it's unexpected behavior for anyone who has not used NVDA before, but I think that anyone who has used NVDA would expect it to dothat
Matt_King: When we did the "radio" test plan, we agreed that because that is how NVDA works (and because they could argue that it's okay even though a lot of us would say it's terrible)
Joe_Humbert: My complaint about it is as follows: when you are navigating virtually, and it's reading out everything, it can be very difficult for a novice user to recognize when inputs are selected
Louis: that's a challenge even for advanced users!
Matt_King: Didn't we agree that we couldn't call that a negative side effect because that's actually us delving into the realm of telling them how to essentially design their screen reader?
Matt_King: We came across this with the "Down arrow" for radio buttons
Joe_Humbert: Any times you have a set of controls which are grouped together, NVDA basically reads the entire group
Matt_King: But only if they're horizontally aligned visually
James: I think we decided that, for radio buttons, we can't report a failure because NVDA would say that the screen reader is functioning as intended (it's just that we find the intended behavior questionable)
Matt_King: We can't call it a negative side effect. They wouldn't call it excess verbosity, and all the information they are reported is accurate
Matt_King: That was our rationale for not calling it a negative side effect (even though it kind of makes our stomach churn)
James: I ran a survey prompted by this meeting, and the responses were overwhelmingly "no" and "I don't know what that is"
Joe_Humbert: It sounds like, for now, we should remove reports of unexpected behavior
Louis: Yup. I can do that
Test content and VO bot Feedback: "Navigate backwards into a tab list where a tab is not selected" (Tabs with Automatic Activation, Test 2)
github: w3c/
Joe_Humbert: When you run test 1 (navigating forward into a tab list), when you run the test setup, no tabs are selected and no tab panel is visible
Joe_Humbert: For test 2, however, after running the test setup, a tab is selected and a tab panel is visible
Joe_Humbert: I couldn't tell if this difference was intentional
IsaDC: You have to navigate to the first tab
Matt_King: What we could do to make these more equivalent is select the second tab and then place the focus on the "navigate forward" link
Matt_King: What I want feedback on my suggestion to changing the way the test is named
Matt_King: I suggested we change it to "Navigate backwards to a tab that is not selected". Would that make the intent of the test more clear?
Joe_Humbert: Sure. Most of the time you have the "navigate forward" and "navigate backwards" tests, the results are often very similar. Here, though, they were very different
Joe_Humbert: I also think test case 1 is a test case that would never happen. I've never seen a tab panel where a tab isn't selected
Matt_King: In issue 1280, there are two other recommendations related to naming. These will impact multiple tests (the name and content changes). All of tests 1 through 4 would need modifications to the wording. And test 1 would need modifications to the script
Matt_King: I think there are in general three changes to the tab plan. First, for all tests, move the "navigate forward from here" link to after the heading
Matt_King: the second change is for test 1 only: change the script so it selects the tab and sets the focus on the "navigate forward" link
Matt_King: The third is for the first four tests: change the name and the instructions
IsaDC: Got it
Joe_Humbert: I have a question about the implementation. When you navigate forward or backward, the tab panels are present even for the ones that are not selected. Is that intentional?
Matt_King: I believe those tab panels are styled with "display: none" (you can't see them visually), but VoiceOver reads them, anyway
Joe_Humbert: Is that the way it's supposed to be?
Matt_King: No!
Joe_Humbert: Well, I looked at the pattern, and it doesn't say anything about how they should be hidden in the pattern
Matt_King: It doesn't?
Joe_Humbert: No
Matt_King: Perhaps it's implicit
Joe_Humbert: aria-hidden is not mentioned, and it doesn't say that you need to hide them
James: It says that you display one at a time