Meeting minutes
Setup and Review Agenda
Matt_King: Next meeting: March 26
Matt_King: Any requests for change to agenda?
Matt_King: hearing none, we'll plow ahead
jongund: I'd like to talk about modernizing the codebase, actually
Matt_King: Sure; we'll talk about that after the first two planned agenda items
Publication status
Matt_King: Target April 1 for next publication.
Matt_King: There are a couple things that are close: work on the "feed", and also the combobox pull request in the next agenda item
howard-e: Sounds good to me. I'll be available then
Fix to make combobox labels clickable
Matt_King: Siri isn't here, so we'll skip this one today
Code quality plan
Matt_King: So jongund was thinking about looking across the APG, evaluating the current state of code quality
Matt_King: Were you thinking of putting together a plan to prioritize specific examples?
jongund: My more immediate concern is how we are not using media queries to honor forced colors
Matt_King: So we're talking about one specific dimension of quality
Matt_King: Related to that, you've been talking about writing guidance about supporting high-contrast mode
jongund: That's right
jongund: Some of our examples which are still using JavaScript prototype instead of classes--there were too many changes to address those in the context of bug fixes
jongund: I'd be happy to focus on supporting high-contrast mode, though
Matt_King: Could you start a "high-contrast mode" project by making a change to the quality-assurance report?
Matt_King: ...one that would surface the examples which don't support high-contrast mode but which ought to support it
jongund: I believe I already did that
Matt_King: Let me check the coverage and quality report... It says there are 31 examples with "high-contrast mode" documentation out of a total of 60
Matt_King: Is that what you were talking about?
jongund: I'll review that offline and get back to you
Matt_King: Send me an e-mail when you have something you'd like to talk about related to this, and then I'll add it to the agenda
jongund: Sounds good; it may be a few weeks from now
Should radio buttons activate with Enter?
github: w3c/
Matt_King: I think this is an important question, partly because we used to have checkboxes which activated on "enter", and somebody pointed out almost this identical issue
Matt_King: e.g. how do they behave natively, etc.
Matt_King: We changed the checkbox so that it only activates on "space"
Matt_King: I'm interested in answering this question as soon as possible because at this moment in time, the "radio button" test plan is being revised in ARIA-AT
Matt_King: ...if we're going to take the "enter" key away from this, I'd like to remove the associated test now rather than have to update the ARIA-AT test plan again later
jongund: I'm okay with "spacebar" alone activating the radio
Matt_King: In Chrome, Cameron is saying that only the space bar activates native radio buttons
Matt_King: Should we look at what native radio buttons do in at least Safari?
Matt_King: Between Chrome and Safari, should we consider that "alignment"? Should we also consider Firefox?
Matt_King: Our pattern is already different from native radio buttons because in native radio buttons, "forward tab" and "backward tab" are not symmetrical operations. We've discussed this previously
Matt_King: The browsers don't treat it like a true composite the way that ARIA says it should be a true composite
Matt_King: If you tab into the radio group, tab out of it, and then tab back into it, you don't end up in the same place
jongund: "Enter" submits the form in native radio buttons in Safari
jugglinmike: Is it worth checking what "enter" does on a radio button that isn't part of a form?
Matt_King: Yeah, probably. I'd hope it would be a "no-op" in that case, but we should check
jongund: In Safari, the "enter" key does nothing if there's no "form" element. The space bar still activates in that case
Matt_King: I think the fact that there is two major browsers is compelling. I also think that consistency with checkbox is relevant
jongund: I don't think we should deviate from what browsers do if we don't have a good reason (e.g. like we have a good reason to deviate when it comes to "tab")
CurtBellew: I agree with this--"space bar" activates and "enter" does not
Matt_King: If we are going to fix this, it requires a change to the code and the documentation. I'm happy to take on the editorial change in the pattern
Matt_King: Do we have any takers who would like to modify the example?
jongund: I can do that
Matt_King: We have two "radio" examples: one with active descendant and one with roving tab index
jongund: Just removing support for the "enter" key, right?
Matt_King: That's right. You can change both examples in the pull request, and I'll add the documentation changes to your patch
jongund: Do we consider this a bug fix?
Matt_King: I think this is a material change to guidance. I'm going to label it an enhancement
Matt_King: Is it really an enhancement, though?
jugglinmike: I think it comes down to whether the prior behavior was intentional. It seems like supporting "enter" was indeed intentional, and that would make this change an enhancement rather than a bug fix
Matt_King: I agree
Matt_King: I'm assigning myself and jongund
Combobox select vs focus issues
github: w3c/
Matt_King: I did further exploration here, and essentially, our documentation about aria-activedescendents is not in-line with aria-selected
Matt_King: This issue could be broken out into multiple issues, but I think the thing we need to talk about right now is... comparing two examples: "select-only combobox" and "combobox with list-autocomplete"
<Matt_King> combobox with autocomplete list: https://
Matt_King: If we compare these two, there are some differences that I'm not sure we want to have
Matt_King: for the editable combobox with list-autocomplete--the behavior if you go into the combobox, you find a list of territories. If you don't type and you just "down arrow", it opens the combobox, and you can go through all the states
Matt_King: ...in this case, were you just down-arrow, I don't believe aria-selected is changing as you move through the list. It only changes when you press "enter"
Matt_King: The feedback in this issue is that we ARE setting aria-selected but that we shouldn't be
Matt_King: The real question here is: should pressing an arrow when visual focus is in the list box change the value of aria-selected in the combobox with list-autocomplete?
Matt_King: Right now, it appears to be doing that. The feedback in this issue (if I'm reading it correctly) is that it should not.
CurtBellew: If I arrow through, I don't see the value changing. If I hit "tab", whatever I am "on" becomes the selection
Matt_King: Right, that's true in both examples we're considering
CurtBellew: For me, that makes it seem like it's selected. But I know I can hit the "escape" key to close it, and when I do, nothing is selected
Matt_King: We had a discussion about that behavior in particular. In the documentation of keyboard support for select-only combobox... It seems that "tab" is not listed. That seems like an oversight to me
Matt_King: I think it's an oversight because I know the current behavior for "tab" (that is: to "select and close") was an intentional behavior
Matt_King: Oh, pardon me. "tab" is documented
Matt_King: Never mind what I was saying about the oversight just now
Matt_King: It's an intentional behavior. It's documented in the select-only combobox, but it's not documented in the combobox with list-autocomplete
Matt_King: The person who raised this issue is perferring the behavior of the select-only combobox
Matt_King: They want to make the combobox in their component library work that way
Matt_King: At a minimum, they're saying that our documentation is inconsistent, and I 100% agree with that
Matt_King: I'm just not sure which behavior we want
CurtBellew: In select-only combobox, there is a visual checkmark to indicate selection state. That's not present in combobox with list-autocomplete
Matt_King: I think the primary question here is around aria-selected.
Matt_King: There's some strangeness in the list-autocomplete example. I observed it earlier, but I'm having trouble recalling it, now
CurtBellew: What is the benefit of changing aria-selected as I arrow through the list? Does it create problem to NOT set aria-selected as I arrow through?
Matt_King: I'm not sure, now that I think about it. It's like you almost don't need aria-selected at all
CurtBellew: On "select-only", you visually see what's selected. I think the aria-selected behavior makes sense there because it matches the visual experience
Matt_King: I think there's room for some asynchronous discussion here
Matt_King: We've at least recognized that there are inconsistencies. We should identify them formally and decide what to do from there.