Meeting minutes
<Jem> https://
Setup and Review Agenda
Jem: Next meeting: March 5
Jem: Any requests for change to agenda?
Jem: Hearing none, we'll move on
Publication status
Matt_King: The latest skipto with all the parameters in place (so that no more customization is necessary for APG)--that's all deployed
Matt_King: It might be a good idea for some people to peruse the production website today and look at these things to make sure there are no problems with skipto anywhere
Matt_King: It should be the same everywhere, but if there are any idosynchratic problems, we'd like to learn about them
<Jem> https://
Matt_King: Also, the coverage report is going to be generated automatically in response to changes to each page
Matt_King: You'll find the report under the heading titled "Coverage and Quality" on each page
Matt_King: We also had one change to the "sortable tables" example; it's a pretty minor change to the CSS
Matt_King: That's what we got done this month
Matt_King: We don't have another publication date set, yet, but we'll choose one as soon as we have a few substantial things to go--hopefully by the end of March
Matt_King: The site is getting better all the time, particularly when it comes to learning about the status of each page
<Jem> https://
Update on triage process definition
github: w3c/
Matt_King: I spent a fair amount of time on this, but I haven't yet addressed everything we dicussed last week. I'm getting close, though
Matt_King: I started working a little more on our labels
Matt_King: I added a label named "ready to prioritize", and I also added labels, "p1", "p2", and "p3"
Matt_King: If something is "ready to prioritize", that means it has completed the "intake" step, and if it's a bug, it has also completed the "bug reproduction documentation" step in the triage process
Matt_King: Once something is prioritized, we would replace the "ready to prioritize" label with either "p1", "p2", or "p3"
Matt_King: I'm still updating the documentation to reflect this
Matt_King: Then it will be ready to go, I think
Matt_King: I need to add labels for issue severity.
Matt_King: I think this will all be done by next week
Jem: Thank you for all the work you've put into the triage process!
Jem: What would be the timeline to start working on triage itself?
Matt_King: I think I'd like try some of it in this meeting today. That will help use ensure that we're all aligned on which issue labels we need
Matt_King: Otherwise, I'll leave it up to you to decide how you want to set up a schedule and how you want to document that schedule
Matt_King: I think it would be possible for you to kick it off next week
Jem: Okay, so who wants to contribute to the triage process?
Matt_King: Last week, we recorded three volunteers, I believe
dmontalvo: I was one of them
Matt_King: My proposal would be that, when people are on rotation (perhaps two times a month), they commit to an hour of independent triage--either the "intake" process or the "bug reproduction" process
Matt_King: Obviously, we don't get bug reports every single week, so eventually, we would be able to begin revisiting prior bug reports using this process
Matt_King: There appear to be about 30 bugs already existing. This means that we could have really solid documentation on them all by some time in June
jongund: How do we sign up? Is there a wiki page?
Jem: I need to create a place to manage this, but I haven't selected one, yet
Jem: Let's use the GitHub Wiki associated with the aria-apg repository
Matt_King: That means folks will need to be comfortable working with GitHub Wikis, but I think that's a reasonable requirement
Fix to make combobox labels clickable
github: w3c/
Matt_King: I put this back on the agenda because we were trying to get people to review it last week
Matt_King: I also had a question for jongund
Matt_King: Previously, the label was in a "<label>" element, and now, the label is in a "<div>" element
Matt_King: My question for jongund is: was that change intentional?
jongund: It was. To me, the "<label>" element wasn't doing anything. I thought a "<label>" element with an associated event handler might be misleading for folks reading to code
Matt_King: In the past, we've advocated for using semantic HTML even in the presense of ARIA because the semantic HTML could act as a sort of fallback for browsers/ATs that don't recognize the ARIA
Matt_King: But your thinking is kind of the opposite of that
Matt_King: It's a more pedagogical case
Matt_King: I could see it either way
Jem: As a developer, I'm accustomed to using the semantic elements whenever possible
Matt_King: Right, but jongund's point is that the "<label>" doesn't do anything in this case. The "click" handler could be confusing to readers. This is example code that we're considering, after all
howard-e: From what I've seen, there are more instances of "<div>" elements being modified to support "click" handlers
Jem: I typically write code from a "semantics-first" mindset
jugglinmike: I'm thinking about graceful degradation. Are there any implications to this distinction in cases where there is no event handler (because the JavaScript has not executed, for whatever reason)
dmontalvo: I'm not convinced that this should be changed from "<label>" to "<div>"
jongund: "<label>" is a special thing--it does something when used correctly
jongund: In the ARIA spec, the group decided not to have a role named "label" because it wouldn't do anything.
jongund: If we say that you should use the "<label>" element here, then all our examples that used "aria-labelledby" had better point to an HTML "<label>" element
Matt_King: I'll have to do some analysis, but I think jongund's making a pretty solid argument (because I don't think a change like the one he's just described would be an improvement)
dmontalvo: Thanks jongund, I wasn't seeing the "aria-labelledby" attribute on the "<div>" element. That's an important aspect!
dmontalvo: I withdraw my earlier comment
Jem: Since we're using "aria-labelledby", using a "<label>" element doesn't add any value
Jem: Could we maybe add a note as a comment?
Matt_King: This is covered by the ARIA documentation
Matt_King: So I think jongund is helping us to be more consistent with what's already been done in other examples
Matt_King: It sounds like we have consensus
Matt_King: We need reviewers on this patch
Matt_King: We want a code reviewer and a functional review, and that's it
Matt_King: We don't need a test reviewer because this doesn't impact the tests
siri: I can perform a functional review with Android
Matt_King: Great!
Matt_King: And I will re-review based on this conversation today
Matt_King: I guess that's enough
Triage new issues
<Jem> https://
Failing dialog-modal_datepicker.js test
Matt_King: This is coming from within the Task Force, so we don't need the "feedback" label
Matt_King: Maybe I should change the definition of "bug" because this is related to the testing of the example, and that means the "bug" label is appropriate
Matt_King: We need to generally extend the language in the process documentation around "pages" to include "site design" and "infrastructure"
Jem: I'll add the label named "regression-testing" for now
Matt_King: howard-e provided excellent "steps to reproduce" in this case, but we should still assign someone to verify
Jem: I will assign myself
Matt_King: Great!
Matt_King: Just from triaging a single issue, we've already found several changes that need to be made to the wiki page
Matt_King: We'll get there bit by bit
Jem: The documentation is already good--it just needs a little more detail