Meeting minutes
Setup and Review Agenda
Jem: Next meeting is October 8 (we're going to be in TPAC next week and miss that meeting)
Jem: Has a conflict on October 1, so we'll cancel that one, too
Matt_King: Any requests for change to agenda?
Matt_King: Hearing none, we'll stick with the agenda as planned
Publication planning
Matt_King: Thanks to Adam_Page for completing the aria-actions page. That's our first experimental page
Matt_King: We're demonstrating an ARIA feature to the world that isn't even in ARIA, yet. We've clearly told the world that it isn't available in ARIA, of course. It's really only available via a sort of "back door"
Matt_King: That depends on the new infrastructure that howard-e and Stalgia built earlier this year
Matt_King: Four other things made it in to the milestone that we published last Thursday
Matt_King: ...but what are we going to do, next?
Matt_King: I'm proposing October 29 as our next target for publication. That gives us a little over a month to put things together
Matt_King: Any thoughts on that? Is it a no-go for anyone here?
howard-e: October 29 works for me
Matt_King: I hope we can land Jon's high-contrast pull request by then
Matt_King: There's an issue from last week that Adam_Page agreed to work on--the one related to tooltip and mouse behavior
Adam_Page: Absolutely. I consulted with Sarah on that to confirm my instincts, so I'm going to write a patch based on that understanding
Matt_King: Excellent
Matt_King: There are some really old pull requests that are related to ARIA 1.3 that I can refactor and bring in to "striking distance" for this publication
Matt_King: I'll look into that after TPAC
Matt_King: At this point, we have a lot of issues, but we don't necessarily have people committed to working on them
Matt_King: That's what will need to change to get stuff added to that milestone
Matt_King: We'll talk about some of the other candidate issues later in this meeting
Live regions practice
Matt_King: Another quick public service announcement
Matt_King: We're looking for people who are excited about helping the world understand how to use live regions effectively
Matt_King: If anybody on this call considers themselves this person, then I have a pull request for you!
Jem: What is the scope of this work?
Matt_King: We have to provide useful guidance
Jem: So is usability a concern?
Matt_King: We want people to understand the intent and purpose of the current live region attributes. We might also include information about what actually works. Though we generally refer people to ARIA-AT to understand what is supported and what is not
Jem: Should we have a "live region" project so that we understand the scope?
Matt_King: There's an issue associated with this pull request which should be used for that
Matt_King: w3c/
Matt_King: Also 1027 has some useful information w3c/
Jem: Should I create a project to organize this?
Matt_King: I don't think there is enough issues to warrant that
Jem: Got it
Adam_Page: Will any of this touch on aria-notify?
Matt_King: We can talk about this at TPAC, but I think there should be references where appropriate
Jem: How is aria-annotate related?
Matt_King: Annotations and notifications are two different things
ARIA 1.3
https://
Matt_King: This is another plea for help. There is a list of six issues in this milestone. Three are related to annotations (like Jem was just mentioning)
Matt_King: This is another area where we have to decide how we want the content structured and what we're going to present
Matt_King: At least for the annotations piece, we need a willing owner
Matt_King: This is another topic for TPAC, but I wanted to be sure that people here knew about it before we brought it up in that larger forum
Jem: We're going to eventually have examples for this, right?
Matt_King: We should before ARIA 1.3 becomes a recommendation
MDN Proposal - next steps
Lola: Ruth has gotten back to me. She read the proposal and the relevant GitHub issue
Lola: She said that the ideal way that W3C would share the content (via API) is unideal for MDN. They would prefer to manage the content however they want
Lola: Currently, any APIs they use currently is for data only--not for content. They're trying to avoid such dependencies for this rewrite
Matt_King: I don't know anything about MDN's governance process (who the people are who control it, etc), and that's a big gap in my understanding
Matt_King: But we could have some kind of joint ownership agreement between W3C and MDN (where the actual editors of the APG content are members of both the W3C Task Force and MDN)
Matt_King: We have an arrangement like that with WHATWG
Matt_King: That seems like a massive shift, though. I have no idea whether it's worth exploring
Lola: I can speak to the governance of MDN. Mozilla is the entity to speak to about changes. However, Open Web Docs are also involved as key contributors and managers of some content (e.g. the Browser Compat Data)
Lola: Something like what you've proposed may not be definitely out of the question
Lola: However, does joint ownership still meet the W3C's requirements even if the content is hosted remotely?
Matt_King: If MDN has very strong editorial opinions that are in conflict with the needs of serving the needs of the web accessibility initiative, then that would be a problem
Lola: I think I'd like to discuss this more at TPAC, particularly because I think Daniel's input will be valuable and because he's not present today
Matt_King: Yeah. I would hate to halt this investigation without even just one exploratory conversation
Lola: The content on MDN is open source, so anyone can realistically contribute. I've contributed tutorials to MDN, and I've been involved in the decision-making process about which documents get renewed. That conversation happens in Open Web Docs
Lola: They have mainly contributed to MDN, but there's nothing to stop them from wanting to contribute to APG or elsewhere
Matt_King: If there are some resources that we should read, then maybe put them in this issue
Matt_King: That could help us be more informed and understand what the options are
Matt_King: We've made a huge investment about building the APG within W3C, so if it were to move, that would be a big deal
Jem: I'm looking at the proposal, and I'm kind of shocked that "the APG Task Force would lose ownership of the APG"
Jem: That text is from the "concept 1" section of the document
Lola: If MDN is consuming some content through an API, that makes it difficult to maintain that content should they need to
Jem: That sounds more like a technical issue and less like a governance issue
Lola: A lot of this is coming up now because they are re-writing the whole platform. I don't know if this is actually being raised as a governance issue. It's more that, in thinking about the change to the platform, they are removing third-party dependencies. So they don't want to introduce a new dependency just as they are removing the existing ones
Matt_King: I would rather have an exploratory conversation before "killing" the idea
Jem: I just want to make sure everyone comes to the conversation with a collaborative spirit
Matt_King: Thank you very much, Lola!
github: w3c/
Where did our pattern-based GitHub projects go?
github: w3c/
Matt_King: We had about 40 projects in the "classic" projects. GitHub has two kinds of projects. The "modern" projects are a mixed bag
Matt_King: Two of the classic projects are showing up in the current list of projects
Matt_King: There's the "combo box patterns and examples development project"
Matt_King: That looks to me like an old "classic" project
Matt_King: Why would they take them away before they've migrated them? And aren't they breaking the URLs?
howard-e: Maybe this is in progress. I don't think I saw the "combobox" patterns yesterday
howard-e: I'm also wondering if the migration happened and it's hidden at the repository level, but that it may exist at the W3C organization level
Matt_King: Perhaps. But it's annoying that when you're in one of these new projects, it's hard to go to any of the associated repositories. There are no links
Matt_King: But then by default, these new projects are private, but the old ones were public
Matt_King: It will be a lot of work to go in and make all the projects public again
howard-e: It looks like the old URLs redirect to the new ones
howard-e: That's how the link for "tree grid" is behaving, for example
howard-e: I shared that on in my earlier comment on the GitHub issue, as well
howard-e: This may be something to check in with Daniel about
Matt_King: One thing that's really cool is this view of the new projects is actually more accessible. They have good headings--one for each column, and one for each card in each column. That makes it really easy to navigate
Matt_King: Maybe we just need to learn more about this migration. Maybe there will be no action required, but we have a lot of broken links right now
Matt_King: Maybe we just wait?
Matt_King: GitHub includes a link to "learn more" about this process
<Matt_King> learn more about the migration: https://
Matt_King: It looks like just two of our forty projects have been migrated. All the others are gone or hidden
Matt_King: It's hard to believe that the migration process would be this slow because it's so disruptive
Matt_King: But we should read the rest of their documentation about the migration
Matt_King: If, after reading it, we still have cause to suspect there is a problem, then we should report an issue to GitHub
Jem: How do we know this is related to the GitHub project migration?
Matt_King: Because if you try to visit a "classic" project, then GitHub displays a message about the migration. "Sunset notice: classic projects"
howard-e: It does for the very first time that you visit such a project, at least
Jem: Okay, your plan sounds good to me, Matt_King
Matt_King: Maybe this will go away in a couple days...