Meeting minutes
Review agenda and next meeting dates
https://
Matt_King: Any requests for changes to the agenda?
ChrisCuellar: There's an issue about the bot's inconsistency being manually reproducible
Matt_King: We can see if we can fit it into the end, today
ChrisCuellar: Great. It's issue 1298
ChrisCuellar: w3c/
Matt_King: Next meeting: Thursday May 29
Matt_King: Next AT Driver Subgroup meeting: Monday June 9
Current status
Matt_King: We're still planning on accordion next. that's on today's agenda
Matt_King: Vispero has approved a couple more plans. Not all the ones I was expecting, but we'll have a meeting with them next week to go through some of that
Matt_King: No really big changes
Matt_King: We already said we want to push out the disclosure because we wanted to bring it to APG. That got raised in the APG Task Force meeting this week
Matt_King: So it's possible that we can have this resolved by the end of this month
Re-run of JAWS for color viewer slider
Matt_King: Isa was going to reach out to Hadi about this because it seemed like it could be a copy-paste error
Isa: No update on that topic, I haven't e-mailed Hadi, yet. I'll do that this week
PR 1245 - Accordion test plan
github: w3c/
Matt_King: We've run into some questions about what this test plan should actually require
Matt_King: Let's talk about what the questions are, but if somebody is going to follow along and participate in this discussion, they'll have to review the test plan
Matt_King: What should the assertion priorities be for heading level? For the heading semantics (when tabbing to the button)? For the region semantics (when tabbing into the input field)?
Matt_King: It seems to me that, when I look at the must/should/may distinction, that the heading levels are definitely a "must"
james: In HTML, there is no such thing as a heading with no level. If a screen reader was encountering a header and not speaking its level, it would be fundamentally broken
Matt_King: That's kind of what I'm asking: is it fundamentally broken?
Matt_King: On mobile, we've always had headings without levels
james: But there's no level attached in that case. In HTML, there is always a level
Matt_King: So can the user still use the pattern or benefit with the semantics if the information is not conveyed?
Matt_King: In other test plans, we have said for example "conveying the 'not pressed' state of the toggle button is completely optional--not necessary"
james: In the cases of position information and 'not pressed' state, there are specific tasks that you can point to that the user is still able to complete despite the absence of information
james: Whereas if a heading level is not conveyed, they can still understand that there is a heading, and they can still navigate to that heading, but they are missing let's say 50% of the information (though it's difficult to put a number on it)
mfairchild: I agree. I'm also unaware of any screen reader that doesn't convey heading levels on the web platform
Matt_King: When I did JAWS, NVDA, Narrator, and VoiceOver, I noticed that there were certain circumstances where the screen reader (I believe it was NVDA) did not convey the level of the heading
Matt_King: I'm raising the question because in other cases, some information like this (selection, pressed, size)...
mfairchild: But those are different circumstances
Matt_King: Agreed
Isa: It would be odd to encounter a heading without a level. Those things go together, like salt and pepper as it were
james: This is legitimately different from the toggle button case because without the information, you are prevented from using it fully
mfairchild: And you're not prevented from understanding the state
james: Exactly
Matt_King: Okay, it sounds like we have strong consensus that the heading level is going to be a "must" in all circumstances
Matt_King: So now, let's talk about assertions about the heading when you're tabbing to the button that's inside the heading
Matt_King: Test 1 is "navigate forwards into an expanded accordion header"
Matt_King: If you open the "test 1" page, you'll notice that the structure of this is a heading that contains a button as aria-expanded
Matt_King: ...and if you are tabbing, and you are in focus mode with NVDA or forms mode with JAWS, your focus is going to the button
Matt_King: So there is a legitimate question here. Quite often, when you tab to something, you get the information about the thing that gets focused--not about the thing that contains it
Matt_King: But in some cases, screen readers have special-case code to give information about certain kinds of containers
Matt_King: It's probably pretty important that this button is contained in a heading, but there are lots of headings that contain buttons
Matt_King: I don't know if all screen readers would agree that if you have a heading contained in the button, should you announce the heading?
Matt_King: We have to be careful about what we're asserting here
Matt_King: One option is that we don't put any assertions about the heading when you're tabbing in focus mode
Matt_King: Another option is that we have some assertions, but that they're "should"
James: I think it should be a "may" assertion
James: I don't think we want to say they they shouldn't do it. A "may" seems perfectly reasonable in that scenario
mfairchild: I have no strong feelings here.
Matt_King: I was surprised by the amount of variation when I was looking in to this
louis: "may" seems reasonable to me, too
Matt_King: Okay, that's when we're tabbing. I'm personally pretty aligned with that, too.
Matt_King: I think it would still be a "may" in browse mode or virtual cursor mode
Isa: Yeah, "may" for tabbing. I don't want to leave it out completely, though
jugglinmike: I know we use "may" assertions to make sure Testers don't label some speech excessive. Is that our motivation, here?
Matt_King: We use "may" to communicate to web authors that they'd better not expect that all screen readers will do this
Matt_King: The test, "request information about expanded accordion header". When the focus gets set by the script, where does the focus go?
Matt_King: It is just on the button, and JAWS only tells me about the button with "insert+tab". It doesn't say anything about the heading
Matt_King: I think that's kind of expected. I would guess that none of the screen readers would say anything about the heading in this situation
Matt_King: It does tell me about the heading in virtual cursor mode
Matt_King: I can only guess why JAWS is working that way. If I recall correctly, NVDA was doing something similar
james: NVDA does not report the heading in any mode with "insert+tab"
Matt_King: JAWS is generally very consistent: "insert+tab" says what "tab" would have said
Matt_King: It's not always true. Sometimes there may be transient information--like if you went into a main region--it wouldn't repeat that
james: I don't think there should even be a "may" assertion
james: The focused element is not a heading. It's inside a heading
james: We've raised with Vispero about how it might be helpful to repeat the context of a menu, but I don't see the advantage of it telling you that this button is inside a heading
james: In some cases, you have a heading with some text and a button (I wish you didn't, but we do). I think that when you ask for the focused element, you should get the focused element
Isa: I may have found a bug in NVDA: it doesn't read the line
Matt_King: But in this case, you're thinking that it's okay to insert a "may" for tabbing and shift-tabbing, but for "insert", you don't think it should have any assertion at all
Matt_King: Usually we don't call something excessively verbosity unless it interferes or is misleading. I guess we won't classify this information as excessive, here
james: I'm fine with a "may" assertion
Matt_King: I'm kind of aligned with not asserting anything about the heading when you're requesting information about the focused element
Matt_King: However, we might want to rename the test... Probably not
Matt_King: I could go either way on that one
Isa: JAWS doesn't convey the heading for me. It only conveys the button and its state
Matt_King: The most important thing is for us to be consistent with other test plans and our expectations in those.
Matt_King: Your menu item context example is a good parallel, but it's not perfect because in this case, there are a lot of cases where there is a button inside a heading and there is a lot of other stuff inside the heading. But it's never the case that a menu has things other than menu items within it
James: Hah--have you used the web?
Matt_King: Well, compliant menus
James: The other day, we had an entire form inside of a button. Including the submit button
[much laughter, all around]
Matt_King: I think we should write this test plan without those assertions. In the "request information" test, we should probably only assert stuff about the button
Matt_King: And for the moving in and out of the heading, that's where you have "may" assertions for the heading
James: To recap: when tabbing to the button, we're saying that the "heading" assertion should be a "may". And when we press "insert+tab", the assertions shouldn't be present. For all modes
Matt_King: Okay, so, the last question about accordion is about when you're tabbing out of the accordion heading and into the form input. There is a region around the input field, and we want to decide on the priority of the assertions about the region semantics
Matt_King: I think we have a little bit of precedent ofr this--in the "navigation menu bar" test plan.. But actually, no, that's different
Isa: In disclosure navigation, there is a different implementation of the region
Matt_King: In that case, the focus goes to the region
Isa: We're asserting name, required, etc. about the form field
Matt_King: When you're tabbing, this feels like another situation where I'm gonna say "it's optional to convey the information about how you entered a region"
James: Meaning "may" or "should"?
Matt_King: "May"
Isa: It's a very interesting situation because you can only get that information when tabbing (I think with all screen readers)
Matt_King: I think all the screen readers convey it when you arrow
Isa: Not all of them, they don't. I tested it last week
James: It does on NVDA. I'm testing now
James: I'm biased because NVDA does this behavior, and I prefer it. Whenever I use JAWS, and I'm moving through a web page and tabbing or using quick nav
James: I find the information legitimately helpful and also easy to ignore
James: That said, it does come up with clients that NVDA is very verbose when moving in and out of containers, and that limits what they can do with their DOM structure
James: So I could see this going either way
James: I'm not sure this should be a region. It seems like a job for a group
Matt_King: I can see arguments for "may" or "should,"
James: I'm coming down on "may" just to collect the data
Matt_King: I'm trying to be as neutral as possible
Matt_King: If you're using arrow keys, it seems like it should be a "should" because you are crossing right over the boundary. You should never ignore regions if you're arrowing
James: If you're arrowing in browse mode, I think it should be a "must"
Matt_King: Maybe it's a "must" if you're arrowing but a "may" if you're jumping
mfairchild: Are we considering named groups to be a region?
James: No
James: The fact that it's a landmark region that is used for the accordion--that's what's causing us to question
Matt_King: So, a "must" for arrowing and a "may" for jumping? On the region, role, and name? Are we aligned there?
James: It raises questions for me: if you're jumping around in browse mode, should there be a difference in the information we expect to be given to users whether they are using arrows or the "e" key?
Matt_King: These are decisions that we can revise. This is going to Draft Review. I just didn't want to introduce the test plan into Draft Review without considering them, first
Issue 1389 - Recording AT/Browser versions for runs started with bots
Matt_King: We're running short on time. Mike has written up a proposal as a response to your issue, James. Could you read it and respond there?
James: Sure
Matt_King: If we need actual conversation, then I guess that will have to wait until next week
jugglinmike: Sounds good, thanks!
Matt_King: Okay. We'll get to the other items next week