Meeting minutes
Setup and Review Agenda
https://
Matt_King: Any requests to change the agenda?
Matt_King: Hearing none, we'll stick with the agenda as planned
Matt_King: Next meeting: May 13
Publication planning
Matt_King: The publication status hasn't changed much since last week
Matt_King: We're still on-track to publish on May 29
Matt_King: We have review pending on color settings, and there are a few pull requests on today's agenda which are marked for the upcoming release, as well
Matt_King: It seems as though I have some record-keeping to do for this milestone
Matt_King: Any questions on the plans for the next publication?
Matt_King: Hearing none, we'll move on
PR 3249 - Add HTML search to landmark practice
github: w3c/
Matt_King: This is ready-to-merge except for this lint error
Matt_King: Adam looked into it and found that there is a known bug (and even a corresponding pull request) for the linter we use
Matt_King: If I merge it, though, then every single pull request will have lint errors
<jongund> eslint command: // eslint-disable-next-line <rule-name>
Matt_King: I'm wondering if we should include an "ignore rule" for this error in order to merge this patch
jugglinmike: I'm curious to see how tightly we can constrain this ignore rule
jugglinmike: If we can ignore this specific instance, then there's little risk
jugglinmike: But if we have to wholesale ignore every instance of invalid parent-child relationships, indiscriminately throughout the project, then I'd be wary of doing so. If we ignored in the problem in that way, we would be putting ourselves at-risk for regressions
[group reviews the APG repository's .vnurc file]
jugglinmike: This mechanism does appear to apply across the entire project. But because the directives include the complete error message to be ignored, I think the risk of ignoring future regressions is low (the directive will include the element name "search", and Matt_King has pointed out that the APG is unlikely to use the "search" element elsewhere)
Matt_King: Maybe we can experiment with this new "ignore rule" in the pull request that's blocked by the linting error
Matt_King: We should include a comment that has a link to the pull request for the linter which fixes the underlying problem
Matt_King: It should say that we made this change in order to merge pull request #3249. And then link to the known validator issue. That would let us find all the information we need in the future
jongund: Or we could make an issue in APG with all the relevant information and then point to that
Matt_King: Sounds good
jongund: I'll give it a try
Matt_King: Awesome. We'll re-assign this from Adam to you
Matt_King: Thank you for your help with this! Hopefully we can get this cleared up and then merge it
PR 3258 - Fix slider to remove redundant announcement of value by screen readers
github: w3c/
Matt_King: The link checker is failing
Matt_King: howard-e raised an issue that is related. I didn't add a link here, though
Matt_King: Can you take your changes out of your pull request, jongund?
jongund: Sure
Matt_King: I also wonder if howard-e's existing pull request will address this
jugglinmike: The error here is due to links with a different domain: tpgi.com
Matt_King: That's the same destination. The company changed addresses
Matt_King: howard-e's relevant patch is w3c/
jugglinmike: We can get this reviewed internally and get it merged as part of our maintenance work
Matt_King: Great!
Matt_King: If you do that, and jongund makes his change, then pull request 3258 will be almost ready to go
Matt_King: It's still pending reviews, though
Matt_King: Jem is listed as reviewer twice on this pull request!
Matt_King: That's strange
Matt_King: But I think it's fine that this patch only has one reviewer
jongund: I've updated the patch as you request
Matt_King: Awesome. Thank you, jongund
Matt_King: We're wait on a review of 3264 and then a review from Jem. If we don't hear from Jem next week, we'll touch base next week
PR 3251 - New expandable region pattern
github: w3c/
Matt_King: Adam added a comment about some linting problems
Matt_King: It says that there are related issues in the linter. "Allow paragraphs in group" and "false positive for a valid role=image"
Matt_King: I wonder if those are the two things that are failing here
Matt_King: It says "some checks not successful", but oh, there's five failing
Matt_King: The coverage report check is failing. I haven't seen that in a while. How does that happen?
Matt_King: index.html coverage... Is this index generation or coverage report generation?
jongund: Looks like someone tried to manually change the coverage report even though it's automatically generated
Matt_King: "13 files changed"... I honestly forget how we handle this in the build process. It's a little tricky
jongund: There must have been some manual changes to the coverage file...
jongund: He could just restore the original file from the "main" branch and see if it builds
Matt_King: We might want to take lessons learned from modifying the .vnurc file in the patch we considered earlier in this meeting
Matt_King: If the validator is this buggy, then it almost starts to seem like more trouble than it's worth! I'm mostly joking, though--the truth is, it catches a lot of potential errors
Issue 2835 - Restructuring landmark examples
github: w3c/
Matt_King: jongund has a pull request related to this, but I was imagining that we would take a very different approach to the solution
jongund: The approach that I was going to try (I don't know when I will have time) was to create an example page that had source code as its primary content
jongund: I don't know how that will interfere with the environment
Matt_King: Well, there are a couple of things that we could do instead of putting source code there
Matt_King: There are some parts of the example template that we could modify. We could take out the "source code" section, for example
Matt_King: I'm imagining that we put the source code example in (so it ends up becoming a bunch of named entities), but I liked before where we had these buttons that would highlight the landmarks on the page
Matt_King: I'm kind of wondering, though. If you look at any example page--e.g. the example for the accordion. On this page, the landmarks we have are "banner", "navigation", "main", "complimentary"...
Matt_King: We could show how the current page uses landmarks visually
jongund: I think we want code examples. I think it's important for people to know
Matt_King: We already have that code on the "practices" page, though
Matt_King: We could eliminate the "landmarks" examples entirely and just tell people to look at the practices page
jongund: I think the important information on the current "patterns" pages is, "what to screen readers do with this stuff?" and links to tools that allow people to analyze them
Matt_King: We can add a section to the "practices" pages for that
jongund: Just as long as we have something like this, so that at least people who have never used a screen reader can have an idea of what the user experience is like
Matt_King: I want to really trim down the external links
Matt_King: We might be able to solve this whole problem by just adding one or two sections to the current "practices" page. Content that's unique to what's currently in the examples subdirectly
Matt_King: We could leave the pattern page there in its current form, or we could remove it entirely
Matt_King: Maybe because this is so important, we should talk about the landmarks on the patterns page
jongund: I think that solves the problem for the APG. That's good--it's been an outlier for a long time.
jongund: But FYI, I would probably take what we have in the current "patterns" page and create a little website that's unaffiliated with the W3C
jongund: And maybe update the look and feel a little bit
jongund: We have enough problems maintaining the APG. I think it's a good idea
Matt_King: I want to make sure we are getting users information that they find helpful. I want the APG to be actionable and helpful. I think the current "practices" page provides a lot of helpful information; we can supplement it
Matt_King: For the ARIA-AT work, they will have to be standalone examples. That might be better, anyway
Matt_King: But that's a whole different topic
Matt_King: So yes, if you can move in that direction with your pull request (whether that means creating a brand new pull request or retrofitting your existing one), that would be great
Matt_King: Thank you for helping to make this a very productive meeting, jongund!