Request for aria-actions example with role=listbox/option

[aleventhal]

Where each option's has 1-2 inner action buttons that become visible only on focus. When the parent option is not focused, the actions are hidden but the option would still use aria-actions="" to indicate that actions are possible.

Chrome will use this example to work with the AT vendors.

[a11ydoer]

https://a11y-screenreader-demos.netlify.app/studies/secondary-actions/
https://www.w3.org/WAI/ARIA/apg/patterns/listbox/examples/listbox-scrollable/

@curtbellew

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed Issue 3193: Next aria-actions example.

The full IRC log of that discussion

<jugglinmike> Topic: Issue 3193: Next aria-actions example
<jugglinmike> github: https://github.com//issues/3193
<jugglinmike> Jem: This sounds exciting!
<jugglinmike> Matt_King: This was an issue that Aaron raised last year after TPAC
<jugglinmike> Matt_King: At that time, we had the example which Adam_Page worked on--I think it was "tabs with manual activation"
<jugglinmike> Matt_King: In the ARIA-AT group, we're beginning the work of a JAWS test plan for that pattern. I would like to share it at TPAC, but I think Aaron was requesting a different specific example because it includes some features that we can't really model in the "tabs" example
<jugglinmike> Matt_King: He's talking about adding tabs in something like a listbox or a tree--where you have buttons that appear as you navigate through the list
<jugglinmike> Matt_King: ...unlike tabs where the visibility of the buttons is commonly persistent. In this case, though, the visibility wouldn't be persistent. It could be based on hover (but gosh, how do you make that work with touch...? It's not really described here)
<jugglinmike> Matt_King: So I guess there are some things to work out in terms of how this would behave, but is there anyone who is excited to work on it?
<Adam_Page> https://a11y-screenreader-demos.netlify.app/studies/secondary-actions/
<jugglinmike> Adam_Page: Sarah put together a page of examples when she initially proposed aria-actions. None of them use aria-actions; they are just patterns that she thought aria-actions could solve
<jugglinmike> Adam_Page: I just reviewed them, though, and I don't think they relate exactly to what Aaron is describing?
<jugglinmike> Matt_King: The question is: what aspects of actions are we NOT demonstrating with the "tabs" example?
<jugglinmike> Matt_King: One, I think, is visibility, since all tabs are visible at all times
<jugglinmike> Adam_Page: If not for Aaron mentioning the listbox role specifically, I would have suggested forking the "tabs" example and add that reveal
<jugglinmike> Matt_King: Is that an authentic use, though
<jugglinmike> s/though/though?/
<jugglinmike> Adam_Page: I'm not sure
<jugglinmike> Adam_Page: Also, Gmail came to mind--that UI pattern where you bring focus to a list of things, and you want to perform some action on that list
<jugglinmike> Adam_Page: I just looked at production GMail. They do reveal actions on hover, but they do not reveal them on focus
<jugglinmike> CurtBellew: I find this interesting, but I do have some questions. I can't think of a use-case involving options in a list with actions on them
<jugglinmike> Matt_King: I've experienced this in a lot of cases
<jugglinmike> Matt_King: Mobile versions of mail are all like that--they're all some kind of list with actions that don't show when you're just looking at the list
<jugglinmike> Adam_Page: Another (maybe contrived) example that came to mind is an ordered list that allows for resorting
<jugglinmike> Matt_King: We have an example like that: the listbox with rearrange-able options. We could make an aria-actions version of that
<Jem> https://www.w3.org/WAI/ARIA/apg/patterns/listbox/examples/listbox-rearrangeable/
<jugglinmike> Matt_King: I think the simpler, the better
<jugglinmike> Matt_King: In my experience, this happens a lot
<jugglinmike> Matt_King: In 1password, you have a long list of different entries, and you can perform actions like "edit" and "delete"
<jugglinmike> Matt_King: It's like a contextual toolbar
<jugglinmike> CurtBellew: Ah, so as opposed to making a list of selections, these are actions with a list of sub-actions
<jugglinmike> Matt_King: Gmail is a grid, but we could make a much simpler list
<jugglinmike> Matt_King: The select-only combobox is "select your favorite fruit." That's a very simple list with some ready-to-go content.
<jugglinmike> Matt_King: We have a bunch of examples that provide content so we don't have to start from zero
<jugglinmike> Matt_King: What else did Sarah suggest as examples?
<jugglinmike> Adam_Page: She had trees where each tree could contain items like "files" which you could delete
<jugglinmike> Adam_Page: She had tabs, she also had listboxes
<jugglinmike> Matt_King: We have examples of both listbox and tree that are fairly straight-foward and either of which would satisfy Aaron's requirements
<jugglinmike> Matt_King: If you want to use aria-actions and just learn about the different ways of coding it, it seems to me that if you had an example of it applied to a listbox, that's sufficient. That you could use that example to figure out how to apply it to a terr
<jugglinmike> Matt_King: I think we would copy it an make a whole new example (to avoid complexity)
<Jem> https://www.w3.org/WAI/ARIA/apg/patterns/listbox/examples/listbox-grouped/
<jugglinmike> Matt_King: The "re-arrangeable options listbox" is pretty complicated in the sense that it currently has two listboxes
<jugglinmike> Adam_Page: I don't know if it's necessary for this example to have a notion of one being selected
<jugglinmike> Matt_King: We just have selection following focus because they're all single-selects
<jugglinmike> Matt_King: If it was multiple select, that feels like it could make it a lot more complicated
<jugglinmike> Matt_King: I think "scrollable listbox" is the simplest example of them all
<jugglinmike> Jem: So we would add aria-action to each option?
<jugglinmike> Adam_Page: Yes
<jugglinmike> Jem: Because it's simpler than any other pattern?
<jugglinmike> Matt_King: Yeah. I don't know we need to bring in the complexity of the other examples in order to demonstrate the essential features of aria-actions
<jugglinmike> Matt_King: The other thing that would differentiate this from "tabs" is that we would reveal each of these individually. In tabs, it would be rare to see three buttons displayed when you hover on the tab. In a listbox, on the other hand, that would almost be the norm. You would never put another click in front of the actions
<jugglinmike> Adam_Page: Agreed
<jugglinmike> Matt_King: And three actions is probably sufficient. I kind of like "remove" for one because it shows how you have to respond to destructive options in terms of focus management
<jugglinmike> Adam_Page: Right, yes
<jugglinmike> Matt_King: All of those end up don't something that is focus-management-ish
<jugglinmike> Adam_Page: Maybe we have an action like "Favorite"
<jugglinmike> Matt_King: Yeah. That could add a little "favorite" star next to it. You could favorite as many as you like
<jugglinmike> Adam_Page: At first, I was tempted to overload aria-selected, but that doesn't make sense. But when you get to a listbox, how do you want it announced? I imagine you want it worked into the name
<jugglinmike> Matt_King: Yeah, it should be part of the name
<jugglinmike> Jem: "add" button and "trash" button are typical
<jugglinmike> Matt_King: Yeah.. "move up/down", "delete/trash", and "trash"
<jugglinmike> Matt_King: One changes the content of the current item without moving focus
<jugglinmike> Matt_King: If you move up, I think you would maintain focus (just like we do in the other ones) so that way when you move up, you're able to continuing moving up
<jugglinmike> Jem: Can you just go with "edit", "trash", and "favorite"?
<jugglinmike> Jem: But maybe we're ready to decide if we want to do this
<jugglinmike> Matt_King: I'm wondering if implementing this might help move some of the aria-actions discussions forward at TPAC
<jugglinmike> CurtBellew: That makes sense.
<jugglinmike> CurtBellew: I won't be at TPAC
<jugglinmike> CurtBellew: But I can devote some resources to it before TPAC. I have some time right now (though those things can change quickly)
<jugglinmike> Jem: What other discussion is needed to make this happen? Do we want to add this for the next agenda?
<jugglinmike> Matt_King: Adam_Page's recent experience demonstrated how so much nuance is unearthed as a result of implementation
<jugglinmike> Adam_Page: Right. Touch, for instance
<jugglinmike> Matt_King: We don't have to worry about touch in the first iteration
<jugglinmike> CurtBellew: Yeah, I'd worry about that last
<jugglinmike> Matt_King: We can release without touch support and then add touch support later
<jugglinmike> Matt_King: I can cut a branch and set up the files for you, CurtBellew
<jugglinmike> CurtBellew: That would help me get started
<jugglinmike> Matt_King: I'll make a branch for you to work on
<jugglinmike> CurtBellew: Great!

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed Issue 3193: listbox example with aria-actions.

