Meeting minutes
<Jem> https://
Setup and Review Agenda
Jem: Next meeting: September 3
Matt_King: Next week's meeting follows a holiday in the US; if this impacts our work, we can push publication back by a few days
jugglinmike: Any requests for change to agenda?
jugglinmike: Hearing none, we'll move on as planned
Publication planning
Matt_King: so far, I've merged two things: Ari's fix and one other fix
Matt_King: We also have the high-contrast page and the pull request related to KBD elements
Matt_King: I'm going to make one change to the KBD pull request (the change is related to the templates)
Matt_King: John_Gunderson isn't present today to talk about high-contrast
Matt_King: I'd also like to get the toolbar changes in to this milestone
MDN integration
github: w3c/
Lola: While I was at Bocoup, this idea had been floated around from Boaz and some other colleagues
Lola: It had been de-prioritized in Bocoup's larger work, but now that I am working independently, I have the bandwidth to focus on this work
Lola: Last week, I met with Ruth John (sp?), the senior manager at MDN
Lola: She's very excited about the potential of this integration
Lola: MDN is currently undergoing a re-write of the platform
Lola: It may not effect the front-end, but the back-end is certainly changing
Lola: The main question right now is where the content should live
Lola: The ideal scenario would be to have a CMS that both MDN and APG could consume
Lola: However, I think that would take a lot of time and effort
Lola: I think Ruth is thinking about having a copy of what's happening in APG
Lola: Or completely moving the patterns from APG and maintaining them in MDN
Lola: Another thing to consider is that the ARIA-AT data (the data that says, e.g. that the "alert" pattern is compatible for JAWS in Chrome) is hosted from an iframe
Lola: We would probably have to think about making that an API instead so that it can be more efficiently consumed by MDN. Similar to the BCD project
Lola: At the moment, there is no funding for this work, but I am looking for funding, now
Lola: I've also spoken to Open Web Docs--the other contributors and maintainers of MDN
Lola: They are all gung-ho and excited for this work, as well
Matt_King: I think we need to sit down and write some goals and vision
Lola: Agreed
Matt_King: I don't think it would be good (from the perspective of serving our mission) to move anything outside of aria-practices
Matt_King: If we have to make changes to the structure of our content to make it more consumable, that would work
Matt_King: I don't know if the right word here is to make it possible to "syndicate" the content, but conceptually, that's what I'm imagining
Matt_King: But again, that's where writing down the goals and the vision becomes very important because that shapes the conversation about solutions
Lola: It's possible that in the coming weeks, someone in Mozilla will join us here so they can give us context about the preferable solution
Lola: I have the sense that an API will fit in with their long-term vision for MDN
Matt_King: It would be amazing if, any time someone wanted to write about something in APG, they could just "suck in" specific examples to their content
Jem: I love working with MDN because that's the first place that developers usually go
Jem: I agree with Matt_King about the scope of this work. I'd much prefer to integrate/syndicate our work with MDN rather than relocate it
Lola: Matt_King, you had originally mentioned that you felt like this would take a number of years. Having heard a bit more, do you still feel that way?
Matt_King: Well, it depends on the approach we take. It sounds like you've already laid a fair amount of groundwork with a bunch of people
Matt_King: Moving the APG from a "TR" to its own website--the startup part of it--took a long time
Matt_King: We had to align many stakeholders with different goals
Matt_King: Addressing concerns related to the mission of the website, etc.
Matt_King: Part of it is due to the speed of the W3C and how many people are spread across many people all at once
Matt_King: I imagine that this could quite a bit quicker, especially if there was funding for someone to work on whatever coding needs to happen
<Jem> One thing to add is that there are more stakeholders other than MDN, APG and Meta. There are WAI, ARIA and other many stakeholders.
Matt_King: Grant-seeking and contracting generally takes time, though. I think this might be done in the span of six months to a year, though
Matt_King: I think the initial alignment on vision and getting things written down in a clear way will go a long way in helping us figure out what potential roadblocks might exist
Lola: Next week, I can bring a one-page document describing goals and stakeholders
Lola: I will send that document and this GitHub issue to Ruth
<Jem> john ruth
<Jem> Ruth John
Simple JSDoc PR for modal dialog
github: w3c/
Matt_King: We just need someone to volunteer to review
Adam_Page: I'll take it
Jem: Thank you! I'll assign you
Tabs with action buttons
github: w3c/
Adam_Page: We took a preliminary look last week. Since then, I made a few changes and pushed them up
Matt_King: In your comments, you mentioned some of the different options you considered
Adam_Page: Basically, I had two motives for creating three examples. One was to test my own JavaScript for robustness and handle different scenarios. But it's also because ARIA Actions is still somewhat pending. I thought multiple examples might help move that discussion along
Adam_Page: The first example is maybe the most complex. It's a tab set where the menu button is the referenced ARIA Action
Adam_Page: Though each tab has four actions that can be performed on it
Adam_Page: The menu button is inside the tab list. Then I have a "div" element with role "presentation" that collects the tab
Matt_King: Well, a "div" element is generic by default, so it doesn't need the "presentation" role
Adam_Page: Good point
Adam_Page: In the second example, instead of having a menu item with a popover, I just stuffed two proper buttons inside each tab
Adam_Page: For ARIA Actions, that's where I'm now referencing both of those buttons
Adam_Page: For the third example, there are no ARIA Actions at all. This is just a sort of "standard" tab set. I included this to ensure that my JavaScript changes didn't interfere with the most basic use-case
Matt_King: The way I was thinking we might want to present different use cases like this (e.g. multiple actions versus a single menu button approach), I was thinking we might want to do it on different APG examples
Matt_King: ...and think a little bit about what people tend to do in the wild the most
Matt_King: I was imagining in a tab list... it's hard to imagine that people are going to stuff a lot of buttons into each tab
Matt_King: People DO actually do that with trees sometimes
Matt_King: Isn't it more likely that you're going to have a single button in a tab?
Adam_Page: Probably, yes, and it will probably by a "close" button
Matt_King: It's also very common for people to put a button at the end of tab lists which pops open a list of tabs that couldn't fit
Matt_King: In that case, though, the actions wouldn't be associated with any individual tab but rather with the tab list itself
Matt_King: I was thinking for this multiple button one, we might want to try to do that on the "file viewer tree" (or whatever it is called). I'm kind of wondering what it might look like if you had an option for "Delete", "rename" and more--right in the file tree
Matt_King: Because that seems like how people want to use it in a tree--to be able to contextually expose Actions on each individual tree item
Adam_Page: I've been thinking about Gmail
Matt_King: Well, Gmail has implemented a tree grid
Matt_King: The one I was thinking about is in VSCode, where you have the trees of Git history, or the outline of your code
Matt_King: ...and they have a toolbar next to it (though I don't know how that works visually)
Adam_Page: I'm looking at some of VSCode's tree views right now. It looks like they're doing it with persistent toolbars, but there are a number of places where they use lists of things--I need to explore their interface some more
Adam_Page: There's certainly the context menu
Matt_King: The context menu is very similar to what you made here
Adam_Page: I would say so, except there is no explicit visual affordance to know that a context menu is available. Users just have to know that it's available and how to activate it
Matt_King: There's some more exploration to do here, just in terms of making decisions of what we put forward
Matt_King: I would love it it these examples are based on things that we know people do or things that we know people want to do, just so we're sure that we're solving real problems
Matt_King: So it kind of feels like we should stick with your first example
Matt_King: If we do that, then if we take this concept of "multiple actions per focusable element" (I'd also like to do that on something like the tab container)... I just don't know how this is going to work
Adam_Page: The "overflow" use case you mentioned earlier is interesting to me because the tab list is not traditionally a focusable element
Matt_King: We have a separate issue for that. I could bring it up and we could maybe address that issue as well
Matt_King: What you said about the way VSCode works, where only the active tab has a "close" button on it, do you think that might work for another example with the overflow, where we put a "close" button on each tab which would only be visible on focus...?
Adam_Page: I misspoke about that; the tab doesn't have to be active for the button to be visible
Matt_King: What do you think of, for this pull request, doing what you have in the first one?
Adam_Page: That sounds great. I think the second example could be adapted in the direction of what you're talking about. It could have just the "close" button, and we might extend it to demonstrate the "overflow" case
Adam_Page: That feels like it transcends ARIA Actions and starts to re-think what a tab-list could actually contain
Matt_King: I think ARIA Actions is supposed to handle this case, too
Bryan_Garaventa: If you're including the buttons inside the tab, what does that mean for the accessible name of the tab?
Adam_Page: Well, the parent-child relationship is only suggested visually in that case. In the actual structure of the document, the tab and buttons are siblings
Matt_King: This will be on the agenda at TPAC!
Matt_King: So we made a decision: Adam_Page is going with the first one and pulling out the other two. I'll share a link to the existing issue about the "overflow" scenario