Meeting minutes
Setup and Review Agenda
https://
Matt_King: Any requests for change to agenda?
Matt_King: Hearing none, we'll stick with the agenda as planned
Matt_King: Next meeting: July 29
Publication planning
Matt_King: Congrats to everyone for getting the last big release out
Matt_King: Especially Adam_Page, with the new example
Jem: I'm still reviewing, but it looks great to me so far. howard-e did a great job
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
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
Matt_King: This time of year always depends a little bit on how much people are around and how much they can get done.
Matt_King: July and August can be a bit dry
Daniel: If we're targeting publication, now, I would prefer a date after the 18th of August
Matt_King: That should be no problem
Matt_King: I had been planning on getting something done before the end of August--before the US Labor Day holiday
Matt_King: This gives us several weeks to get work in shape
PR 3306: Rename Javascript to JavaScript
github: w3c/
Matt_King: We have a review of this--it's strictly editorial
Matt_King: The person who originally submitted this, howard-e reviewed and found some occurrences of the string which were not covered
howard-e: Yes, they were outside the content tree. They were in templates
Matt_King: We don't have a response from the person who originally created the pull request
Matt_King: I think that, because we don't have a publication date set, yet, we can wait a couple weeks
Matt_King: We can mention the person on this thread to bump their awareness
Matt_King: I think it's okay to let this sit
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
howard-e: That seems fine to me, as well. I can wait until the end of the week and ping the author again
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
Matt_King: So as soon as the source is updated (in the content/shared/template directory), then that will be good
Matt_King: And that's not a WAI template, that's our own template
howard-e: That's right
Jem: And eventually, are we going to move those templates into WAI?
Matt_King: No, because those templates are not design templates--they're content templates
Jem: Got it
PR 3309: Proposed changes to focus handling in editor menubar
github: w3c/
Matt_King: jongund was assigned to this, but he isn't present today
Matt_King: This is a set of three changes to the way that JavaScript is updating the tab index in the editor menubar
Matt_King: The first two are in response to mouse/pointer actions, and the third is in response to keyboard actions
Matt_King: I tested it from the perspective of a keyboard user, and I didn't see any changes in the behavior
Matt_King: I'm not clear whether change is expected here
Matt_King: And I wasn't able to test the mouse-related changes
arigilmore: I can try taking a look
Matt_King: That would be great, arigilmore--thank you!
Matt_King: This is all about when people are using both the mouse and the keyboard, is that right?
arigilmore: yes, when you use a mouse, clicking and hovering should change it. And also (from the keyboard) tab, enter, space, up, and down
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
Matt_King: This happens by accident quite often
arigilmore: Is there a related pull request?
Matt_King: We can probably find it if we search for pull requests related to "menu" and "hover"
arigilmore: maybe it's this one--
arigilmore: Oh, no, this one is from 2018. That's quite old
Matt_King: I think the one we're looking for was opened in the last year or so
Jem: I've assigned arigilmore to 3309
Issue 3293: Adding "Read This First" link to the top of each pattern page
github: w3c/
Matt_King: howard-e, you're working on this issue
howard-e: There's a pull request for this
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
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"
Matt_King: ...but there isn't anything there on those pages related to "read this first" content
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
howard-e: yes, that surprised me as well.
howard-e: The "read this first" banner has always been getting injected
howard-e: I'm wondering whether or not we should move that over to the "content" repository entirely
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
howard-e: Got it. I can re-purpose this PR with that in mind
Matt_King: So it will be a little longer before this is ready for review by other people
howard-e: I think I should be able to have this ready by the next meeting
Matt_King: Awesome, then we'll keep it on the agenda for next week
Issue 3308: Supporting "back" in modal dialogs on mobile devices
github: w3c/
Matt_King: This is related to the way modal dialogs are handled on mobile devices
lola: I can share a little context into what "close watcher" is--I'm currently implementing it in the Servo browser
lola: It's a mechanism to allow modal-type elements to respond to closing in a similar way as dialog
lola: It should be native within the browser--it's not something that the user has to install or the author has to install
lola: It's part of HTML. It inherits from EventTarget, so it behaves like an event
lola: There is a page for this on MDN, if folks want to read more in detail
<arigilmore> https://
https://
lola: This will respond to different mechanisms for closing, e.g. swiping, hitting "back", etc.
lola: You can specify which element to put the close watcher on
Matt_King: That's pretty cool!
Matt_King: This sounds like a good idea
lola: I don't know whether it's available across all browsers. I know that it's in Firefox (but not the main release)
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?
Jem: How does this help accessibility?
lola: I'm a bit confused about why this person opened the issue because I don't think this needs to be in APG.
Matt_King: The author is saying that it would make the standard "back" button in Android work. That doesn't work right now
Matt_King: ...and I think there's an accessibility argument to be made for that kind of support
Jem: I don't think this is about APG patterns. This is about usability improvements for the APG website... Right?
Matt_King: I think it's something we would include in specific examples, like the modal dialog example
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
lola: But it can be used on desktop, as well
Jem: So it enhances usability
Matt_King: In terms of where we would possibly utilize this in APG--
lola: If you have anywhere that you use dialog or popover
Matt_King: We're not using the "dialog" element, but we have multiple examples with the "dialog" role
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?
arigilmore: I think it makes sense to table this for now
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"
Issue 3307: Clarifying language about landmark region proliferation
github: w3c/
Matt_King: This is in the accordion example
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
Matt_King: Our explanation for this is "landmark proliferation"--that there would be too many landmarks on the page
Matt_King: The issue's author is asking what this would mean in practice
Matt_King: When I go to the "landmarks" practice, we actually don't talk about landmark proliferation anywhere on the practices page
Matt_King: There was a question here--what if there were twelve? Would you use landmark regions only for the first six?
Matt_King: We have three sections in our accordion
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
Matt_King: The first question is: should we be recommending the use of a region at all within the accordion?
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?
Matt_King: Nope
Siri: I think having a region is not needed. That is my opinion
Matt_King: Any other thoughts on this? Are people, in your pattern libraries--do you have accordions?
arigilmore: Yes, we have an accordion
Adam_Page: Yes, we have accordions, too, and we do not use regions in them
Matt_King: Do you use any grouping?
<arigilmore> carbon does not use regions either
Matt_King: In the example you just created, Adam_Page, we used "article". That was a container that separates one card from another
Matt_King: Since these always have headings, we don't necessarily need regions to delineate
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?
arigilmore: We just use "aria-controls" and "aria-expanded"
Adam_Page: Same for us; we don't use any kind of grouping mechanism
Matt_King: I think, because of the presence of the headings, I'm inclined to think that's adequate
Matt_King: If you have a heading structure, then whatever is after the accordion would presumably have a heading
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.
Siri: While we're on the topic of accordion--do you ever see accordions with actions beyond "expand" and "collapse", eg. "copy"?
Siri: I've seen that on marketing sites
Matt_King: That would be a good application of the new "disclosure card" pattern--the one that Adam_Page just completed
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