Meeting minutes
Review agenda and next meeting dates
https://
Matt_King: Next AT Driver Subgroup meeting: Monday February 10
Matt_King: Next Community Group Meeting: Wednesday February 12
Matt_King: Requests for changes to agenda?
Matt_King: Hearing none, we'll move forward as planned
Current status
Matt_King: IsaDC is working on a spreadsheet that will help us figure out a schedule for draft review and candidate review of the revised test plans
Matt_King: With that, we'll be able to set some targets for around June
Matt_King: I've been trying to get the revised versions of both radio group test plans into the test plans. They are so close, but there are so many details
Matt_King: It feels like really really on the verge of getting these two test plans into the test queue
Matt_King: Despite all the delays here, I'm feeling very confidence that they will be ready in time for next week's meeting
Testing status
Matt_King: I don't see any testing conflicts on any of the three things that are actively being worked on. We can talk about each on in turn
Matt_King: The first one in the queue is Disclosure
Matt_King: We have IsaDC, Joe_Humbert, and mmoss all assigned to this
Matt_King: It looks like Joe_Humbert is done
Joe_Humbert: I assigned myself over the weekend because I had the time
IsaDC: That's awesome, thank you!
Matt_King: I think we may want to rely on mmoss in this case and save some of your time, IsaDC
Matt_King: For the "link" test plans
IsaDC: They both have JAWS pending, and we are planning to complete them by Monday
Matt_King: There are no conflicts in NVDA, so I think NVDA is done
Joe_Humbert: In that test plan, there are tests that ask you to press a button to get information about a link. NVDA says "linked" at the end--is that correct?
Joe_Humbert: I think it could be confusing
IsaDC: I was going to mention that, as well
Matt_King: It's not normal behavior
James_Scholes: This is probably related to NVDA's internals, where links have a state named "linked"
James_Scholes: NVDA does track the "visited" status as well
Matt_King: It does feel like excess verbosity to me. We could mark it as such and label the problem "moderate". It seems like it's worth calling out because there's no value in that state...
Joe_Humbert: Yeah. When would a link not be linked?
James_Scholes: I think it may be related to spans of text...
James_Scholes: I've found a link on Wikipedia that doesn't have a "linked" state
James_Scholes: I think the likelihood of their fixing this particular behavior is very low
Matt_King: That doesn't mean we shouldn't report it, though
IsaDC: I can update both test plans
Matt_King: Well that was unexpectedly interesting!
James_Scholes: This looks to be an exposure of the underlying IAccessible2
Matt_King: Looking at link example 3, we only have JAWS remaining, and IsaDC told us that will be done by Monday
Matt_King: We're not going to talk about radio group--that's on hold
hadi: Why is it on hold?
Matt_King: We were working on changes due to the issue that the setup script was hiding a heading and changing results. We made a decision to change the script and then re-run the effected tests
Matt_King: Hopefully your work will be preserved!
hadi: I hope so, too
Matt_King: Hopefully we'll have this back on the agenda next week
Issue 1194 - Same-page link assertions
github: w3c/
Matt_King: This came up during the testing of the disclosure navigation menu
Matt_King: The thing that we're testing is the behavior that occurs when you activate a same-page link
Matt_King: In the disclosure navigation menu example, you activate a link in the navigation menu to the overview page, and the example script loads the content of the overview page which includes a heading that says "overview"
Matt_King: What happens is your screen reader reading cursor is placed at that point in the DOM (it travels from the link overview to this place on the page in the heading)
Matt_King: The href on that link is pointing to an ID and the ID is on a DIV, and that DIV includes that heading as well as some additional content
Matt_King: We have written assertions for that test, and the assertions are currently saying that it should announce the heading role, the heading level, and the heading text
Matt_King: but we don't have a basis for those assertions in the standards!
Matt_King: Because the heading is just the first thing in the div
Matt_King: This came up in our meetings with Vispero because their behavior in this particular case was not great, and they fixed two bugs. It prompted a discussion about what "SHOULD" the behavior be?
Matt_King: The challenge with same-page links is that they could be pointing to an empty span, a container with a lot of content, a semantic element like a heading, or a element with no semantics and just a text node
Matt_King: We're kind of in a tough position here because if we want to have expected behaviors that work for any same-page link...
James_Scholes: I'm not sure that we do want that
Matt_King: Great point. I wrote about this in the issue
Matt_King: If we're going to define expected behaviors for any specific example. Say we were going to test a bunch of different examples--we would need some kind of approach to saying what the expected behaviors for each of them. What is the basis for saying "these are the things that should be spoken in this specific case?"
James_Scholes: It sounds like what we're implying is the behavior of the common-case even though we're only testing one pair of roles
Matt_King: When we test combo box, we will use the exact same principals for every single combo box
Matt_King: In essence, in all these cases, if you go back--from our tests, we're going to be able to derive general principals about expected behaviors. This is kind of test-driven standards development, in a sense
James_Scholes: I agree. But there are always cases that are going to be more easily matched than others
James_Scholes: [gives an example of such a case]
James_Scholes: I think you're right that the current assertions don't have any basis in the standards
James_Scholes: I think we should assert that it reads the role of region and the name and leave it at that
Matt_King: If our test is based on a principal that only applies in one specific case, then how does that help if you are testing a different same-page link?
James_Scholes: The role and the name should be relevant regardless
James_Scholes: I think those expectations hold across use-cases
Matt_King: It sounds like you're kind of deriving an algorithm
James_Scholes: Sure
Matt_King: I suggested that we could have a generic expectation or a specific expectation
Matt_King: A generic expectation would be an assertion along the lines of "the new location is conveyed". We have the user needs (they need to know that they activated the link and where the link took them to). If we had a generic assertion like that, and we left it up to every individual screen reader to decide how to convey that
Matt_King: Or we could have a specific assertion based on some kind of logic--that's what you're talking about James_Scholes. The only challenge there is that we need to come up with some logic that we can get all screen readers to agree to
James_Scholes: I don't think the logic I've proposed would be controversial
Matt_King: I'm not saying that it's controversial, but I'm concerned it may be an issue for folks that need to consider all the edge cases
James_Scholes: We're not testing all the edge cases, though
Matt_King: But we need to be prepared to write such tests for interoperability purposes
James_Scholes: I don't think it's appropriate for a screen reader to approach a project like ours and say, "because this test has been written in such a way that it may fail X% of tests, we don't think it's valid"
Matt_King: This project, as I've seen it, has been taking the logic that is expressly stated (generally speaking) in other specs--and that we're just pulling it together and trying to make it explicit. Things about how you respond to state change, focus change, etc...
Matt_King: Things we've done with, eg. radio, is all based on what's in the accessibility tree and why it's there
James_Scholes: so is what we're discussing right now
Matt_King: I agree
Matt_King: I would agree that it's pretty much impossible to cover all possible implementations. At a minimum, we're trying to cover all examples in APG and trying to be systematic about it
Matt_King: Though we have talked about writing separate tests which are more atomic
James_Scholes: I'm not sure why we would want to essentially dilute the tests based on one use case
Matt_King: Here, if the screen reader were to speak the name of the container and its role ("mythical university sample content") and spoke the heading overview...
James_Scholes: I think the heading overview is an aspect of user experience and shouldn't be asserted. (I think this even though I authored the tests.) The heading is incidental
Matt_King: We just wouldn't want anyone to call it "excessive verbosity"
James_Scholes: NVDA is quite verbose in ways that goes beyond the heading
James_Scholes: [demonstrates NVDA's behavior for this specific case]
Matt_King: That is a lot, and it's also similar to what JAWS does
James_Scholes: I think there's a big difference between "we incidentally spoke the heading" (I think that's a perfect user experience--just the name, the role, and the heading)
James_Scholes: Instead, it completely ignores my "say all" preferences (and the means by which I navigated there)
James_Scholes: I find that behavior quite irritating
James_Scholes: That's why I'm trying to distill it down into the minimum that would make people happy
Matt_King: So James_Scholes is clearly advocating for the "logic" approach; I think if we take that approach, it will be our responsibility to articulate that logic clearly
Matt_King: It's not quite like moving with the arrow keys because you're jumping
hadi: When you have a "skip to" a specific landmark, they provide different announcements than when you use the landmark navigation
Matt_King: I think James_Scholes is saying that it should be the same regardless
hadi: What is the difference?
James_Scholes: I'm not a JAWS expert, but when you move to a landmark with the R key, it just reads the name and role--not the content
James_Scholes: when you use the skip-to link, however, JAWS re-reads the page title, gives an overview of the page, and then starts reading the entire reading as though you were doing a "say all"
Joe_Humbert: The reason any screen reader may be doing that is that, generally, if it's done without any scripting, it involves a change in URL, so the screen reader receives a completely different event and handles that differently
Matt_King: Brett from Vispero tells me that he's addressed this in the next version of JAWS
James_Scholes: Anyway, there is a lot going on. If screen readers have the ability to detect that you clicked a link to move to a thing, they could choose to behave as if you moved to that thing using another navigation technique
Matt_King: I think the logic is actually pretty solid
Matt_King: This discussion helps me a lot, here!
hadi: I'm also thinking it should behave just as James_Scholes suggested. I'm going to think it over some more, though