Meeting minutes
Setup and Review Agenda
Matt_King: Next meeting: October 28
Publication planning
Adam_Page: I checked out spin button in production, and it appears to be working as expected. I didn't leave a comment, though
arigilmore: I checked on menu, and it looks good
Matt_King: Thank you; those were the two I wanted to check on
Matt_King: I think October 29 is too aggressive for our next publication date, so I'll move it out
Matt_King: It would be nice to get it out before TPAC, but we'll see. We'll discuss it next week
Issue 3193: listbox example with aria-actions
github: w3c/
Matt_King: First of call, CurtBellew: thank you so much for the progress you've already made. It's starting to look pretty great!
Matt_King: I left a comment with some discussion items
Matt_King: The first is about what the browser is doing to name the options
Matt_King: The issue specifically said, "let's test the meaning of aria-actions=''"
Matt_King: That is supposed to communicate that actions are available
Matt_King: When you're in JAWS "forms mode", you only get one of the options. You can't get any information about the options that don't have focus
Matt_King: I don't know if this is working for items that don't have focus
CurtBellew: I was the same way. I can see it happening in the code, but I don't know how to test it
Matt_King: I just realized that I can test it with the JAWS touch cursor
Matt_King: Here's the naming problem, though: Chrome calculates the name of an option from its content (unless we apply aria-label, which we don't want to do in this case)
Matt_King: Because the HTML has the buttons at the time the page loads, Chrome is calculating the name of all of those options to include the name of all the buttons because they are in the content
CurtBellew: I wonder about looping back around and using aria-labeledby
CurtBellew: I created a test on that, but I haven't been able to reply, yet.
Matt_King: That kind of breaks the intent to determine whether Chrome is doing the right thing with the naming algorithm
Matt_King: My guess is that when we were talking about this in ARIA, that we would assume that the JavaScript would add the buttons to the element in real-time.
Matt_King: In this case, the IDs are actually there, so you could specify aria-actions with all the IDs
Matt_King: So, when we made this part of the spec (where aria-actions="" means something), my assumption was that it was supposed to support a use-case where the IDs are not available
CurtBellew: I'm not averse to that. I thought we wanted these to be basically "display: none" and then come into view when they were focused
CurtBellew: But I think it would work the same way either way
Matt_King: They are "display: none". Does that mean that Chrome has a bug?
Matt_King: If you have aria-actions specified before they are displayed... Is this an order-of-operations thing?
Matt_King: What if you just disabled the method that sets the value of aria-actions? Would you still get the names of the buttons?
Matt_King: I'm thinking that there is a bug in the name-from-content algorithm and that Chrome is leaving out the content
Siri: This is one thing I see a lot. If you use "display: none", how does the screen reader know that there are extra actions?
Matt_King: When you're in "reading mode" or a "touch cursor mode", JAWS will tell you there are actions because aria-actions=""
Siri: But they are empty until you focus on it
Matt_King: Right. When the screen reader wants to get the actions, what they're supposed to do is first focus the item, and then look at the value of aria-actions. So focusing the item is supposed to reveal the actions
Siri: The first one is none, and it doesn't have any actions.
Matt_King: JAWS has an experimental command (if you have an experimental flag enabled in Chrome) where, if you have all these conditions met, JAWS will tell you that you have actions even if the actions aren't specified, yet
Matt_King: This is an interesting thing. We don't want the name to be in...
Adam_Page: I'm looking at the preview, now, and I'm seeing that the buttons which are referenced by aria-actions are nested within the option
Adam_Page: ...that is different than my initial tabs example, where I purposely did not nest them in that way. I had to make them siblings because I was dealing with natively-focusable elements
Adam_Page: Where in this example, you are using aria-activedescendent
Matt_King: That's what Sarah had said with tree-items. It's why we have a change to the naming algorithm with aria-actions. Sarah expected that normally items would be nested like that
Adam_Page: I'm translating this to native HTML concepts in my mind, so to me, and option is focusable
CurtBellew: It was definitely a shift for me
Matt_King: Do you think we should have the buttons inside the listbox but outside the options?
Adam_Page: Yes, that cognitively makes more sense to me, and it also sidesteps the accessible name problem
Matt_King: Even though they are focusable, if they contain a group and if it's a parent tree-view item, then the parent has to contain a group which is the child nodes
Matt_King: So you're normally putting focusables inside focusables
Matt_King: It sounds like, for listbox, you're saying that it feels unnatural to place them inside the option
Adam_Page: That's right, but I trust Sarah. I should review that discussion
CurtBellew: I had the same response as Adam_Page, but I missed the discussion (I believe it was a TPAC)
Siri: I wish we had some information. It seems like these are used a lot
Matt_King: I'm noticing that with the touch cursor, JAWS is not telling me that the elements have actions, and it's also not including the names of the hidden buttons inside the names of the options
Matt_King: If I activate one of these... Now, it is including it in the name. That seems like a Chrome bug, unless again, this is a timing issue. What I did was I activated with the touch cursor, and now I have the element being selected and the name of that element (including the name of all the buttons)
Matt_King: I don't know whose bugs these are, but I think the naming thing is something that we need to figure out. What the intent of the spec is, at least
Matt_King: I wonder if aria-actions is again on the agenda this week
CurtBellew: I should be able to attend the ARIA Working Group meeting this week
CurtBellew: I could ensure the timing that you're talking about happens--that the activedescendent gets updated and that then we set the actions
Matt_King: It seems like we need to set the ID of the actions before the options are visible
CurtBellew: Ah, yes, that's what I meant
Matt_King: If you make the buttons visible, and Chrome calculates the name as a result of that, and then you add the value of aria-actions, then is Chrome going to re-calculate the name after that?
Matt_King: Maybe that's the question for the ARIA Working Group--"what is the expectation, here?"
CurtBellew: It feels like it won't recognize that the IDs exist or, as you said, it will just sort of re-calculate, and you'll get what we have, now
Matt_King: The touch cursor is also seeing all the icons--the graphics. We probably want to hide those with aria-hidden
Siri: It's reading all the names of the buttons that show up?
Matt_King: Yeah, that's one of the problem
Matt_King: It feels like it's really janky to place the buttons inside of the element
Matt_King: Maybe aria-actions="" doesn't apply in that scenario. Maybe if you're going to place the buttons inside of the element, you need to...
Adam_Page: ...have a persistent relation?
Matt_King: Maybe...
Matt_King: I really wonder about the intent. I feel a lot of confusion here
Matt_King: In the mean time, if you could place aria-hidden on those icons (just like we already use it with the "checked") icon
CurtBellew: Got it
Matt_King: What do we want to do when someone has marked something a "favorite"? I wonder if the favorite icon should be first or last within the name. It seems like it should be part of the name because it's not a state
CurtBellew: Right now, it's just using an aria-pressed, so that makes sense!
Adam_Page: This is where a relatable real-world example could be helpful. It's feeling a little contrived right now. Who's out there favoriting elements?
CurtBellew: I have a few bullet points to take care of, so I'll do that
Adam_Page: This might be a good opportunity to use text alternatives for CSS "content" in pseudo-elements
Adam_Page: It's a special syntax for the "content" property for the CSS "content" attribute
Matt_King: Adam_Page, can you make a suggestion for CurtBellew in the "files" tab of the GitHub pull request?
Adam_Page: Sure
Siri: Could you add a link to the IRC chat, as well?
Matt_King: Okay, we're out of time. Thanks everyone! We'll meet same time, same station next week