17:06:22 <RRSAgent> RRSAgent has joined #aria-at
17:06:26 <RRSAgent> logging to https://www.w3.org/2025/05/21-aria-at-irc
17:06:26 <Zakim> RRSAgent, make logs Public
17:06:27 <Zakim> please title this meeting ("meeting: ..."), jugglinmike
17:06:36 <jugglinmike> present+ jugglinmike
17:06:40 <jugglinmike> scribe+ jugglinmike
17:06:48 <jugglinmike> scribe+ Isa
17:06:54 <jugglinmike> present+ Isa
17:07:01 <jugglinmike> present+ Matt_King
17:07:21 <jugglinmike> present+ louis
17:07:34 <jugglinmike> present+ mfairchild
17:07:38 <jugglinmike> present+ james
17:07:44 <jugglinmike> present+ ChrisCuellar
17:08:34 <jugglinmike> topic: Review agenda and next meeting dates
17:09:29 <jugglinmike> https://github.com/w3c/aria-at/wiki/May-21%2C-2025-Agenda
17:09:46 <jugglinmike> Matt_King: Any requests for changes to the agenda?
17:10:07 <jongund> jongund has joined #aria-at
17:10:19 <jugglinmike> ChrisCuellar: There's an issue about the bot's inconsistency being manually reproducible
17:10:34 <jugglinmike> Matt_King: We can see if we can fit it into the end, today
17:10:44 <jugglinmike> ChrisCuellar: Great. It's issue 1298
17:11:12 <jugglinmike> ChrisCuellar: https://github.com/w3c/aria-at-app/issues/1298
17:11:57 <jugglinmike> Matt_King: Next meeting: Thursday May 29
17:12:04 <jugglinmike> Matt_King: Next AT Driver Subgroup meeting: Monday June 9
17:12:23 <jugglinmike> Topic: Current status
17:12:35 <jugglinmike> Matt_King: We're still planning on accordion next. that's on today's agenda
17:12:54 <jugglinmike> 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
17:13:02 <jugglinmike> Matt_King: No really big changes
17:13:27 <jugglinmike> 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
17:13:37 <jugglinmike> Matt_King: So it's possible that we can have this resolved by the end of this month
17:13:52 <jugglinmike> Topic: Re-run of JAWS for color viewer slider
17:14:12 <jugglinmike> Matt_King: Isa was going to reach out to Hadi about this because it seemed like it could be a copy-paste error
17:14:33 <jugglinmike> Isa: No update on that topic, I haven't e-mailed Hadi, yet. I'll do that this week
17:14:54 <jugglinmike> Topic: PR 1245 - Accordion test plan
17:15:04 <jugglinmike> github: https://github.com/w3c/aria-at/pull/1245
17:15:16 <jugglinmike> Matt_King: We've run into some questions about what this test plan should actually require
17:15:57 <jugglinmike> 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
17:17:36 <jugglinmike> 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)?
17:18:06 <jugglinmike> Matt_King: It seems to me that, when I look at the must/should/may distinction, that the heading levels are definitely a "must"
17:18:48 <jugglinmike> 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
17:19:02 <jugglinmike> Matt_King: That's kind of what I'm asking: is it fundamentally broken?
17:19:12 <jugglinmike> Matt_King: On mobile, we've always had headings without levels
17:19:32 <jugglinmike> james: But there's no level attached in that case. In HTML, there is always a level
17:19:52 <jugglinmike> Matt_King: So can the user still use the pattern or benefit with the semantics if the information is not conveyed?
17:20:23 <jugglinmike> 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"
17:21:01 <jugglinmike> 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
17:21:45 <jugglinmike> 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)
17:22:02 <jugglinmike> mfairchild: I agree. I'm also unaware of any screen reader that doesn't convey heading levels on the web platform
17:22:36 <jugglinmike> 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
17:22:59 <jugglinmike> Matt_King: I'm raising the question because in other cases, some information like this (selection, pressed, size)...
17:23:11 <jugglinmike> mfairchild: But those are different circumstances
17:23:13 <jugglinmike> Matt_King: Agreed
17:23:41 <jugglinmike> Isa: It would be odd to encounter a heading without a level. Those things go together, like salt and pepper as it were
17:24:19 <jugglinmike> james: This is legitimately different from the toggle button case because without the information, you are prevented from using it fully
17:24:33 <jugglinmike> mfairchild: And you're not prevented from understanding the state
17:24:39 <jugglinmike> james: Exactly
17:25:01 <jugglinmike> Matt_King: Okay, it sounds like we have strong consensus that the heading level is going to be a "must" in all circumstances
17:25:17 <jugglinmike> Matt_King: So now, let's talk about assertions about the heading when you're tabbing to the button that's inside the heading
17:26:08 <jugglinmike> Matt_King: Test 1 is "navigate forwards into an expanded accordion header"
17:26:26 <jugglinmike> 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
17:26:55 <jugglinmike> 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
17:27:17 <jugglinmike> 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
17:27:33 <jugglinmike> Matt_King: But in some cases, screen readers have special-case code to give information about certain kinds of containers
17:27:52 <jugglinmike> Matt_King: It's probably pretty important that this button is contained in a heading, but there are lots of headings that contain buttons
17:28:12 <jugglinmike> 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?
17:28:21 <jugglinmike> Matt_King: We have to be careful about what we're asserting here
17:28:33 <jugglinmike> Matt_King: One option is that we don't put any assertions about the heading when you're tabbing in focus mode
17:28:53 <jugglinmike> Matt_King: Another option is that we have some assertions, but that they're "should"
17:29:04 <jugglinmike> James: I think it should be a "may" assertion
17:29:33 <jugglinmike> James: I don't think we want to say they they shouldn't do it. A "may" seems perfectly reasonable in that scenario
17:30:13 <jugglinmike> mfairchild: I have no strong feelings here.
17:30:25 <jugglinmike> Matt_King: I was surprised by the amount of variation when I was looking in to this
17:31:21 <jugglinmike> louis: "may" seems reasonable to me, too
17:31:34 <jugglinmike> Matt_King: Okay, that's when we're tabbing. I'm personally pretty aligned with that, too.
17:31:59 <jugglinmike> Matt_King: I think it would still be a "may" in browse mode or virtual cursor mode
17:32:12 <jugglinmike> Isa: Yeah, "may" for tabbing. I don't want to leave it out completely, though
17:33:56 <jugglinmike> jugglinmike: I know we use "may" assertions to make sure Testers don't label some speech excessive. Is that our motivation, here?
17:33:58 <jugglinmike> Matt_King: We use "may" to communicate to web authors that they'd better not expect that all screen readers will do this
17:34:51 <ChrisCuellar> ChrisCuellar has joined #aria-at
17:35:17 <jugglinmike> Matt_King: The test, "request information about expanded accordion header". When the focus gets set by the script, where does the focus go?
17:35:42 <jugglinmike> 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
17:36:06 <jugglinmike> 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
17:37:31 <jugglinmike> Matt_King: It does tell me about the heading in virtual cursor mode
17:38:07 <jugglinmike> Matt_King: I can only guess why JAWS is working that way. If I recall correctly, NVDA was doing something similar
17:38:17 <jugglinmike> james: NVDA does not report the heading in any mode with "insert+tab"
17:38:35 <jugglinmike> Matt_King: JAWS is generally very consistent: "insert+tab" says what "tab" would have said
17:39:00 <jugglinmike> 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
17:39:09 <jugglinmike> james: I don't think there should even be a "may" assertion
17:39:26 <jugglinmike> james: The focused element is not a heading. It's inside a heading
17:39:51 <jugglinmike> 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
17:40:36 <jugglinmike> 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
17:41:05 <jugglinmike> Isa: I may have found a bug in NVDA: it doesn't read the line
17:41:36 <jugglinmike> 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
17:42:09 <jugglinmike> 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
17:42:16 <jugglinmike> james: I'm fine with a "may" assertion
17:42:34 <jugglinmike> Matt_King: I'm kind of aligned with not asserting anything about the heading when you're requesting information about the focused element
17:42:42 <jugglinmike> Matt_King: However, we might want to rename the test... Probably not
17:42:50 <jugglinmike> Matt_King: I could go either way on that one
17:43:01 <jugglinmike> Isa: JAWS doesn't convey the heading for me. It only conveys the button and its state
17:43:20 <jugglinmike> Matt_King: The most important thing is for us to be consistent with other test plans and our expectations in those.
17:44:05 <jugglinmike> 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
17:44:12 <jugglinmike> James: Hah--have you used the web?
17:44:21 <jugglinmike> Matt_King: Well, compliant menus
17:44:36 <jugglinmike> James: The other day, we had an entire form inside of a button. Including the submit button
17:44:42 <jugglinmike> [much laughter, all around]
17:45:07 <jugglinmike> 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
17:45:25 <jugglinmike> Matt_King: And for the moving in and out of the heading, that's where you have "may" assertions for the heading
17:46:09 <jugglinmike> 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
17:47:14 <jugglinmike> 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
17:47:46 <jugglinmike> 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
17:48:00 <jugglinmike> Isa: In disclosure navigation, there is a different implementation of the region
17:48:09 <jugglinmike> Matt_King: In that case, the focus goes to the region
17:48:24 <jugglinmike> Isa: We're asserting name, required, etc. about the form field
17:48:48 <jugglinmike> 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"
17:48:54 <jugglinmike> James: Meaning "may" or "should"?
17:48:58 <jugglinmike> Matt_King: "May"
17:49:23 <jugglinmike> Isa: It's a very interesting situation because you can only get that information when tabbing (I think with all screen readers)
17:49:33 <jugglinmike> Matt_King: I think all the screen readers convey it when you arrow
17:49:44 <jugglinmike> Isa: Not all of them, they don't. I tested it last week
17:50:04 <jugglinmike> James: It does on NVDA. I'm testing now
17:50:38 <jugglinmike> 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
17:51:04 <jugglinmike> James: I find the information legitimately helpful and also easy to ignore
17:51:30 <jugglinmike> 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
17:51:37 <jugglinmike> James: So I could see this going either way
17:52:05 <jugglinmike> James: I'm not sure this should be a region. It seems like a job for a group
17:52:27 <jugglinmike> Matt_King: I can see arguments for "may" or "should,"
17:52:36 <jugglinmike> James: I'm coming down on "may" just to collect the data
17:52:43 <jugglinmike> Matt_King: I'm trying to be as neutral as possible
17:53:09 <jugglinmike> 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
17:53:27 <jugglinmike> James: If you're arrowing in browse mode, I think it should be a "must"
17:53:39 <jugglinmike> Matt_King: Maybe it's a "must" if you're arrowing but a "may" if you're jumping
17:53:50 <jugglinmike> mfairchild: Are we considering named groups to be a region?
17:53:52 <jugglinmike> James: No
17:54:14 <jugglinmike> James: The fact that it's a landmark region that is used for the accordion--that's what's causing us to question
17:54:35 <jugglinmike> Matt_King: So, a "must" for arrowing and a "may" for jumping? On the region, role, and name? Are we aligned there?
17:55:25 <jugglinmike> 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?
17:56:53 <jugglinmike> 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
17:57:50 <jugglinmike> Topic: Issue 1389 - Recording AT/Browser versions for runs started with bots
17:58:47 <jugglinmike> 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?
17:58:53 <jugglinmike> James: Sure
17:59:05 <jugglinmike> Matt_King: If we need actual conversation, then I guess that will have to wait until next week
17:59:18 <jugglinmike> jugglinmike: Sounds good, thanks!
17:59:32 <jugglinmike> Matt_King: Okay. We'll get to the other items next week
18:02:23 <jugglinmike> Zakim, end the meeting
18:02:23 <Zakim> As of this point the attendees have been jugglinmike, Isa, Matt_King, louis, mfairchild, james, ChrisCuellar
18:02:25 <Zakim> RRSAgent, please draft minutes
18:02:27 <RRSAgent> I have made the request to generate https://www.w3.org/2025/05/21-aria-at-minutes.html Zakim
18:02:34 <Zakim> I am happy to have been of service, jugglinmike; please remember to excuse RRSAgent.  Goodbye
18:02:34 <Zakim> Zakim has left #aria-at
18:02:43 <jugglinmike> RRSAgent, leave
18:02:43 <RRSAgent> I see no action items