Meeting minutes
<Jem> https://
Setup and Review Agenda
Matt_King: I won't be available next week
Jem: Then let's take a spring break
Jem: The next meeting will be on Tuesday, April 16
Publication status
Matt_King: None of these 5 pull requests are merged, yet, but I want to get them merged
Matt_King: Two of them appear later in the agenda, so we'll talk about those in due time
Matt_King: For the pull request for combobox, we're still waiting for someone to test it on mobile
Matt_King: Siri is currently assigned to that, but if the testing doesn't happen this week, then it won't go out
Matt_King: That needs to be tested specifically by someone who is not using a screen reader
<Jem> w3c/
Matt_King: We're looking for a test on Android or iOS to make sure that when you tab, the label still works as expected
arigilmore: I can take a look
Matt_King: Thanks!
Matt_King: Then there's the radio group pull request from jongund, removing the "Enter" key
Matt_King: I think jongund's three-line change to the JavaScript is really all there is (there is no reference to the "Enter" key in APG)
Matt_King: I've reviewed the code, and I think it's so minor that my review is sufficient to merge. Any objections?
Matt_King: Hearing none, I will merge it
Jem: I will take a look at the fourth item in the list--the pull request about the landmark example page
Infra updates
Matt_King: I would like two people to review the changes to skipTo
jongund: I'm the only one working on skipTo right now. The code is kind of complicated (Alt+0 wasn't working for a user of a French keyboard)
jongund: My patch removes the ability for users to change the keyboard shortcut
Matt_King: It's still an open investigation within Meta what we really want the approach to be with global shortcut keys like this
jongund: We could remove the shortcut key altogether
Matt_King: I don't really like that solution; the only way I ever use "skipTo" is by using a shortcut key
Matt_King: We could land this as-is, and jongund could take a new issue in skipTo to address this
Matt_King: But I'm wondering if someone could look at the skipTo change
howard-e: I can review it
jongund: I will create an issue in the skipTo project repository for disabling the shortcut when focus is on an input, and I'll reference that new issue in this existing one in APG
Infrastructure: Fix syntax highlighting bug on examples by evmiguel · Pull Request #2939 · w3c/aria-practices
github: w3c/
Matt_King: I think this needs a visual review
Jem: I will do it
Approach to keeping date correct on coverage report
github: w3c/
Matt_King: My understanding is that, if we were to take this approach and merge this, then every time we merge a pull request, there's going to be a commit for merging the pull request and there's going to be a subsequent commit for updating the date on the quality report
howard-e: That's correct
Matt_King: Could we change the script that generates the report so that the date that is in the report itself doesn't change?
Matt_King: For example, lets say we took jongund's "radio" pull request here. Lets say it was March 26, so his commit is March 26. The quality report runs on March 26, and it doesn't use the date that it runs--it uses the date of last changed file.
Matt_King: That way, if he ran the coverage report on April 1, then it will still keep March 26, because it only considers the state of the code
howard-e: I think why I ended up doing like this--it was based on the comment that the date should reflect the moment it was merged into the "main" branch
<Jem> "As a request of yesterday's APG meeting, this PR will capture any changes found in that coverage report's diff check and immediately push it to the main branch because the "last updated date" should reflect when the affecting PR is merged in."
Matt_King: The only reason we want a date there is for us to be able to see that the report includes the latest changes in the repository
Matt_King: I don't know if the date of the merge to "main" is that important
Matt_King: I've been trying to keep the state of the history of the "main" branch as clean as possible
Matt_King: Now, these commits are labeled "CHORE:", so we can filter them out. So maybe I shouldn't even care.
Matt_King: But it seems like having the extra commits is just more to ignore
howard-e: If the date that it is merged into "main" truly doesn't matter, then I can walk back that second "CHORE" commit. It wouldn't be a problem
howard-e: My other suggestion was making a transform on the "build" repo. So that none of this date manipulation would happen here
Matt_King: If we're working on pull requests that would cause changes to a report, we'll want to be able to look in the report itself and see that the report was updated
howard-e: The date would still show up in the preview, even if it was part of a transform in the "build" repository
Matt_King: So we would still have the "coverage and quality report" script and generation all done in the repository
Matt_King: Because it's part of the content, I kind of like having it in the "content" repository, but I'm okay with either
Jem: So the last-update date would be when?
Matt_King: It would match the date in the footer on example pages
<jugglinmike> s/it would match/the "last update" date would match/
howard-e: If it's done from APG, the date would reflect the moment of the latest contribution. If it's done from the "build" repository, the date would reflect the moment of the merge
Matt_King: You're right. It's probably better to do this as a preview, that way, the two kinds of dates that we're exposing on the site would match
<Jem> https://
Matt_King: Why does "alert" say it's been updated in the past two months?
howard-e: We updated "skipTo" across all the pages
Matt_King: Ah. This is why we need that other feature we discussed--to make that date link to the list of relevant commits. That way, folks could understand what the date actually described
Matt_King: I have a design issue for this somewhere. It kind of got de-prioritized
Matt_King: We don't have any complaints recently, but there is an issue related to this in the backlog
Matt_King: In the future, "skipTo" changes will not effect this date. That's a beautiful part of jongund's recent changes to skipTo--we'll never have to update the pages when "skipTo" changes
Support for experimental content
github: w3c/
Matt_King: If you follow the preview link, then go to the "index" page and scroll down so you have the very last heading on the page in view
Matt_King: It's called "experimental examples"
Matt_King: The first pattern we want to get into APG is called "ARIA Actions"
Matt_King: We want people to be able to get to ARIA Actions--the people who are working on this, e.g. ARIA-AT Testers
Matt_King: Those people will be able to pull up this example which is "not part of the official APG"
Matt_King: There are several aspects to the design of this page
Matt_King: Every experimental example's title has the word "Experimental" in brackets
Matt_King: The "read this first" content is expanded by default (instead of being collapsed by default)
Matt_King: And the "About this example" section instead read "About this experimental example"
Matt_King: all of these things would change when the example stops being experimental
Matt_King: But we won't do this in the pattern itself. It's kind of hidden. Not totally hidden, but kind of
Matt_King: My question for the group: Is this design sufficient to make sure people understand that this is experimental?
Jem: This is great. I remember talking about this at TPAC. There, I mentioned that I wanted to see a reference to ARIA to help explain why we are experimenting here in APG
Jem: I think we're missing that context at the moment
Matt_King: We would address that in the "About this example" section by adding a link to the draft
Jem: I have some thoughts about the wording of the description
Matt_King: I'm still working on the wording; I'm mostly just looking for feedback to the high-level changes (The title, the heading, etc.)
Matt_King: At the point in time that it becomes evergreen in ARIA, we would have a pull request that removes the word "experimental" everywhere it shows up, we would remove the metadata that causes it to be listed separately in the index
Jem: I like that. I like that we'll be able to prepare for the transition to take place when the time is right
jongund: I think it looks good. It seems pretty clear that it's experimental. The word is everywhere
jongund: I agree with Jem's feedback to highlight the relationship to the draft spec
Bryan_Garaventa: Does it explain what the term "experimental" means?
Matt_King: yes
Matt_King: I'm going to take this to the next level by updating some of the content. Is that going to be a problem for Alex?
howard-e: That should be fine
howard-e: Should this be excluded from updating the "coverage and quality" report?
Matt_King: I actually think that no, it should not be excluded, for two reasons. I think it would be good to be able to see if the experimental pages cause any quality problems.
Matt_King: Second, even if people outside of the APG Task Force look at the report, I think the title of these pages will make it clear to them that these are experimental.
Improving guidance for setting focus in multi-select listbox
github: w3c/
Matt_King: I'm having a little bit of difficulty following the text in the issue
Jem: This is about focus management
Jem: I'm reviewing the visual recording
Matt_King: I think it would be helpful if the reporter added explicit steps to reproduce, including each of their interactions with the keyboard
Jem: Yes. We can review this asynchronously and discuss it again next week