18:07:56 RRSAgent has joined #aria-apg 18:08:00 logging to https://www.w3.org/2025/07/22-aria-apg-irc 18:08:00 RRSAgent, make logs Public 18:08:01 Meeting: ARIA Authoring Practices Task Force 18:08:05 present+ jugglinmike 18:08:11 scribe+ jugglinmike 18:08:17 present+ lola 18:08:20 present+ arigilmore 18:08:23 present+ howard-e 18:08:29 present+ Daniel 18:08:32 present+ Adam_Page 18:08:38 present+ Siri 18:08:49 present+ Jem 18:08:54 present+ Matt_King 18:09:52 Jem has joined #aria-apg 18:10:23 present+ Jemma 18:10:50 Topic: Setup and Review Agenda 18:10:54 https://github.com/w3c/aria-practices/wiki/July-22%2C-2025-Agenda 18:11:51 Matt_King: Any requests for change to agenda? 18:12:03 Matt_King: Hearing none, we'll stick with the agenda as planned 18:12:26 Matt_King: Next meeting: July 29 18:12:45 PRESENT+ 18:12:57 present+ 18:13:28 Topic: Publication planning 18:13:37 Matt_King: Congrats to everyone for getting the last big release out 18:13:44 Matt_King: Especially Adam_Page, with the new example 18:14:12 Jem: I'm still reviewing, but it looks great to me so far. howard-e did a great job 18:14:55 Matt_King: On the "pattern" page for the disclosure example, there's a label on the section that contains the examples, and it created a landmark region somehow. That's kind of nasty, and I'm not sure how it happened, but I plan to make a pull request to fix it 18:15:37 Matt_King: For the next publication, I created a generic milestone to start capturing things. Looking across the space of things in the works, I don't have a sense for how quickly we'll be able to push to get another batch ready 18:15:53 Matt_King: This time of year always depends a little bit on how much people are around and how much they can get done. 18:16:00 Matt_King: July and August can be a bit dry 18:16:21 Daniel: If we're targeting publication, now, I would prefer a date after the 18th of August 18:16:26 Matt_King: That should be no problem 18:16:41 Matt_King: I had been planning on getting something done before the end of August--before the US Labor Day holiday 18:16:49 Matt_King: This gives us several weeks to get work in shape 18:18:29 Topic: PR 3306: Rename Javascript to JavaScript 18:18:37 github: https://github.com/w3c/aria-practices/pull/3306 18:19:02 Matt_King: We have a review of this--it's strictly editorial 18:19:25 Matt_King: The person who originally submitted this, howard-e reviewed and found some occurrences of the string which were not covered 18:19:34 howard-e: Yes, they were outside the content tree. They were in templates 18:19:46 Matt_King: We don't have a response from the person who originally created the pull request 18:19:58 Matt_King: I think that, because we don't have a publication date set, yet, we can wait a couple weeks 18:20:10 Matt_King: We can mention the person on this thread to bump their awareness 18:20:17 Matt_King: I think it's okay to let this sit 18:20:37 Matt_King: If we don't get a response after that, we can merge it to a feature branch, push a few more changes, and then merge it 18:20:55 howard-e: That seems fine to me, as well. I can wait until the end of the week and ping the author again 18:24:02 howard-e: the coverage report is failing because the contributor only updated the target file that the template would update, but not the template itself 18:24:34 Matt_King: So as soon as the source is updated (in the content/shared/template directory), then that will be good 18:24:41 Matt_King: And that's not a WAI template, that's our own template 18:24:45 howard-e: That's right 18:25:03 Jem: And eventually, are we going to move those templates into WAI? 18:25:15 Matt_King: No, because those templates are not design templates--they're content templates 18:25:19 Jem: Got it 18:25:30 Topic: PR 3309: Proposed changes to focus handling in editor menubar 18:25:36 github: https://github.com/w3c/aria-practices/pull/3309 18:25:46 Matt_King: jongund was assigned to this, but he isn't present today 18:26:01 Matt_King: This is a set of three changes to the way that JavaScript is updating the tab index in the editor menubar 18:26:18 Matt_King: The first two are in response to mouse/pointer actions, and the third is in response to keyboard actions 18:26:39 Matt_King: I tested it from the perspective of a keyboard user, and I didn't see any changes in the behavior 18:26:59 Matt_King: I'm not clear whether change is expected here 18:27:08 Matt_King: And I wasn't able to test the mouse-related changes 18:27:14 arigilmore: I can try taking a look 18:27:20 Matt_King: That would be great, arigilmore--thank you! 18:27:46 Matt_King: This is all about when people are using both the mouse and the keyboard, is that right? 18:28:14 arigilmore: yes, when you use a mouse, clicking and hovering should change it. And also (from the keyboard) tab, enter, space, up, and down 18:29:46 Matt_King: I want to make sure we don't regress specific existing behavior: if you have your mouse in an area where a sub-menu would appear (if you opened it)--so it's in an empty space--and then you use the keyboard to open the menu. If the mouse happens to be sitting on the place where the submenu item would appear, then the underlying submenu item gets expanded automatically 18:30:00 Matt_King: This happens by accident quite often 18:30:44 arigilmore: Is there a related pull request? 18:30:58 Matt_King: We can probably find it if we search for pull requests related to "menu" and "hover" 18:31:32 arigilmore: maybe it's this one-- 18:31:59 arigilmore: Oh, no, this one is from 2018. That's quite old 18:32:10 Matt_King: I think the one we're looking for was opened in the last year or so 18:34:43 Jem: I've assigned arigilmore to 3309 18:35:03 Topic: Issue 3293: Adding "Read This First" link to the top of each pattern page 18:35:11 github: https://github.com/w3c/aria-practices/issues/3293 18:35:22 Matt_King: howard-e, you're working on this issue 18:35:35 howard-e: There's a pull request for this 18:35:56 Matt_King: The part of this that became confusing to me is that it seems like we have some of the content being controlled from the build repository 18:36:20 Matt_King: When I review "practices.html" and "patterns.html", at least in the screen reader reading order, the very first thing after the "h1" is the "read this first section" 18:36:35 Matt_King: ...but there isn't anything there on those pages related to "read this first" content 18:37:01 Matt_King: So if I preview those pages that have "read this first" from the content repository--if I preview them locally, that content doesn't show up. "read this first" isn't there 18:37:08 howard-e: yes, that surprised me as well. 18:37:21 howard-e: The "read this first" banner has always been getting injected 18:37:40 howard-e: I'm wondering whether or not we should move that over to the "content" repository entirely 18:38:06 Matt_King: I think that's a good thing--especially if we're ever to move to another build system--to make sure the content is fully controlled from the content repository 18:38:33 howard-e: Got it. I can re-purpose this PR with that in mind 18:38:56 Matt_King: So it will be a little longer before this is ready for review by other people 18:39:05 howard-e: I think I should be able to have this ready by the next meeting 18:39:17 Matt_King: Awesome, then we'll keep it on the agenda for next week 18:40:39 Topic: Issue 3308: Supporting "back" in modal dialogs on mobile devices 18:40:47 github: https://github.com/w3c/aria-practices/issues/3308 18:41:15 Matt_King: This is related to the way modal dialogs are handled on mobile devices 18:41:39 lola: I can share a little context into what "close watcher" is--I'm currently implementing it in the Servo browser 18:42:09 lola: It's a mechanism to allow modal-type elements to respond to closing in a similar way as dialog 18:42:52 lola: It should be native within the browser--it's not something that the user has to install or the author has to install 18:43:11 lola: It's part of HTML. It inherits from EventTarget, so it behaves like an event 18:43:31 lola: There is a page for this on MDN, if folks want to read more in detail 18:43:55 https://developer.mozilla.org/en-US/docs/Web/API/CloseWatcher 18:44:10 https://developer.mozilla.org/en-US/docs/Web/API/CloseWatcher 18:44:39 lola: This will respond to different mechanisms for closing, e.g. swiping, hitting "back", etc. 18:44:49 lola: You can specify which element to put the close watcher on 18:44:54 Matt_King: That's pretty cool! 18:45:11 Matt_King: This sounds like a good idea 18:45:36 lola: I don't know whether it's available across all browsers. I know that it's in Firefox (but not the main release) 18:46:01 Matt_King: So you need a fallback. That sounds complicated because how would you know that closewatcher is doing what it's supposed to do? 18:46:08 Jem: How does this help accessibility? 18:46:26 lola: I'm a bit confused about why this person opened the issue because I don't think this needs to be in APG. 18:46:46 Matt_King: The author is saying that it would make the standard "back" button in Android work. That doesn't work right now 18:47:06 Matt_King: ...and I think there's an accessibility argument to be made for that kind of support 18:47:27 Jem: I don't think this is about APG patterns. This is about usability improvements for the APG website... Right? 18:47:41 Matt_King: I think it's something we would include in specific examples, like the modal dialog example 18:48:18 lola: The interface is not limited to mobile, but it's useful in mobile because on mobile, you have more options for how you can close something 18:48:29 lola: But it can be used on desktop, as well 18:48:34 Jem: So it enhances usability 18:48:45 Matt_King: In terms of where we would possibly utilize this in APG-- 18:48:55 lola: If you have anywhere that you use dialog or popover 18:49:10 Matt_King: We're not using the "dialog" element, but we have multiple examples with the "dialog" role 18:49:30 Matt_King: It sounds like a potentially good thing, but I guess the complicated part is: if it's not supported, then how do you fall back in a reliable way? 18:50:23 arigilmore: I think it makes sense to table this for now 18:51:14 Matt_King: In practice, I think this means that we will not add "assignee", and for a label, we will use "P3", "enhancement", and "example page" 18:51:34 Topic: Issue 3307: Clarifying language about landmark region proliferation 18:51:41 github: https://github.com/w3c/aria-practices/issues/3307 18:51:46 Matt_King: This is in the accordion example 18:52:11 Matt_King: We have some guidance there which states that you should avoid using landmark regions for the accordion panel if there could be more than six panels open at the same time 18:52:29 Matt_King: Our explanation for this is "landmark proliferation"--that there would be too many landmarks on the page 18:52:40 Matt_King: The issue's author is asking what this would mean in practice 18:53:03 Matt_King: When I go to the "landmarks" practice, we actually don't talk about landmark proliferation anywhere on the practices page 18:53:34 Matt_King: There was a question here--what if there were twelve? Would you use landmark regions only for the first six? 18:53:56 Matt_King: We have three sections in our accordion 18:54:25 Matt_King: When it was first developed, only one region could be opened at the same time. We've since changed that so any number can now be opened 18:54:39 Matt_King: The first question is: should we be recommending the use of a region at all within the accordion? 18:54:59 Siri: I think if you're marking the according as a button and there is a heading, is there really a requirement to use a region? 18:55:05 Matt_King: Nope 18:55:18 Siri: I think having a region is not needed. That is my opinion 18:55:39 Matt_King: Any other thoughts on this? Are people, in your pattern libraries--do you have accordions? 18:55:47 arigilmore: Yes, we have an accordion 18:55:57 Adam_Page: Yes, we have accordions, too, and we do not use regions in them 18:56:12 Matt_King: Do you use any grouping? 18:56:36 carbon does not use regions either 18:56:38 Matt_King: In the example you just created, Adam_Page, we used "article". That was a container that separates one card from another 18:56:57 Matt_King: Since these always have headings, we don't necessarily need regions to delineate 18:57:41 Matt_King: Do you use articles or groups or anything to denote the expandable part--the part that's controlled by the button? Or does your button just point to a "div" element that expands or collapses? 18:58:01 arigilmore: We just use "aria-controls" and "aria-expanded" 18:58:12 Adam_Page: Same for us; we don't use any kind of grouping mechanism 18:58:32 Matt_King: I think, because of the presence of the headings, I'm inclined to think that's adequate 18:58:48 Matt_King: If you have a heading structure, then whatever is after the accordion would presumably have a heading 18:59:17 Matt_King: In our case, if we have level-3 headings in the accordion, then when the very last section is collapsed, one would expect that the next heading after the according is a level-2 heading. 18:59:50 Siri: While we're on the topic of accordion--do you ever see accordions with actions beyond "expand" and "collapse", eg. "copy"? 18:59:56 Siri: I've seen that on marketing sites 19:00:11 Matt_King: That would be a good application of the new "disclosure card" pattern--the one that Adam_Page just completed 19:01:12 Matt_King: We're out of time for the day, but the next step here is to decide whether we want to get rid of the regions 19:10:13 Zakim, end the meeting 19:10:13 As of this point the attendees have been jugglinmike, lola, arigilmore, howard-e, Daniel, Adam_Page, Siri, Jem, Matt_King, Jemma 19:10:16 RRSAgent, please draft minutes v2 19:10:17 I have made the request to generate https://www.w3.org/2025/07/22-aria-apg-minutes.html Zakim 19:10:24 I am happy to have been of service, jugglinmike; please remember to excuse RRSAgent. Goodbye 19:10:24 Zakim has left #aria-apg 19:11:11 RRSAgent, leave 19:11:11 I see no action items