The full IRC log of that discussion

<jugglinmike> Topic: Issue 3193: listbox example with aria-actions
<jugglinmike> github: https://github.com//issues/3193
<jugglinmike> Matt_King: I created a draft pull request
<jugglinmike> Matt_King: https://github.com//pull/3372
<jugglinmike> Matt_King: The HTML page is basically complete, including proposed keyboard documentation and roles, states, and properties
<jugglinmike> Matt_King: I don't know if we can have a useful discussion of the keyboard proposal. We could wait for code from cbellew. I do have a proposal here, though.
<jugglinmike> Matt_King: This came out of TPAC discussions last year, where we're talking about "aria-actions" being set to null (or '") in certain circumstances
<jugglinmike> Matt_King: The screen reader would know that it has actions but wouldn't be able to figure out what the actions are until the element receives focus
<jugglinmike> Matt_King: This is specifically what Aaron was hoping to do
<jugglinmike> Matt_King: In the aria-actions specification, the empty string is supposed to have meaning
<jugglinmike> Matt_King: That allows you to use "display: none" for the buttons
<jugglinmike> cbellew: Ah, so you aren't referencing IDs which don't exist
<jugglinmike> Matt_King: Exactly. Or so we don't have to use some weird mechanism of making them not visible
<jugglinmike> cbellew: are there standard icons or icon libraries? Or should I just choose my own?
<jugglinmike> Matt_King: We don't have a standard set. We have some other examples which have icons which might be similar
<jugglinmike> Matt_King: Here we want move up, move down, favorite, and delete...
<jugglinmike> Matt_King: We probably have SVGs already in the repository that might represent most of those things...
<jugglinmike> cbellew: I've been looking but haven't seen anything. I'll keep searching
<jugglinmike> siri: Can you add a pattern that has disabled actions?
<jugglinmike> Matt_King: Well, in this case, you would not show disabled actions
<jugglinmike> Matt_King: But if the item is the first in the list, you can't move it up. Likewise, if it's the last item in the list, you can't move it down. But I'm assuming we wouldn't display those actions as disabled--that we would simply not display them at all