Meeting minutes
Setup and Review Agenda
https://
Matt_King: Any requests for change to agenda?
Matt_King: Hearing none, we'll keep the agenda as planned
Matt_King: No meeting June 24
Matt_King: Next meeting: July 1
Publication planning
Matt_King: We have four things that are ready to go
Matt_King: The other things that are in the works--at least one of them (the "expandable region" thing), I think is really close to ready (Adam is working really hard on it)
Matt_King: Rather than go through the work of multiple publication cycles... I'm thinking that since none of the "ready" items are high-priority, we can push out publication to right after the July 1st meeting. Perhaps July 2nd
Matt_King: I know howard-e is out until July 1
howard-e: That's right. I can help with a delayed release when I return
Matt_King: Okay, I'll make a change to the milestone.
PR 3251 - New example demonstrating expandable cards/regions
github: w3c/
Matt_King: This is the new "Expandable card"/"expandable region" pattern
Matt_King: Last week, we discussed how it is essentially the example (all the code) is complete (except for the tests). Code-complete and design-complete
Matt_King: jongund gave some feedback on the design and on the CSS
Matt_King: As far as design feedback goes, Adam's last comment... It looks like Adam updated the focus state
jongund: I just returned, so I will take a look at it
Matt_King: It also looks like there was something related to the way he wrote selectors. jongund provided some feedback, and he didn't see any examples that mimic the feedback that you were providing
jongund: The thing that threw me was using an event handler on the document and then filtering the events. In our other examples, we were using querySelectAll to find elements that match and applying events to those
jongund: For me, it's harder to understand why there is an event handler on the whole document
Matt_King: I think your feedback sounds logical. In terms of how it would be easier to understand what we're looking for and filtering here
jongund: Maybe that's the way people write event handlers, now
jugglinmike: There are some technical reasons to prefer Adam's approach in production settings, but they generally don't apply to the patterns as we implement them for APG
Matt_King: Is this distinction important? Is it worth while to be consistent here?
jugglinmike: I'm generally in favor of consistency always, personally, but I think this is a editorial question
Matt_King: As an editor, I think I should only ask for changes if we specifically call them out in our code guide for consistency reasons. Otherwise, we should let it slide
jugglinmike: That sounds fair to me
Matt_King: In this case, the "altitude" of the event listener (if we can say this) is not something we're going to be picky about
jongund: I'll look at this some more and try to give more feedback
howard-e: I can review the tests before I go out-of-office
Matt_King: And I'm still on the hook for editorial feedback
PR 3291 - Remove role of row from TR elements in treegrid example
github: w3c/
Matt_King: We have the role of "row" declared explicitly on the TR. It should be unnecessary, but we put it there because we have "pause" and "set" and "setsize", and the validator complained when "role" wasn't declared
Matt_King: Now, it says that "role=row" is missing. It seems like there is still a validator bug.
Matt_King: One thing we could do is that we could put new changes into the validator configurations to ignore this error
Matt_King: That's probably better because then, at least the example wouldn't be telling people, "hey, you shouldn't declare role=row on your TR elements"
Matt_King: Do we land this PR with additional changes to the validator? Or do we not land it until the validator is in a better state? Or is there a third option that I'm not considering?
jongund: We're also putting "role=gridcell" on the TD elements
Matt_King: That's a good call-out. That should be the default implicit row.
jongund: If we're taking out "role=row", I think we should also be taking out "role=gridcell"
Matt_King: I agree with that
bryan: For someone who's looking at the design pattern, how would they know what the purpose of "role=gridcell" is?
Matt_King: We do have a note in the pattern, I think. I know we do in the "table" pattern. We tell people that you don't have to put "cell" on the TD elements
bryan: I've seen people put "gridcell" on DIV elements and all sorts of other stuff
bryan: Where the div is inside a table
bryan: It screws everything up
Matt_King: I wonder if we put a note about this in the example
Matt_King: There's nothing about implicit semantics anywhere
Matt_King: If we added something about that, and if the validator isn't supporting the implicit semantics, then I don't know how well-aligned APG should be with the validator
Matt_King: If we put code out there, and say "this is the way to code it", and if that throws validation errors... I'm not sure what the best thing to do is in this case
jongund: I think we want to tell people how to code using the best practices we know. If the validator isn't supporting that... I don't think we should limit what we tell authors just because the W3C validator has a bug.
jongund: How widely used is the W3C validator used, anyway?
Matt_King: I have no idea
jongund: I'm guessing it's not widely used, just given the problems we've had with it
bryan: I do not use it
Matt_King: We don't use it at Meta
bryan: I've never heard of anyone using it in my practice
Matt_King: I hadn't originally thought that implicit semantics would be in the scope of this pull request
Matt_King: I'm leaning away from closing the pull request, at least for now, but it doesn't sound like something we're going to close quickly
Matt_King: Okay, that's very helpful!
Matt_King: I think the next step on this pull request, as jongund suggested, is to remove "gridcell", and then after that, to configure the validator accordingly
Matt_King: I'm going to look at what we did in "table". It's probably the case that we have some notes in different places. I'll try to sort that out. I think that would be the next step after the other steps. But it might be a separate issue and another pull request
Matt_King: We'll make a decision; we're not quite there, yet
Issue 3289 - Potential bug in select only combobox
github: w3c/
Matt_King: My goal is just to get someone assigned to look at this. I don't want to dig into the details in this meeting
Matt_King: Someone is pointing out that there is an "if" statement here that is essentially useless
Matt_King: Is there someone who can take a look and weigh in on whether they agree or disagree about the superfluousness of the code?
jongund: I can take a look
Matt_King: Okay, I assigned you, jongund. I'm not going to put the "bug" label, yet, because I'm not ready to say that it's a bug. I'm just going to add the "feedback" label.
Matt_King: We'll take a look at that when you are ready
Issues 3277 and 3294 - Treegrid focus order questions
Matt_King: These are both related to tree grid
Issue 3277: Rules for the Expand/Collapse button in the treegrid
github: w3c/
Matt_King: I think this is kind of a focus-order issue.
Matt_King: I didn't quite understand it. The reporter attached a video. I couldn't get the video to play, or if it does play, it's totally silent
Matt_King: Can anyone here get the video to play, and if so, could they share what it describes?
Matt_King: Maybe ChatGPT could explain it to me or bryan
bryan: I could give it a try...
jongund: I'm playing it, now. There is some audio, but it's very faint
jongund: He's describing and pointing at things. It's very hard to hear
lola: I can give it a shot
Matt_King: Okay, I can assign this issue to you, and we can discuss it next time
lola: I won't be present at our next meeting on July 1, but I can post my findings on the issue so that you can continue asynchronously
Matt_King: That sounds good!
Matt_King: I've assigned you, lola
Issue 3294: Keyboard implementation for the Tree grid Only cells can be focused is not proper
github: w3c/
Matt_King: I asked a clarifying question
Matt_King: What I think this issue is about is: on the treegrid example, we have three different ways of implementing keyboard navigation. This is something that we worked with Aaron Levinthal on a couple years ago. It's a situation where there's no obvious "best way" to do keyboard navigation, so we decided to illustrate multiple ways.
Matt_King: I think two of the approaches are reasonably well-tested, but this third approach (the one the reporter is referring to) may have bugs
Matt_King: I think it's about tab order, but I don't quite understand the language they're using
Matt_King: Sometimes when I use tab, I have the experience that the focus is traveling through every row in the tree grid (which is clearly not what's intended)
Matt_King: I don't know if that's what the reporter is describing, so I've added a comment requesting clarification
Matt_King: In this one, you cannot focus the row itself. In this one, the way you expand and collapse a branch is by having a cell with the "expand"/"collapse" functionality on the cell
Matt_King: This issue also has a video
Matt_King: lola, since you're looking at a similar issue, would you be willing to take a look?
lola: I can attempt to, but I will flag that my final working day is Thursday, so I don't know if I will be able to get to everything
Matt_King: We'll take it when you can do it--if that isn't until after you return, that's fine
lola: Okay
Matt_King: The way the screen readers are behaving, it's not always easy to figure out what its focus is. Sometimes, it seems as though JAWS may have even regressed!
jongund: I think the problem is that, when you're doing a "shift+tab", you're definitely getting row selection, but not when you go "tab" forward
Matt_King: It is a problem that forward-tabbing and backward-tabbing are not reversible
Matt_King: It might be a little bit of work just to document the problem. I want to make sure we fully understand the intent of the reporter
Issue 3293 - Add read this first to pattern pages?
github: w3c/
Matt_King: This was a request for a change to the APG, sort of an editorial change
Matt_King: It originated as a side-comment on another issue (there is a link included)
<jongund> I have to leave a little early
Matt_King: We have a prominent link to the "read this first" content at the top of the index pages, but not on the individual pattern pages
Matt_King: It was suggested that we may want to do that
Matt_King: I wish we had Isaac...
Matt_King: I don't know, from the structure of the pages, how reusable the design is for the disclosure which has the "read this first" link. Do people think this is a good idea? Should we put it at the top of every pattern? If so, where? Right after the "h1" heading?
howard-e: Yeah, I think it would fit stylistically. I don't see why not
howard-e: I'm not opposed to this idea
Matt_King: It is pretty short--it's just a heading and one line. It doesn't seem like it would really get in the way much
howard-e: On the "patterns" page, these is a graphic which may not be necessary on each "pattern" page
howard-e: The graphic feels more in place on the index page because of all the cards
lola: I think I agree with howard-e
Matt_King: I know that the "read this first" section is pulled in with an "include" directive or something... We'd want to do it in the same way. I think it would mean modifying all twenty-something "pattern" pages.
howard-e: Yes, I think so. Maybe also a small modification to the "read this first". I don't think there is anything that would have to happen in the "builder" repository
Matt_King: I would like to avoid any changes to the "builder" repository unless it was necessary
lola: The section we're talking about is just the "no ARIA is better than bad ARIA" bit, right?
Matt_King: We would include the link
Matt_King: Okay, I'm going to assign this to you, howard-e