Meeting minutes
Matt_King: Publication planning
Matt_King: In the milestone, there are six pull requests. Four of them are merged and ready to go
Matt_King: Okay, then I will do that later today
Matt_King: Now, for the two in active review, we have a listbox with tabs and the color settings ones
Matt_King: Maybe we should do a quick check on each of these two
PR 2991: Add Practice Page for Supporting Color Contrast Settings by mcking65
github: w3c/
Matt_King: Here, jongund has made updates, so it's ready for the next round of review
jongund: Yeah, I'm caught up on all the feedback I've received to date
Matt_King: We're looking for feedback from a few people
Matt_King: The person who last requested changes was Adam
Matt_King: jongund, if you've responded to those changes, then I think I should re-request review from Adam. I've done that just now
Matt_King: We haven't had participation from Sarah in a while. I wonder if she could look again because she had a lot of input before...
Matt_King: It would be great if we could get Sarah's input on the current state
Matt_King: howard-e is also on the list of reviewers
Matt_King: CurtBellew and JoeLamyman, both of your names are on here. Are you able to do those reviews?
JoeLamyman: Yes
CurtBellew: Yes
Matt_King: I think all of your feedback has been incorporated, JoeLamyman
JoeLamyman: Awesome, thank you
Matt_King: It seems like I should reach out to people directly and find out if they are available (and remove them from the "reviewers" list if they are not)
PR 3400: Revise Content for New Experimental Example of Scrollable Listbox with Actions on Options by mcking65
github: w3c/
Matt_King: This is the one that CurtBellew is working on--updating the aria-actions listbox
CurtBellew: I've made all three changes that we discussed last time
CurtBellew: jongund made a suggestion on the visual side. I didn't implement it exactly, but I think the change I made is in the spirit of his suggestion
Matt_King: Okay, so for reviewers... There aren't actually any reviewers assigned on this.
Matt_King: We aren't merging this one into main; we're merging it into another pull request branch. That's because that is the branch that is referenced by another issue in ARIA. So we don't have to have a formal review process here.
Matt_King: If we're comfortable with the amount of feedback we've received so far, we can merge it to update pull request #3372
Siri: As soon as the focus is placed on the list box, you have to use the up and down arrow to traverse. I'm using the left and right arrow. If I use the left arrow, it goes from items to the star, but if I press left again, I feel like focus goes to the entire list box, but I'm not sure
CurtBellew: It goes to the entire option. I see what you mean
CurtBellew: There's no change in the visual presentation
Matt_King: I think I understand. When you take it off of the star and go back to the whole item, the "sub-focus" (the focus on the thing inside the item) disappears and gives the feeling that something was lost.
Matt_King: I feel like that's the correct behavior. You still have the focus ring
CurtBellew: We could change the appearance of the focus
Matt_King: Yeah. You still want to keep some kind of ring around the whole item because it's a composite. It's like focusing within a row
Siri: When the focus is on the star, when I tab, the focus goes to the next item on the page
Matt_King: That sounds like a bug
CurtBellew: I see what you mean
Matt_King: Okay, for the first behavior you observed, Siri, let's make a decision. Should we leave it as-is and see if it is confusing to others (based on any feedback we receive), or is it clearly going to be a problem (that is: should we address it right now)?
Daniel: With VoiceOver today, what would be the actions are unlabeled. At this point, I'm not sure if we can do something for that not to happen
Matt_King: Hm. James said that they are fully supporting aria-actions already...
Daniel: I was surprised to hear that, too. I was expecting to use the native actions support, but that isn't supported in the rotor, yet
Daniel: This is Safari in macOS
Matt_King: They are definitely not unlabeled. JAWS is reading the label. I almost think it's a Safari bug. Or it may be a VoiceOver bug
Matt_King: Even if I look at them with the JAWS virtual cursor or the mouse cursor, they're still present and they have labels
Siri: For some reason it says aria-actions is empty
Matt_King: It should be empty when you first land on it
Siri: But when it shows on hover...
Matt_King: ...that's when it should not be empty
CurtBellew: On hover or on focus?
Matt_King: Actually, only on focus. I'm not sure that hover should popular the aria-actions attribute, but it wouldn't be wrong if it did. Focus should definitely populate the attribute
Siri: Okay, on focus, I'm seeing it
Matt_King: Back to the question of whether or not we should change the visual design of focus
Matt_King: I'd like to propose that we leave it as-is for now and see if we get reports from others that it is problematic
Matt_King: The focus behavior is acceptable. There's no WICG failure here
Matt_King: Not hearing any objections to that right now
Matt_King: The second thing Siri reported sounds like a bug. If you focus on the favorites button and tab out, then the visual focus indicator is not reviewed
CurtBellew: Confirmed. I will fix that
Siri: aria-actions, do you have to provide the ID?
Matt_King: Yes because it is inside the option
Siri: Got it, thanks
Matt_King: Okay, so CurtBellew, I don't know if it makes a difference whether you fix it before or after I merge this.
Siri: Also, the labels aren't being announced by VoiceOver
Daniel: It's happening seemingly randomly. We should figure out what the pattern is
CurtBellew: I haven't tried that in Safari at all
jongund: I have a Mac
Matt_King: Could you test it with VoiceOver and see if there are any patterns behind when labels are not getting announced?
jongund: Now?
Matt_King: When you have time
Issue 2438: Tablist that supports reflow
github: w3c/
Matt_King: We discussed this two meetings ago. We came up with solutions in the meeting four weeks ago, and we proposed that we make two separate examples with two variations on a tabs list that supports reflow
Matt_King: I made those two sub-issues, and the goal was to make them with enough specificity that they would be "good first issues"
Matt_King: One of the open questions that I came up with is about the number of tabs that we should have in the example in order for it to adequately illustrate the need for reflow.
Matt_King: One of the things we had done previously in another pull request was to actually reduce the number of tabs
Matt_King: So that's the first question--it's about making the sub-issues more specific
Matt_King: We could discuss this now in the meeting, or someone can work with me after the meeting (I just can't make decisions on the visual aspects on my own)
Matt_King: To answer this question, you'd have to load up the example and do some visual experimentation to determine how many more tabs we need
Matt_King: Would anyone be willing to partner with me?
JoeLamyman: I'd be interested in helping out with this one if that's okay
Matt_King: That would be great!
Matt_King: The visual design specs for the two sub-issues are going to be almost identical. We can start with either one of them. That's why I put the question in issue 2438--the main issue
Issue 3428: Proposal for potential accordion improvements
github: w3c/
Matt_King: We started the discussion of this last week
Matt_King: We discussed some of the proposed changes that are in there
Matt_King: We noticed one accessibility bug related to aria-expanded
Matt_King: The person who filed this has responded
Matt_King: I asked some follow-up questions. It seems there are two main features that the person is proposing that we may be interested in adding to the APG accordion example
Matt_King: The first is related to browser find, and the second is related to the way screen reader landmarks/VoiceOver rotor works
Matt_King: That first one is about finding content in an accordion panel that is collapsed
Matt_King: I think the only reason that we would want to adopt that change and make it part of the APG example is if we could justify doing so with an accessibility benefit
Matt_King: Do we see an accessibility benefit? Or is there another reason we should consider adopting that capability into the accordion even in the absence of an accessibility benefit?
CurtBellew: It seems like it would be the opposite. It seems like you wouldn't want to be something that isn't visible to be find-able
Matt_King: I think it could go either way. Maybe the APG should be silent
jongund: People may forget to do the before-match event to update states and properties. So it may be a useful way to remind readers to keep aria properties in sync as the state of the page changes
Matt_King: Right
jongund: If we ask whether this is good/bad for accessibility--this is what people do, regardless. Part of me thinks we should provide guidance. It seems like it's a good thing to add whether we think it's good to search for hidden content. My guess is that it's probably something that most people want if they're looking for specific keywords
Matt_King: That's a super-good point! If it's something that is done often enough, and if it has potential accessibility side-effects that we want readers to understand, then we should demonstrate it in the APG to help people avoid the "gotcha"
Matt_King: In that case, it would not be "scope creep" or adding unnecessary complexity to APG
Matt_King: Does that make sense to the rest of the crew here? That if you want stuff to be find-able, there are important things you have to do to ensure that the accessibility of the accordion doesn't break. Therefore, we should explain what those things are
Daniel: I think it's good advice
Matt_King: Okay, hearing no dissent, we can go with that
Matt_King: That's the find-ability thing
Matt_King: The next question (to which the issue author has not responded) is why we want to make the collapsed hidden panels (essentially "div" elements with a "region" role) focus-able but not in the focus order (so tab-index to -1)
Matt_King: But by doing that, somehow, they show up in the VoiceOver rotor. That seems problematic to me. It doesn't seem like a region that is not visible should be in the rotor
Matt_King: It's not 100% clear to me that is the effect of the code (I haven't tested it with my iPhone in the CodePen)
Matt_King: One the one hand, if you can navigate to the panels via the headings, then why not via the regions?
Matt_King: But somehow, navigating via the region doesn't seem to me like a good idea.
Matt_King: Does anyone have thoughts on that?
Siri: So what is the option here?
Matt_King: Two things. First, setting tab index to "-1" on the regions. Second: adding a focus handler to the panels (if I actually don't know whether the
Matt_King: It could be the case that if VoiceOver is somehow picking up on the hidden regions, then when VoiceOver is issuing the command, that would cause the region to become focusable and the handler would display it
Matt_King: This might be a fallback mechanism, when something is focusable but hidden. That would seem like a bug, though
Matt_King: They might be getting a behavior either because of a fallback mechanism or a bug (in VoiceOver or Safari)
Matt_King: Daniel do you have any thoughts?
Daniel: I'm not sure why VoiceOver is doing that (I haven't checked it enough). I agree with you, though: if it's hidden for everybody, then I don't see why it should be accessible for AT users
Daniel: I understand the use-case, but that's another story. That could be enabled via a plugin or a setting. But in the general case, I would advise against it
Matt_King: That's my intuition as well
Matt_King: So I think, summarizing this
Matt_King: As I read it, there are three changes, and there is one of the three that we think is a good addition. That is: the support for browser find
Matt_King: So we have some decision on what the pull request could contain. The author suggested that they could be available for that pull request
Issue 3439: Question about keyboard behavior in experimental tabs example
github: w3c/
Matt_King: This is about our current experimental tabs example (with aria-actions). It's about the keyboard behavior there
Matt_King: They are asking whether or not the behavior we have in this example matches the documentation. And whether or not that's what we really want
Matt_King: This is a little nuanced because it's related to tabbing in, changing the focus, and then back-tabbing
Matt_King: This is an example where which tab is active (the tab that is displayed and selected) is manual. You have to press tab or space to activate it. If you make a tab active, then move to another tab, then move out, and then shift-tab backwards
Matt_King: I believe the behavior in that case is expected. We should validate that
Matt_King: And then for the shift-tab, the wording...
Siri: [describes a nuanced shift-tab behavior]
Matt_King: I don't know. I'm reading this documentation, and the reporter is having a different interpretation of the documentation
Matt_King: I think the behavior and the documentation are aligned
Matt_King: I don't think you could skip over the actions button. I suppose you could, but it feels complex
Matt_King: There are two options. When you are not in the tab list (your focus is after the tab list) and you're going backwards into the tab list. One option is that the focus could jump directly to the active tab (skipping over the actions button).
Matt_King: I think that violates one of our principles: your tab sequence should always be reversible. If you back-tab and then forward-tab, you should end up in the same place from which you first back-tabbed
Matt_King: Personally, I hate it when that expectation is violated
Matt_King: Essentially having any kind of forks or conditions in the tab sequence, I find that extremely confusing and hard to deal with
Matt_King: I can understand why someone might want to skip the actions button when tabbing backwards and only have it when going forward. But in terms of keeping a linear sequence, it doesn't feel like a good idea to me
Siri: If you do shift-tab, it is placed on the "more" button, but...
Matt_King: It sounds like you might have found a bug
Siri: Select any tab, I have "baskin shark" selected
Siri: Now tab forward
Matt_King: I'm at the "more" button for baskin shark
Matt_King: Now, I tab again, and I go to the tab panel for that shark
Matt_King: Now if I tab backward, I go back to the same button, and back to the same tab
Daniel: I couldn't reproduce what you said, Siri
Siri: Maybe I got confused
Matt_King: [describes a nuanced tab sequence]
Matt_King: That seems to work as expected, as well
Daniel: This one's a little bit awkward. I expect it will evolve as aria-actions matures. For now, I think it's the best we can do
Matt_King: There is still this kind of debate. For keyboard users who wouldn't be taking advantage of aria-actions, you still have to do something in the tab sequence here... I think
Matt_King: This example is suggesting something a little bit different from what, say, Chrome has done in its tab bar
Matt_King: I find Chrome's behavior annoying, but I think you could justifiably do it either way
Matt_King: As long as it's only one button, I think it's okay. But if you had multiple buttons for tab (which is probably how you would design it if you had multiple aria-actions support)
Matt_King: The reason we did it this way for tab-list is because this is the most common application for tab lists. People generally don't put a bunch of buttons for every tab
Matt_King: Okay, we're out of time. Thank you very much, everyone, we can wrap it here. I can respond to the issue. It sounds like we are aligned that this is behaving as we expect
Daniel: Maybe this deserves an editorial pass to make sure the messaging is clear
Matt_King: I think that's a good idea. When you read the documentation, it's kind of complex