Meeting minutes
Setup and Review Agenda
https://
Matt_King: any requests for changes to the agenda?
Matt_King: Hearing none, we'll stick with the agenda as planned
Matt_King: Next meeting: November 4
Matt_King: We will not hold a meeting on November 11 because many of us will be attending TPAC
Matt_King: I assume we will meet on November 18, but we may try to get a publication done before TPAC
Publication planning
Matt_King: I changed the milestone date to Wednesday of next week
Matt_King: That might be influenced a little bit by this pull request that we'll talk about next (the one regarding aria-actions)
Matt_King: It seems as though we'll have jongund's pull request for skipTo ready
Matt_King: I believe Adam_Page tested that and that it works
jongund: If someone could test it with Android, I would appreciate it. The issue also presented on Android and TalkBack, but I don't have an Android device to use for testing
jongund: I'll try to find an Android device
jongund: Do we want information about how the keyboard support does not apply to mobile devices?
jongund: If someone is expecting to use the cursor keys even with keyboard enabled on mobile, it won't work on mobile
Matt_King: We have that disclaimer about mobile on every example page
Matt_King: It makes me wonder, though. Are you saying that it isn't even achievable?
jongund: Well, for example, on skipTo, if you enable keyboard operation--you can tab to a button, but you can only use "enter" (or perhaps it was "space") to activate the button
jongund: The keyboard is a whole different ballgame
jongund: I was going to try with an iPad, but it's strange. You can use the keys in a text area...
Matt_King: I don't think that's something for us to do anything more right now
jongund: At least we have that disclaimer regarding the operation on mobile
<Daniel> Comment by Rémi on an alternative approach for not using javascript on the read this first banner
Daniel: Has anyone had a chance to review my issue--where remy has suggested an alternative approach for not using JavaScript injected content
Daniel: We agreed that this wouldn't block the previous publication
Daniel: But it would be nice to provide an answer there, even if we don't want to address it for the next publication, either
Matt_King: I don't want to cause a problem for the next publication... Let me review
Matt_King: This is issue 3373
howard-e: I could take a look. I've been off, so I missed this
howard-e: At first glance, this looks like it could work for us
howard-e: I will reply after this meeting
Matt_King: We'll have to talk separately about whether or not we can get it done for the next publication
Matt_King: If we could at least get alignment before the next publication, that would help
Issue 3193: listbox example with aria-actions
github: w3c/
Matt_King: I had a meeting with Sarah Higley and Brett Lewis about this yesterday
Matt_King: One of the questions was around, "why are the button names getting included in the label?"
Matt_King: Sarah offered to review the code of the pull request
Matt_King: She didn't think it was a problem with that code, though
Matt_King: Her suspicion is that the browser is not yet fully implementing the spec
Matt_King: We verified that when the action buttons are hidden, they are not in the name
Matt_King: Because this is name from content, the event that causes the name to be re-calculated is the change in style--away from "display: none"
Matt_King: When Sarah was looking at the code, she agreed that it appeared to be authored correctly
CurtBellew: That's great to know. I was really confused about this. It makes sense that the actions need this information
Matt_King: What we could do for now (unless someone ends up proving otherwise) is just assume that it's a browser bug
Matt_King: Just knowing that the code event that causes the browser to recalculate the name is when you change the "display" CSS property value
Matt_King: Okay, that clears up one thing
Matt_King: There was some feedback that I provided in there related to how the keyboard works--the left and right arrow getting back to the current option
CurtBellew: I was holding off while waiting for a resolution to the question about the name
CurtBellew: I don't know if I'll have time to look at it this week, but I should have time by next week (perhaps as early as this coming Friday)
Matt_King: From a priority standpoint, the most important thing is representing the starred state in the name of the option somehow
Matt_King: We should talk about what should happen
Matt_King: What should the screen reader experience be if you choose the "favorite" option from the actions?
CurtBellew: If we use aria-label to add "favorite", we'll wind up changing the name
Matt_King: If you favorited something, and you up and down arrow through the list, you need to know
CurtBellew: If we use a label, or if we use hidden text...
Matt_King: For a sighted user, when the buttons are not displayed, and you're just looking at the list--how is the "favorited" state shown to the user?
CurtBellew: you don't see it until you have focused
Matt_King: That seems like a shortcoming in the visual design
CurtBellew: There is a selected checkbox that we could replace
Matt_King: Yes. We're not doing multi-select in this example, so the checkbox is useless
Adam_Page: In Gmail, it has a "favorite" toggle that is always visible
CurtBellew: When you hover, the actions appear to the right.
CurtBellew: you typically see this kind of thing to the left of the text
Matt_King: Maybe emulating Gmail is not the most illustrative
Matt_King: Maybe just make a display icon on the left
Adam_Page: I agree. I like having something persistent on the left. And furthermore, having something to display the absence (rather than simply displaying nothing at all)
Matt_King: It sounds like you're suggesting that the favorite should not be an action. That it should be a visually persistent thing
Adam_Page: Can it be both?
Matt_King: It could
Adam_Page: In a lot of ways, it feels like what I'm suggesting is more like in the tabs example
Adam_Page: This is a more sophisticated design. One action is persistently visible and three others are not
CurtBellew: What would the keyboard interaction be like to designate a favorite?
Siri: When you favorite or do anything on that, when the star is hollow or filled in, it is not shown to the user anymore. Only the selected part of the listbox is shown
Matt_King: That's what we're talking about changing
Siri: I would say to show all the actions available for the selected item
Matt_King: We could make "space" and "enter" be the keyboard shortcut for the favorite, and then the other actions are accessible via the means already documented
CurtBellew: I like that idea
Matt_King: If it's favorited, you would want the icon to be part of the accessible name and not aria-hidden. But if it's not favorited, you would not want that piece of information to be part of the accessible name
CurtBellew: I've built this on top of listbox, but I should be able to make the necessary overrides to implement this behavior
Siri: If the user moves up and down with the arrows, will the user be informed via aria-live?
Matt_King: Ah, if you choose the option to move up or down
Matt_King: I agree; I think aria-live would be a good way to implement that
CurtBellew: I almost forgot about that. Thanks for the reminder, Siri!
Matt_King: I can net all of this out into a checklist of changes... But only if it will speed you up!
CurtBellew: definitely!
Matt_King: This example was really helpful in that discussion with Brett and Sarah. Even if we don't publish this before TPAC, we can always use the PR preview during TPAC.
Matt_King: I think we've worked out the things that we need to work out for this one for now. I'll make that list of changes for you, CurtBellew
Guidance on focusability of disabled controls
Issue 2318: Why does the APG advocate that disable components are keyboard reachable?
github: w3c/
Matt_King: Ideally, I would like to get to a place where we feel comfortable closing this. It's been around for some time
Matt_King: There's a lot of comments and a long history in this issue
Matt_King: The APG was saying that you should always be focusing based on the controls, but the conversation surfaced the idea that you only sometimes do this
Matt_King: But depending on what you read, it's possible to get the impression that you always do it
Matt_King: The question is, who is responsible here. Should the APG be advocating for consistency
Matt_King: In the discussion, people share examples of times when operating systems do or do not show focusable controls
Matt_King: The content of the APG is slightly more aligned with native Windows than native macOS (though there were some examples from native macOS, as well)
Matt_King: I added a final comment with a few questions from last week
Matt_King: The first was: has anything changed? As far as I can tell, the design world still doesn't have a specific answer
Matt_King: The second question is: is there any relevant research that has been conducted since 2022?
Matt_King: I offered to bring it to this group to see if anyone here has anything the can point to related to this
Matt_King: How often does this come up in internal design discussions at the companies represented here?
Matt_King: It comes up at least twice a year where I'm working
Adam_Page: It comes up fairly often for us at Hilton, too
Adam_Page: We err on the side leaving "disabled" things reachable and then using extra descriptive text describing while they are in the disabled state
CurtBellew: I see where you're coming from Adam_Page. The thing I always get hung up on is that disabled things aren't required to fulfill the minimal contrast requirements
CurtBellew: In theory, there are users who would land on these without being able to understand what it is
CurtBellew: That's part of the reason we take them out of the tab sequence
Adam_Page: That makes sense. We've had a fair amount of success in getting our designers to give disabled things much more contrast
Matt_King: Same here
Matt_King: If you're not going to disable something, then I say "hide it". If it isn't important to be perceived, then make it so no users can perceive it
Adam_Page: Plus one to that
Matt_King: If you need to be aware of the feature and how to access it, then the approach that Adam_Page described is appropriate
CurtBellew: I agree with out assessments here, but it unfortunately comes down to a case-by-case decision
Matt_King: This issue was raised because maybe it sounds like the APG is advocating too strongly in one direction, or its wording doesn't have the right tone
Siri: In one of the examples, the APG said it was okay to give focus to a non-focusable element
Matt_King: I'm wondering whether or not we should consider any revisions to the current guidance in the APG--even just in tone if not meaning
Matt_King: Or to say, "it's fine the way it is," and close unless someone outside the Task Force has a specific suggestion (in which case, they should raise an issue with that suggestion)
Matt_King: There is a section named "Developing a Keyboard Interface" in the "practices" page
Adam_Page: I'll read that and add a comment to this issue
Matt_King: thanks, Adam_Page
Matt_King: That gives us a path toward closure on this issue
Issue 3370: How should keyboard focus be handled for Tabs with aria-disabled?
github: w3c/
Matt_King: This is actually a really good question, especially for tabs with automatic activation
Matt_King: I am unclear of the use case for a disabled tab
Matt_King: If you have tabs with automatic activation, you arrow across the tab list, and the content of the tab is supposed to appear
Matt_King: If you arrow to a tab that is disabled, then it wouldn't change the content, I think
Matt_King: What would cause a tab to be enabled?
bryan: I never implement tabs that automatically open
Matt_King: But still, in that case, when would you have a tab that is disabled?
<Adam_Page> Scott O has a disabled tab example here: https://
bryan: I found that, when I didn't disable tabs, it screwed up the rendering. I was having trouble getting it to render in JAWS. It would announce "tab 1 of five", but when you arrow around, you would only perceive four tabs
bryan: There were times where a client would want to periodically disable certain tabs based on what they had available within their systems
Matt_King: It seems like you would hide them
bryan: yeah, but it was easier to disable them
Adam_Page: It comes down to whether you want a user to understand that there is a disabled tab
Adam_Page: Scott O'Hara shared an example involving a grocery store
Adam_Page: Including a tab named "mangoes - out of stock". In this situation, you would want your customers to know that you generally sell mangoes
Matt_King: It sounds like you could make that message part of the tab panel itself...
Adam_Page: That's true
Matt_King: When you make the first focusable tab receive focus, then the question becomes, "what do you do when the first focusable tab is disabled?"
Matt_King: It says that "if none are selected, then...", but that's not quite right. There should always be a selected tab in a tab set
Matt_King: It sounds like we are aligned, though, that there are cases. I'm going to review the pattern. Based on the information gathered in this meeting, I can write a response
Matt_King: I wonder if we should provide an example of a disabled tab with good contrast in the APG
CurtBellew: That sounds good
Adam_Page: I like that
Siri: Me, too
Matt_King: It doesn't seem like it would be a very big change to one of our "tabs" examples