Meeting minutes
<Jem> https://
Setup and Review Agenda
Jem: Next meeting will be May 8th
Jem: Any requests for changes?
Jem: Hearing none, we'll move on
Publication status
Jem: next publication date: May 7
Matt_King: We pushed this back due to Access U and Shawn's availability
Matt_King: I don't know if we can get this all done by next week
Matt_King: Shawn did say that we could publish later in the week next week, if necessary
Matt_King: I guess we'll have to decide later in this week if we'll be ready on May 7
Matt_King: We could push back to May 21. I was hoping to avoid that because I wanted to get a new release in before Global Accessibility Awareness Day (GAD)...
Matt_King: ...but I haven't even started the blog post which would support that, so maybe it's already too late for that
Feed example update
github: w3c/
Matt_King: While testing, I was running into trouble with CTRL+End
Matt_King: Right now, since the CTRL+End is specifically targetting the delay slider, it's moving focus to before the feed instead of after the feed
arigilmore: Instead of the "terms of use" button? We added that button so there was somewhere else to go
Matt_King: Ah, I didn't realize that we had added that. That actually makes the problem simpler to solve than I thought!
Matt_King: Putting the focus there would enable that CTRL+End key to work whether its in CodePen or not
Matt_King: Oh, we don't have CodePen on this one
Matt_King: I don't know if we can. We don't have to make that part of this pull request, though
Jem: I can open an issue about adding CodePen to this page.
Matt_King: That CTRL+End behavior was the only problem that I had found
arigilmore: I'm not sure how much work it will take to fix that. I thought it was working a while ago; I haven't looked in some time, so I wonder if something broke recently
arigilmore: There is a regression test. In my "feed" test changes, it checks for the "CTRL+End" keys
Matt_King: CTRL+End is clearly taking me to the "delay" selector
arigilmore: Okay, I'll take a look
Matt_King: We probably need to merge the "main" branch into this branch for these tests to pass
arigilmore: The pull request branch is already up-to-date
arigilmore: Maybe I have to run the coverage report locally and update it myself
howard-e: That seems to be the case, but I'm not understanding why you have to do that...
howard-e: The regression in the other failing test is, I think, something I've been seeing recently. I attempted to fix it in a patch I pushed yesterday
howard-e: Alex is reviewing that fix, now
Matt_King: If arigilmore can figure out what's going on with CTRL+End, then I think this is ready for merge
Matt_King: I'm excited to get "feed" moving again. I think there are more steps for feed
Update to AT Support tables
Matt_King: If you look at the current "radio button" example in production and compare it to this one, the AT support tables (the section right after "roles states and properties"), the differences you'll find...
Matt_King: Previously we had ATs in the rows
Matt_King: Now, so that we can show more data for each combination, the first column is the combination of the screen reader and browser. The second column is for the percentage of passing "must" behavior, and the third column is for the percentage of passing "should" behaviors
Matt_King: We're going to add a link to a page explaining these columns (that's the next item in today's agenda), but before we go there
Matt_King: ...I have two bits of feedback: about the column names and about the number of rows in the table
Matt_King: On the column names, it says "must assertion priority". That's technically correct, but I think a name like "must behaviors" (and, correspondingly, "should behaviors") will be more understandable
Jem: I like that
Siri: even with that change, I have to go back and read what they mean?
Matt_King: "Must" behaviors are the ones that are required for the thing to be usable at all. "Should" behaviors are those whose absence would not prevent operation
siri: Usually, radio buttons, once you select one, you cannot unselect it
Matt_King: there is no support for unselecting a radio button without selecting another. That's built into the pattern
Matt_King: Although that's not related to anything in AT support
Jem: Do you have an analogy for these terms?
Matt_King: We're going to have a separate page to explain them
jugglinmike: The report page uses "MUST HAVE behaviors" and "SHOULD HAVE behaviors"
Matt_King: We can use those here, too, or we can change the report page to use "MUST behaviors" and "SHOULD behaviors"
jugglinmike: I prefer "MUST HAVE behaviors" instead of "MUST behaviors" because the word "MUST" is not an adjective, and I think that can make it harder for new folks to parse a name like "MUST behaviors"
CurtBellew: I agree
Matt_King: Sounds good
Matt_King: Now for the row order, they don't appear to be in any discernible order right now
Matt_King: I propose sorting them alphabetically
howard-e: We can do that, no problem
Matt_King: We're going to add a link to a page. I don't know the text of the link, yet--something like "learn more about assistive technology support". Something about how to understand this data
Matt_King: Whatever the text, should the link appear above or below the table?
Matt_King: There's an iframe which includes the table and the two associated buttons
Matt_King: The link would either go after the buttons or before the warning
Jem: Can you summarize the content that you are expecting to appear in this new explanatory page?
Matt_King: The next link in the agenda has a preview of the page https://
Matt_King: It includes a heading named "Assistive Technology Support tables"
Matt_King: If you follow that link, you'll find a placeholder page
Jem: I vote for "above" the table
howard-e: Me too; I like to be briefed on what something is before I see it
arigilmore: I feel the same
<Jem> https://
Adding a Live regions practice page
https://
Matt_King: This page about live regions is a few years old
Matt_King: Simon drafted it, and it was intended to be a starting point for discussion
Matt_King: We never got very far with it because there were so many different problems with live regions
Matt_King: Now, the Web Platform Tests browser interoperability for accessibility project is taking up issues with live regions
Matt_King: So it's a good time for this group to work on getting live regions done
Matt_King: As I read through this, I've been thinking about the things that need to be covered and how they need to be covered
Matt_King: So I'm particularly interested in hearing how folks here think this needs to be changed
Matt_King: You can add comments in the pull request; I just thought it would be easier for folks to read the current proposal by visiting the preview
Matt_King: For one, I don't think if an error and a chat log message are the best examples
Matt_King: Do folks here think we might want to maybe highlight other kinds of examples?
Jem: Why don't we add our comments to this pull request, also responding to the question you raised
Matt_King: That would be great
Jem: I'll assign it to everyone here on the call today. Any objections?
CurtBellew: Sounds good
Matt_King: I'm curious about the content at a high level. Right now, I'm not interested in fixing editorial issues like spelling and grammar
Matt_King: For instance, when it says "chat log", I think it maybe be confusing because I don't think anyone uses the "log" role because it typically doesn't do a good job of only communicating the changes that need to be communicated.
Matt_King: Maybe just "chat messages", for instance
Matt_King: Has anyone ever seen the "log" role used well?
Jem: Not me
Matt_King: I think the section titled "triggering live regions" should probably be level 2 instead of a sub-section
Matt_King: It isn't a live region state or property, so it shouldn't be a sub-section
Matt_King: And that sub-section (that is, "Triggering live regions") is probably the one that needs the most work
Jem: I know of a video by Sarah which may be relevant
Matt_King: If anyone wants to share some good references on the topic (either in the issue or the pull request) then we could use them as a basis for a summary