Meeting minutes
Review agenda and next meeting dates
Matt_King: Requests for changes to agenda?
IsaDC: There are major updates for VoiceOver and JAWS
Matt_King: Yes, though I don't think we have time to deal with those today
Matt_King: We had some discussion of the JAWS update
Matt_King: Actually, these might impact what people do this week. Lets spend some time on that today
jugglinmike: I'd like to give some visibility to an AT Driver issue
dean: I think we need a tiebreaker for when there are conflicts
Matt_King: Generally speaking, that's going to be me
Matt_King: But we're always open to feedback on how we work
Matt_King: Next Community Group Meeting: Wednesday November 20
Matt_King: No meeting Thursday November 28
Matt_King: Next AT Driver Subgroup meeting: Monday December 9
Current status
Matt_King: We're a little bit stuck in getting the rest of the stuff to candidate review. They're mostly blocked by issue 365, so hopefully we'll unblock those today
Matt_King: The big thing here is that I'm really hoping we'll be able to step up testing as we approach the end of the year
Matt_King: I want to wrap up the ones in the queue, and there are three more that I was hoping to have ready today. All of those will for sure be ready for testing before next Wednesday's meeting
Matt_King: We're going to have plenty of work for folks to do!
Issue 365: Impact of hints on testing
Matt_King: I'm trying to thread the needle here, but I'm not sure we can make everybody happy in this situation
Matt_King: I am proposing a solution for how to treat hints
github: w3c/
Matt_King: I wrote a definition of "hint"
Matt_King: I'm calling it supplemental output that is provided by the screen reader
Matt_King: The full definition I'm proposing: "Supplemental output provided by a screen reader that is intended to help users understand an element or how to use it. Hints are distinct from base output that includes required information, such as name, role, value, state, and properties. Hints may repeat information that is included in base output. hints that are conveyed with speech are spoken after base output."
IsaDC: I read it, and I agree with it
jugglinmike: Does this definition's focus on screen readers exclude other kinds of ATs? Do other ATs even have a concept of hints?
IsaDC: On the iPad, VoiceOver doesn't consistently use hints with Braille displays. In some cases, they disappear very quickly
Matt_King: I'm happy to change the wording to be a definition of "screen reader hint" as opposed to any other kind of hint because I do think what we're trying to address is specific to screen readers
Matt_King: JAWS calls them "messages". I intentionally chose not to use proprietary language
dean: If you wanted to be exact, I think the blanket term would probably be something like supplemental information
Matt_King: In our content design at Meta, they're referred to as "hints." I don't know how other people do it
dean: I vote for "screen reader hint"
<Joe_Humbert> Hint: Supplemental output provided by a screen reader that is intended to help users understand an element or how to use it. Hints are distinct from base output that includes required information, such as name, role, value, state, and properties. Hints may repeat information that is included in base output. hints that are conveyed with speech are
<Joe_Humbert> spoken after base output.
mfairchild: My brain went to "well, the screen reader decides how to provide everything, so everything is provided by the screen reader"
Matt_King: We could say, "provided by the screen reader and not the application content"
Matt_King: As for testing guidance
Matt_King: I've proposed a sort of question--"Why AARIA-AT does not test hints, i.e., test assertions do not apply to hints?"
Matt_King: I gave two reasons for why the assertions would not apply to the hints
Matt_King: The first is that the hints are supplemental output and that the scope of ARIA-AT is limited to the essential functionality (hence why we have MUST/SHOULD/MAY distinctions)
Matt_King: The second (which we probably discussed the most) is that for certain screen readers, it's really common for users for disable hints. If that's so common for screen readers, and if the hint were to provide essential information, then for those users, we would have to say that the hints are not "supplemental" or "optional", and we can't do that
Joe_Humbert: I want to head something off--something we're working through at the Google Accessibility Task Force. Certain elements in iOS and Android do not provide a role, they only provide a hint
Matt_King: Yes, I recognize that. We're not there yet, though.
Matt_King: Some organizations are taking different approaches to deciding whether that is a problem or not
Matt_King: At Facebook, we've had really long discussions about that for things like the Facebook New Feed (a really long widget)
Matt_King: Because people use that constantly, we wonder whether or not it actually needs a role
Matt_King: But it's a fair point, Joe_Humbert
Matt_King: When those kinds of things come up, though, maybe we would say conveying the role is optional.
Matt_King: We're not doing iOS and Android, yet, but I can't wait until we do!
Matt_King: Anyway, those two points I laid out are why I am suggestion why the hint does not contribute to the assertion verdicts
Matt_King: The next part of my proposal is about whether we leave hints on during testing
Matt_King: I think we should, and I have two reasons for that, too
Matt_King: When we capture an AT response, we want that response to be comprehensive--that is, including all side-effects of the command under test, positive and negative
Matt_King: We could consider a helpful hint to be a positive or neutral side-effect
Matt_King: There's also the automation system to consider
Matt_King: Where it would be difficult to omit hint text
Joe_Humbert: I often have to edit the text from the automation system; inserting commas which can change how the output is interpreted
Joe_Humbert: Also, why are we capturing it in the output if it doesn't have any impact on the assertion?
Matt_King: We have to be able to see what the complete response in, in order to render a verdict
Matt_King: I wonder if Braille display includes commas...
IsaDC: They do not. It's just like the speech
Joe_Humbert: Does it separate the pieces, even without a comma?
IsaDC: It does, via a double space
Matt_King: If I turn on all punctuation in VoiceOver, I don't think it speaks commas
Matt_King: I don't know about adding commas. That's an interesting thing
Joe_Humbert: It's a separate topic, though. I don't mean to derail this conversation
Matt_King: Testing with default settings, except for the two exceptions we've documented
First exception: a setting which is frequently changed by users e.g. quick nav on/off, browse mode vs focus mode, etc.
And second: if a particular feature is, be default, expected to be hidden behind a setting
Matt_King: When you take all these things together, you get the testing requirements I proposed
First: "Because hints are sometimes part of an AT response, they are included in the AT response recorded for a command. The goal is for response collection to be comprehensive; it must include both positive and negative side effects of the command. Good hints an be considered a positive side effect while inaccurate hints can be considered a negative side effect."
Matt_King: This puts an important requirement on all of our testers
Matt_King: All of our assertion verdicts are determined by people, and they must have the basic skill to be able to differentiate between basic output and hint
Matt_King: In other words, if we go with this proposal, Testers will need a specific exptertise
jugglinmike: This expertise seems to preclude the use of Mechanical Turk or of natural language processing
Joe_Humbert: I think an AI could be trained to determine hints
Matt_King: Or a bot could run the test twice; once with hints enabled and once with hints disabled
jugglinmike: If we publish "AT response" as a single string, we will be hiding away the human interpretation that is the designation of "hint text"
Matt_King: I agree. It adds some complication, though, and I'm not sure we want to go down that path right now
Matt_King: For right now, I think it's going to be important to add a link to the report pages that includes information about interpreting hint text
jugglinmike: It's good to think a bit in advance about this, though
Matt_King: Right. We could one day extend automation to automatically fill in "basic response" and "hint text" should we track those as separate attributes
Matt_King: Okay, back to the proposal on the table
Matt_King: I'm not hearing any objections, but I'm also not hearing any elation
Joe_Humbert: I just want an answer either way so I can test efficiently and consistently
dean: I'm in the same boat
Matt_King: I will note that this issue is more than three years old (practically four years old). I was surprised to learn its age when I wrote this up. I'll be happy to resolve it!
Matt_King: I'm going to close this proposed solution, but first I will update the wiki (extend the glossary and the testing guidance). We will also create an issue related to linking the reports to some documentation about reading the reports
Testing Action menu button with element.focus
Matt_King: We have only IsaDC assigned, so we're in dire need for more Testers!
dean: Aside from tie-breakers and some clarity that I got this morning, I should be able to get through the tests I'm working on in the next couple days. All this to say: I'm available to help with VoiceOver on this one
Joe_Humbert: I just signed up for VoiceOver and NVDA on this test plan
Matt_King: Thank you both!
IsaDC: Thank you!
Matt_King: If both Dean and Joe_Humbert can do VoiceOver, then maybe IsaDC can switch to another (since I know IsaDC has a ton on her place)
IsaDC: And Luke, my coworker at PAC, can take over JAWS
Testing Disclosure Navigation Menu
Matt_King: The only work remaining for this is VoiceOver
IsaDC: And we have four conflicts
Matt_King: And Dean has six left
Matt_King: There are multiple issues opened related to conflicts
IsaDC: Some of those are kind of pending because I don't know if they're going to come up again. I think they belong to the last test...
Matt_King: Test 2, test 7, and test 14. Are these all the same?
IsaDC: When I press enter on the button or on the link, I don't get any output
Matt_King: Ah, yes, I forgot about this
IsaDC: It expands, but it does not announce the change
IsaDC: I updated my Mac, and I still don't get that output
Matt_King: I definitely get output when I do Ctrl+Option+Space
Matt_King: I haven't seen if it changed with Enter
dean: I haven't performed an update in a few weeks, so that could explain something
Matt_King: Oh, howard-e, when we're looking at the conflicts, we can't see the versions that each person is using (neither AT versions nor browser versions)
howard-e: Ah, yes, that's important! I'll make an issue to track that
dean: I am running MacOS 14.5
Matt_King: that makes me really curious, then. When I was on 14.5, and I used the "enter" key, I got the same response as IsaDC--that is, no speech at all
dean: I am using an Apple-branded keyboard during my testing
Joe_Humbert: That's good to know because technically, "enter" and "return" are slightly different
Matt_King: Every time I pair my Windows keyboard to my Mac, "ctrl+option+space" and "enter" do behave consistently with how they behave when I used the laptop keyboard
dean: Both of my keyboards (my Apple external keyboard and my MacBook pro) have "return" keys
Matt_King: I'm wondering how you got output using the "enter" key. It feels like such an aberration.
Matt_King: If we need a tiebreaker... I wonder what the bot reported here.
dean: Should I update from 14.5 so we're on the same page?
Matt_King: I think that would be helpful, as long as its not a problem for you
dean: For example. Conflicts on "navigate backwards to a collapsed disclosure button". I recorded output and IsaDC reported output that is identical. We only assigned different verdicts
Matt_King: That's test 2
Joe_Humbert: There is a slight difference between the responses. One includes the word "navigation" and the other does not
IsaDC: I just went with the bot there.
IsaDC: I think I need to re-test this
dean: This was my confusion. I think the bot may be going through it too fast and not capturing all the output. That's a hypothetical, but I don't think we can rely on the bot.
jugglinmike: The bot does observe a delay before considering the AT done speaking. If anything, I have previously thought that delay was excessive, but we can look in to it
IsaDC: In any event, I will re-test this
dean: My only other comment was kind of philosophical (and I may be overthinking it). If the test says, "get information about X", but there are three steps to get there, then you aren't just getting information about "X", but rather information about the complete path to get there
Matt_King: Which test are you talking about?
dean: Any test with three commands
Matt_King: Oh, that's test 2
Matt_King: You are navigating from point A to point B. That's the thing we're testing
Joe_Humbert: I went to the ARIA APG example for disclosure, and VoiceOver 14.6.1 said "about comma expanded comma button". To be accurate, I'd like to test it as rendered within the actual test queue
"Activate element" user intent
github: w3c/
jugglinmike: [asks clarifying question]
Matt_King: if the virtual cursor is already on an element then if you press enter, it activates the element. that is more equivalent to doing a mouse click. that's essentially what it does (simulating a mouse click)
jugglinmike: this was prompted because i misunderstood what we wanted by activate elemtn. i thought we wanted something where we'd update the document focus to be the element where the virtual cursor goes
Matt_King: yes and that's exactly what Enter does. no activate element could also mean if you are on a checkbox, it checks it, on a radio button then it pushes
jugglinmike: okay so i'm now learning that's what we want
Matt_King: yes, i'm pretty sure this is the intent we want for activate element. now interestingly, there are scnearios where ctrl+opt+space. maybe by default it moves focus but you have to change a setting to make it also move focus. so we can define that as the intent. Both set element.activeelement to that element and simulate a mouse click
jugglinmike: okay, totally fine. we can specify what we want. Let's just make sure we're specifying the right thing here. I previously wasn't even considering VO. But actually if the semantics is more broad than that (activating element and do mouse click) then it would be a meaningful command
Matt_King: Okay great
jugglinmike: Thank you howard-e for minuting that