Meeting minutes
Setup and Review Agenda
Jem: Matt_King is out next week, should we cancel the meeting?
Matt_King: the day before is a holiday in the US
Jem: Hearing no objection, we will cancel the meeting for May 28
Jem: Next meeting: June 4
Publication planning
Matt_King: Shawn has agreed to do a publication on Thursday of this week
Matt_King: Can we have a branch ready on Thursday morning, howard-e?
howard-e: Yup
Matt_King: The relevant milestone is linked in the agenda: https://
Matt_King: w3c/
Matt_King: tests seem to be taking much longer to run in GitHub Actions
howard-e: I noticed that as well
howard-e: At the time, there was a GitHub Status advisory regarding performance issues; maybe we were experiencing the the same problem
Matt_King: I observed it as recently as this morning, so maybe not.
Matt_King: the regression tests were especially slow
Matt_King: the skipTo changes are waiting on a review from myself and from Jemma w3c/
Jem: I will get to that today
Matt_King: I think that will be ready for this coming publication. I expect to perform these merges early tomorrow morning
Matt_King: I'm going to push out https://
Matt_King: It looks like Jon submitted a duplicative pull request. I'm confused about that, so I posted a question to learn more
Matt_King: it looks like the only thing in this milestone that we won't get in for the next deployment is Jon's work with the coverage and quality report
Update to AT Support tables
Matt_King: a brand new page: https://
Matt_King: Boaz drafted it
Matt_King: We need reviewers
Matt_King: we have two major sections: what are the meanings of the support levels, and recommendations to readers
[Matt_King reviews the content of the new page with the group]
Jem: Generally, there's a lot of negative phrasings, and that's giving me a little trouble in understanding
Jem: for example, "Not negatively affect the experience when the failure being accommodated is resolved."
Matt_King: Maybe it should be phrased in terms of "When the AT vendor fixes the behavior [...]"
Jem: Yes, I like that
Jem: Also, I don't know what "Unless otherwise noted, all testing is done using the default configuration of an assistive technology." means
Jem: Everyone can have a different default, right?
Matt_King: No, because the default is what the AT ships with
Jem: Could you say the "system default", then?
Matt_King: How about "the assistive technology vendor's default"?
Jem: That sounds better to me
<Jem> https://
dmontalvo: We say that we don't advise implementing patterns that don't have 100% "must have" support
dmontalvo: It seems like there are a lot of ATs at the moment which don't have 100%, but I can't recall if that includes "should have" assertions
dmontalvo: I'm not sure if we want to make this recommendation differently
<Jem> "When possible, test implementations of APG patterns with an assistive technology that provides 100% support for both must-have and should-have behaviors."
Matt_King: The only places where VoiceOver has had a problem with "must have" have been features which are specific nav key features that people can generally work around
Matt_King: e.g. "navigate backwards to a button" might only work under certain circumstances
Matt_King: I don't think that failures there will raise a lot of red flags in terms of keeping someone from using a given pattern
Matt_King: though it might impact how they design their application
Matt_King: In general, though, when it comes to "must have" behaviors, the screen readers are doing quite well
dmontalvo: I defer to your familiarity with the latest results; I'm just concerned that requiring 100% may be too high a standard and may mean we are advising against using many patterns
dmontalvo: How many patterns do we have now which don't reach 100% of "must have" passing?
Matt_King: Maybe I need to change how I worded this
Matt_King: It says, "where *feasible*, avoid implementing *features* of APG patterns [...]"
Matt_King: Maybe it should be something like "Avoid designing experiences that rely upon features which have not reached 100% of 'must have' assertions"
Jem: I think the first list item is very clear. Are the others really necessary?
Matt_King: The second item is really saying what less-than-100% doesn't mean
Matt_King: Maybe saying "every way of implementing" instead of "every variant"
Jem: That would be better
Jem: ...but it makes me wonder about the title of this section. "Design Around Critical Support Failures". What do you mean by "design around"?
Matt_King: I think I have a wording here
Matt_King: I'll paste it in the chat
<Matt_King> suggestion:
<Matt_King> Where feasible, avoid designing experiences that rely on features of APG patterns that have less than 100% support for must-have behaviors.
<Matt_King> If the must-have support level is less than 100% for the example implementation of a pattern, that does not mean all ways of implementing that pattern will present assistive technology users with critical problems.
Jem: I'm still wondering about "Design Around"
Matt_King: How about "Design to mitigate critical support failures" ?
Jem: That's much better to me
dmontalvo: Me too
CurtBellew: I hadn't thought about this. I usually say things like "work around"
Matt_King: Great! I've just now implemented all the suggestions from this call so far
Matt_King: I also wanted to discuss the links *to* these pages
Matt_King: Just under the heading "Assistive Technology Support", there is a new link labeled, "Learn how to interpret and use assistive technology support data"
Matt_King: I just put it in a paragraph under the heading. Is that positioning/styling okay? And is the wording of the link clear?
Jem: The wording is clear to me
Jem: Do we want to use a sub-heading for the link?
Matt_King: I don't think so, no
Jem: It looks good to me
Jem: Anyone else?
Matt_King: If it's fine the way it is, then lets not complicate things
howard-e: seems fine to me, too
Matt_King: I would like at least one (ideally two) people on this pull request to serve as reviewers
Matt_King: We'd like a review before I would merge, and I want to merge in the middle of the day tomorrow
Siri: I can take a look this evening
Matt_King: That would be awesome! Thank you, Siri
Jem: I can look, also
Matt_King: I'm super-excited to get this out
Matt_King: We can merge the support tables in ARIA-AT App, howard-e
Matt_King: I think it's fine to merge it as-is even right now. Then these previews will show the real support tables
Matt_King: This is so great; we're gonna get this launched
Quality report tracking of force-colors
Matt_King: We don't have Jon right now, so we can't really do this
Select-only combobox enter key behavior
Matt_King: We'll come back to this when we have more time
Mouse behavior differences between Select-only and editable combobox
github: w3c/
Matt_King: My intuition was the opposite of the intuition of the reporter
Matt_King: I assumed that it WOULD select it because it was selected by the keyboard
Matt_King: The last person I remember talking a lot about using both mouse and keyboard was our friend at Norton--his name escapes me, now
Matt_King: It was about how many people would arrow down with the combobox but then blur with the mouse
Matt_King: Personally, though, I don't know what's reasonable here
CurtBellew: Honestly, I would expect it to work the same way as if I was using the keyboard, arrowing down, and then tabbing out
CurtBellew: Why would clicking out be different from tabbing out?
Matt_King: Would you be willing to check how Chrome, Firefox, and Safari behave with a native HTML select?
CurtBellew: Sure! I'd like to know, anyway
Matt_King: Great. We can put this back on the agenda in a couple weeks (since we're not meeting next week). We can follow the browsers' lead if they're consistent. If they're NOT consistent, then we'll have to have more of a discussion