Meeting minutes
Setup and Review Agenda
Matt_King: Any requests for changes to the agenda?
Jem_: Looks good to me!
Matt_King: Next meeting will be two weeks from today, July 22
Publication planning
Matt_King: On the 25th of June, we got our last publication out. That's marked "completed"
Matt_King: I've verified that everything included in that publication is indeed live and appears good (at least, to a non-visual user)
Matt_King: We ended up landing five pull requests. That's a really good and substantial update
Matt_King: Thanks to all who made that happen and to Daniel and Remi for making that happen
Daniel: Just to clarify: simply merging the pull request does not mean it is published. The WAI repository has a number of submodules, and we have a script that manages them. That is a deliberately-manual step that we perform to actually perform the publication
Matt_King: Does the person who merges also trigger the publication?
Daniel: Yes, generally, remi merges and publishes. In this latest publication, there was a delay because remi had another responsibility to attend to between those steps
Matt_King: I'll keep that in mind for the future.
Matt_King: Should I use the event of merging as the indicator that it is time to check the live site?
Daniel: Yes, for now. I'll discuss this with Remi because we used to post a comment after the merge once the publication had occurred
Daniel: For now, it's probably enough to simply wait 30 minutes after the merge to check the production site
Matt_King: Moving forward, a comment would be helpful
Daniel: That's fair
Matt_King: I tentatively set August 27th as a target date for the next publication
Matt_King: The milestone currently includes a total of three pull requests
Matt_King: Does that seem like a good date?
Daniel: I'll be around. I'll see if Remi will be around, as well
PR 3451: Another link checker fix
github: w3c/
Matt_King: This is a bit beyond my expertise
Matt_King: I've contacted howard-e about potentially taking a look
Matt_King: I did notice that one of the things this pull request does is remove the npm package named "node-fetch". I don't know why we were using it in the first place
Matt_King: I'm looking for people who can review this pull request and who have at least some relevant experience from an engineering standpoint
Jem_: I'm a bit rusty in that sense. The issue isn't just about node-fetch, is it?
Matt_King: No, that's just one thing that I am curious about
Jem_: I wonder whether we have a better way to check the link. Its purpose is to find a broken link
jugglinmike: I'm not familiar with this code, so I can't comment immediately. I'm not sure I have the bandwidth to review this week, either
Jem_: Well, the patch looks good to me.
Daniel: We had an issue with the UA strings we were using. That was apparently only one of the issues because the link checker is still failing.
Daniel: I asked Denis to take a look at the remaining issue, and this pull request is what they came up with
Daniel: I don't have enough expertise to determine the relevance of the removal of the "node-fetch" package, but I trust Denis' decisions on this
Matt_King: I have no particular reason to question. I'd just like to understand
Matt_King: If howard-e didn't write this code, then he definitely at least contributed to it
Jem_: Perhaps spectranaut could own this. I believe she created the workflow
Matt_King: The link checker was written long after spectranaut's contributions
Daniel: We had some errors with HTTP code 403. Initially that was because we were using an old user-agent string (for an old version of Chrome), but there were further failures
Daniel: It's those further failures that Denis is tackling with this pull request
Matt_King: One way to test this might be to merge these changes into some of the other pull requests that are out there, like pull request #2991
Daniel: The problem with this is that we should go back to those pull requests and remove this if we merge this to the main branch
Matt_King: I can make a separate throwaway branch that combines the other pull request and this one, just for testing purposes
Matt_King: Maybe we can let this sit for a little while. We might be able to get howard-e or CurtBellow to review
Matt_King: Could JoeLamyman take a look?
JoeLamyman: I'm not familiar with the Node.js code, so unfortunately, I don't think I'd be of much there. I can assist in functional testing on the test branches that Matt_King suggested created
Matt_King: Great!
Jem_: The code changes look hygienic enough to me, for what it's worth
PR 3416: Add MCP server
github: w3c/
Daniel: We discussed this internally. It's not clear to us what value this could add given that our HTML already has good structure and semantics
Daniel: It would be another layer that we would have to support, and everyone has limited resources
Jem_: I like this idea. Why don't we ask the pull request author to give more detail?
Daniel: We're not sure what the value is. It seems as though you could point your LLM at the APG directly
Daniel: If there is value in this, I would like to know how it would be different than using the APG site as context rather than this MCP server
Jem_: I think it's about creating a Cursor skill
Matt_King: I get that part, but the architecture of the solution--I don't know what the precedent is, but it's not like you go to various resources on the web... As far as I know, most models build context from resources without special files
Matt_King: I don't know what Jekyll would do with this stuff or how anyone would ever access it. What will the web server do with the content? How does an AI agent discover it?
Jem_: Can you assign this ticket to me so that I can do some additional research?
Matt_King: Sure. That's what Daniel and his team has been doing. If you think there is value in this and that the APG is the right place to put it--should w3.org have this kind of resource sprinkled throughout it?
Matt_King: I don't know enough about how you build MCP servers to know that this is the right place for the resource
Jem_: I may be naive, but a SKILLS.md for APG could be used in many places. If that's right, then maybe people who are using LLMs like Claude could use it to build more accessible user-interfaces
Matt_King: I thought you need server infrastructure to support that, but I'm not sure w3.org has that infrastructure
Jem_: I think it could be worth considering. I'd like to do some research and report back
Daniel: Maybe it's better to open a separate issue to discuss this with the WAI team, including Remi. We're currently skeptical about this
Jem_: I understand that. I just want to research a bit further
Matt_King: That goal is good and laudable, but implementable is a different topic
siri4: We have similar tools like JetStream... Even if a skill is there, it may not be added to the AI. You have to manually say, "add this skill to my AI". If the skill isn't present, then it will go and search outside itself
siri4: Adding the skill means that you don't have to tell the LLM explicitly
Matt_King: Which means you need some way of surfacing the skill and making it available. I don't see the infrastructure in this pull request that would surface it and make it useful. That's the part I don't understand because I haven't done any work installing specific skills into an agent
Jem_: I'm interested in looking into this idea
PR 3449: Three Combobox Examples: Expand on click and improve filter behavior
github: w3c/
Matt_King: Basically, this is a call for reviewers
Matt_King: This is a first-time contributor and someone who wants to make a valuable improvement to our combo-boxes
Matt_King: We don't have enough people looking at this, yet
Matt_King: It looks like Copilot has done a bunch of commenting on this pull request. I don't know how that got kicked off, and I don't know if the comments are good or bad, but they're there
Jem_: Did we enable Copilot in the repository? Or was it automatic?
jugglinmike: The comment history includes an entry which reads, "Copilot AI review requested due to automatic review settings 3 weeks ago"
jugglinmike: It sounds like it's possible for us to prevent this behavior if that's what we want
Matt_King: I'm not necessarily suggesting that, but we should have a human review the Copilot-generated comments to determine whether they are useful
Jem_: Matt_King, your middle name is "Combo-box", not mine
Matt_King: My main question for this meeting is, is there anyone here who is available for review?
JoeLamyman: I'm available to review it
Jem_: Thank you, JoeLamyman!
Matt_King: Thanks, JoeLamyman. I've added you
Matt_King: There is a lot of detail in inssue 3442
JoeLamyman: I'll make sure to check that context before conducting my review
PR 2991: Add Practice Page for Supporting Color Contrast Settings
github: w3c/
Matt_King: This is our color-settings practice
Matt_King: JoeLamyman reviewed it. Thank you, JoeLamyman
Matt_King: JoeLamyman reviewed it twice, actually. JoeLamyman initially gave jongund some substantial advice, and jongund incorporated that advice. I think that significantly improved the patch, so thank you JoeLamyman
Matt_King: I have some comments, but I have not put them in writing, yet
Matt_King: My first question is related to a question that is actually in the content. I am search for the string "**". Point number 4, under the heading "support color scheme"
Matt_King: This guidance--item number 4--is to use CSS filters on images to make them easier to view in color schemes
Matt_King: He's asking, is this something that we want to tell people to do?
Matt_King: I have zero expertise on this, but I'm hoping people in this room can weigh in on whether we keep, add, or remove the item
JoeLamyman: When I performed my initial review, I commented on some of the content on CSS filters. I don't think there's a way to do this in a way that is consistently usable, without making the images difficult to perceive
JoeLamyman: In the interest of consistency, I suggested that it was best not to use filters and for users to adjust their screen brightness.
JoeLamyman: Jongund agreed with me and decided to remove the text
Jem_: I support that suggestion, JoeLamyman
Matt_King: It sounds like Jongund agreed with you, but maybe what he did here was to leave it as-is and throw it to review for the larger group
Matt_King: I'm fine to step in and remove it. We really should have strong confidence before recommending anything. There's enough doubt in this meeting for me to want to remove it
Matt_King: Next up, under "increased contrast example", there is a table with seven columns, but there are a bunch of merged cells
Matt_King: One set of columns for text and one for buttons
Matt_King: The part that's really confusing for me is that in the second row, the color columns are BG are text
Matt_King: I'm concerned about "BG". I don't think that's universally understood as "background". "CCR" is "Creedence Clearwater Revival", so I'm uncertain about that, too
Matt_King: I assume that jongund's motivation has to do with the challenges of cramming in seven columns
Jem_: On the row you are mentioning, there is a th... I don't know why he used an acronym
Matt_King: I'm going to make some changes and bring them back to the group and ask you to review the tables to see if I messed them up in any way.
Matt_King: I think this page has really come a long way, and I'm excited to get it out there in our next publication
Jem_: I think it's a good idea to revise this table. I don't see why we need the acronyms
Matt_King: I want to combine the first row, where it says "text" and "button"
Matt_King: It's pretty much the same kind of idea in the next example table, as well, so I'll do the same kind of thing there, too
Matt_King: My next question is in the "SVG graphics" section. It's an editorial question about the first paragraph
Matt_King: If you read the entire section, you understand why this section is here. But when you first start reading it, the purpose is unclear
Matt_King: It seems like there should be an introductory paragraph or sentence that states what is the point of this whole SVG thing
Matt_King: I think the point is that SVGs have advantages over other forms of images
Matt_King: Bitmap isn't a very generic term? Doesn't that refer to a specific format
Matt_King: Is there are more generic term?
Jem_: "Non-SVG" ?
jugglinmike: "raster-based image" ?
Matt_King: Do we just say, "SVGs have advantages over raster-based images?" and then list the specific advantages?
Jem_: Yes. It's good to let readers know what are the advantages of SVGs. Jongund is saying that with the table, but what is the advantages of SVG versus raster-based images in terms of color contrast?
Jem_: You can change SVG color using media queries
Matt_King: It's saying that if you user current-color, you don't have to use media queries
Matt_King: Maybe it's that SVGs can automatically change their colors? Or perhaps more than their colors
Matt_King: Or perhaps we could state that "they can automatically adapt to user preferences based on the other settings that are described earlier in this article"
Jem_: So we start with the benefits of SVG and then go into the media query explanation
Matt_King: It also mentions smooth scaling...
Jem_: I don't think that's relevant here.
Matt_King: Smooth scaling is relevant to accessibility. When you zoom in, if you have a button (or toggle or switch) drawn with SVG, it automatically zooms and scales
Jem_: Right, but here we are talking about color contrast
Matt_King: Sure, but if we are making a list of advantages of SVG, we could include that as the final item in the list
Jem_: Will you make a new pull request?
Matt_King: I'll probably just edit it directly in this pull request
Matt_King: Unless anyone else would like to participate
Matt_King: If there's no one else available when I do these other things, then I'll make an attempt