Meeting minutes
Setup and Review Agenda
<scribe> https://
<scribe> Matt_King: Next meeting: April 1
<scribe> Matt_King: Any requests for change to agenda?
<scribe> Matt_King: Hearing none, we’ll stick with the agenda as planned
Publication planning
<scribe> Matt_King: I’ve verified the changes from the prior publication in production. It includes John’s “SkipTo” update. Good job, everyone!
<scribe> Matt_King: I’ve created a new GitHub Project to track the “May publication”. It has a semi-random target date in the middle of May, and it includes three pull requests at the moment.
PR 3400: aria-actions example
<scribe> github: w3c/
<scribe> Matt_King: We’re skipping this for now
PR 3387: Clarify guidance for Focusability of disabled controls
<scribe> github: w3c/
<scribe> Adam_Page: I haven’t been able to incorporate your feedback, yet
PR 2991: Add Practice Page for Supporting Color Contrast Settings
<scribe> github: w3c/
<scribe> Matt_King: This is a giant pull request, and it’s been open for a long time. I recently merged the “main” branch back into it to make sure there are no conflict
<scribe> Matt_King: It may be trying to do too much
<scribe> Matt_King: jongund and I are the primary authors. jongund did a lot to pull together the relevant information, including a survey of blog posts. We were trying to hit the bar of being practical.
<scribe> Matt_King: I think what might be most helpful right now is to get some general feedback right now. High-level feedback on whether it is organized in a way that we believe will be helpful to a reader who is interested in this topic. Also, are we covering useful information?
<scribe> Matt_King: I’m trying to figure out: what’s the best way to move this forward? I don’t want to put something in APG if it’s hard to maintain but not actually useful.
<scribe> jongund: My biggest concern is that in the APG, we don’t do much of any of this.
<scribe> jongund: Putting it in makes it look like it’s important to do, but we don’t do it
<scribe> jongund: We have some examples that demonstrate doing some of these things
<scribe> jongund: But from a practicality standpoint: should I implement contrast?
<scribe> Matt_King: That’s a good point. What we would do in the APG or what we wouldn’t do in the APG does suggest something about the importance of each item
<scribe> Matt_King: Are these things that people don’t do because they don’t have to? Or because they don’t prioritize it?
<scribe> Matt_King: What should the APG cover in this space?
<scribe> jongund: People see these things, so we should say something about them. Saying nothing discounts them to other people. Readers will see these things out there and wonder if they should do something about them.
<scribe> Adam_Page: At Hilton, we are generally pretty aware and savvy about the techniques that are described here. We use them as little as possible because we want things to just work”. We don’t want them to get in the way of default behavior
<scribe> Adam_Page: We do have some pretty specific scenarios where we use “high contrast” mode, eg. in our “tab panel” implementation (our “active tab” includes some high-contrast-mode specificity to ensure that the visual indication of the active tab shows up there)
<scribe> Matt_King: is that in the system colors?
<scribe> Adam_Page: Yes
<scribe> Matt_King: Another company out there that doesn’t have your awareness is including things based on the APG. If you’re doing styling that disappears if someone is using these accessibility settings, then this is important. That’s kind of a prioritization statement.
<scribe> Matt_King: Are there any automated checks out there that say, “you ARE doing automated styling” and that will disappear if these features are in use?
<scribe> Adam_Page: Not that I’ve seen.
<scribe> Matt_King: Computed style is available to all the checkers
<scribe> Adam_Page: Yes, but I haven’t seen any checker that attempts to deduce that the style is informative
<scribe> Matt_King: Ah, right. Recognizing the problems from specific properties applied in specific ways is not necessarily deterministic.
<scribe> Adam_Page: right
<scribe> Adam_Page: I think this is really useful. It’s interesting that we’re considering it in APG because ARIA figures into it so lightly
<scribe> Matt_King: Yes, that’s true.
<scribe> Adam_Page: It’s probably no coincidence that the one place at Hilton where we DO do something is in an ARIA feature (the tab-set). Otherwise, we try to rely on native semantics.
<scribe> Matt_King: I wonder if it would be useful to state something along those lines in the into
<scribe> Matt_King: How do you do something at the top of this that say, “for you, this is interesting and here’s why” so that for everyone else, they recognize that it’s safe to ignore the page.
<scribe> Matt_King: So from your point of view, Adam_Page, this still seems potentially valuable in the APG
<scribe> Adam_Page: Definitely
<scribe> jongund: What about color scheme (light/dark modes)?
<scribe> Adam_Page: Hilton doesn’t support them in our web applications (though we do in our native mobile apps)
<scribe> jongund: Does the W3 support it?
<scribe> daniel: The specifications do. I’m not sure about the WAI website
<scribe> joe: I think it would be useful to see these considerations in one place. I’ve seen each topic in separate areas, so collecting them together is great.
<scribe> joe: Having considerations against each method (perhaps in a new column of the table) would be nice
<scribe> joe: It would be nice to have “things to look out for” when using high-contrast mode. Just to sort of walk people through that process.
<scribe> Matt_King: Can that table handle another column? It feels wide to me, but I can’t see it.
<scribe> joe: Visually, it does look quite large on the page. I’m not sure
<scribe> Matt_King: Were you suggesting that near the beginning, we add some text?
<scribe> joe: Something about what people should check for when it comes to what visual information will be perceivable
<scribe> Adam_Page: On the “quantity spin button” example I built last year, I did do some high-contrast work. I don’t remember specifically what I did, though
<scribe> Adam_Page: Quantity Spin Button example and mention of forced colors https://
<scribe> Matt_King: What would the problem be if people did NOT do that? Is that the kind of guidance we’re looking for?
<scribe> Adam_Page: I think one active state might not show up
<scribe> Matt_King: The fact that you can’t remember even after reading what we’ve written is a little concerning. Maybe we should update the wording to describe the specific situation
<scribe> jongund: There are some broken parts to contrast themes, e.g. with pseudo-elements
<scribe> Matt_King: It sounds like there is some value in continuing this work
<scribe> Matt_King: It sounds like we need some kind of introductory statement that describes when/how this is useful
<scribe> Matt_King: And a comment on the “quantity spin button” that explains “this is what would have happened if we didn’t implement high-contrast” would be helpful
<scribe> jongund: There is a section at the end about SVG versus bitmap graphics
<scribe> Matt_King: Maybe that doesn’t belong. That may be another future discussion
<scribe> Adam_Page: I have time to read through this.
<scribe> Adam_Page: I can start by doing exactly what you suggested regarding adding some explanatory text (it has to do with visually making three buttons appear as one. I used “Highlight” to do that (https://
<scribe> Matt_King: If we have an example like this, in other parts of the article, we have screenshots to depict what the failure state looks like in high-contrast mode (along with screenshots to depict the “normal” visual rendering). That demonstrates the kind of problem that authors need to be aware of
<scribe> Matt_King: If we could knock this one out in the next couple months, it would be great to get it out of the backlog!
PR 3418: Landmark Practice: Update alignment between HTML aside element and ARIA complementary role
<scribe> github: w3c/
<scribe> Matt_King: the contributor is trying to align with what HTML says about “aside”
<scribe> Matt_King: I haven’t reviewed the spec recently
<scribe> Matt_King: for right now, I would love to designate someone who would love to “run point” on the technical entails of this pull request–does it say what we need it to say, and are the details justified?
<scribe> joe: I can review
<scribe> daniel: I can review as well
<scribe> Matt_King: I really appreciate that someone from the outside is paying close attention
Issue 1229: Feedback on documentation of button keyboard support
<scribe> github: w3c/
<scribe> Matt_King: This is very old, but people were recently talking about it
<scribe> Matt_King: It concerns different platform preferences related to when different buttons are activated. Essentially, at what point during the “key down”/”key up”/”key event” that the button is activated. It concerns the ability to “change your mind” about whether the button is activated.
<scribe> Matt_King: I’m amazed that any human in the world might do some of these cancellation activities
<scribe> Matt_King: I’m looking for advice on what the next steps should be.
<scribe> Adam_Page: Zoe struck some of her list items out.
<scribe> Matt_King: This behavior is not documented. Is that the fundamental issue? It seems like there is some discussion about whether this is the correct behavior.
<scribe> Matt_King: In December 2025, someone performed some testing. That’s why it’s on the agenda, now.
<scribe> Matt_King: If you use a button element, and you don’t use any JavaScript, is the behavior standardized?
<scribe> jongund: I don’t see an example where the APG uses “key up,” so this may be a moot issue.
<scribe> Matt_King: Oh. Did we go through and make changes in response to this? It’s been five years, after all
<scribe> Adam_Page: When I search the codebase, I am seeing event listeners for both “key up” and “key down”.
<scribe> Adam_Page: looks like alert dialog, button, combobox, checkbox, layout grid, and maybe some others. There are quite a few for “key up,” and also some for “key down”
<scribe> Matt_King: Which button example?
<scribe> Adam_Page: The match is in the “button.js” file.
<scribe> jongund: It may not be something we’re actually using
<scribe> Matt_King: In terms of technical problems or interaction problems, when I go back and read the beginning of this, it sounds to me like what’s left here (since we struck out the “mac versus Windows” point and the “you can’t cancel” thing)--that in general, we’ve taken the position that the APG is not an engineering guide (it doesn’t teach you how to code), but it DOES document the ramifications of specific engineering choices, and it guides you to make decisions that favor accessible experiences.
<scribe> Matt_King: I am wondering whether this is really boiling down to a documentation issue. Unless we’re doing something that is out-of-step with a best practice, it seems like we could possibly close this issue
<scribe> Adam_Page: I agree. It seems quite deep in the weeds. Possibly the only scenario where it would make sense for us to talk about “key up” and “key down” is if we chose to favor one over the other.
<scribe> Adam_Page: Documenting the difference across native implementations seems out-of-scope to me
<scribe> Matt_King: Does what the APG is already doing appear inconsistent with what is happening in the outside world?
<scribe> Adam_Page: We’d have to do some analysis to answer that question. “Key up” and “key down” both have distinct and legitimate use-cases. It could be that we’re using each of them legitimately for each of the APG examples, but it could also be that we chose them arbitrarily (and inconsistently) in cases where either would work fine.
<scribe> Matt_King: Should we document a recommendation about the “repeating keypress” example for “key down” when holding a key down…?
<scribe> Matt_King: We’re out of time!