Add experimental example of tabs with action buttons to demonstrate aria-actions

[mcking65]

Draft PR. Looking for volunteer to complete.

Resolve #3070

Preview

Preview Experimental Example of Tabs with Action Buttons in compare branch

---

WAI Preview Link (Last built on Tue, 10 Sep 2024 23:00:12 GMT).

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed Tabs with action buttons.

The full IRC log of that discussion

<jugglinmike> Topic: Tabs with action buttons
<jugglinmike> github: https://github.com//pull/3071
<jugglinmike> Matt_King: Our very first experimental example
<jugglinmike> Matt_King: There's a preview link in the first comment on the pull request
<jugglinmike> Adam_Page_: I was excited about this because I've been following aria-actions since its early days
<jugglinmike> Adam_Page_: And because I had a use for it during my day-job at Intel a while back
<jugglinmike> s/a while back/a couple years ago/
<jugglinmike> Adam_Page_: I reviewed the issue that's attached to this pull request, and I found your exploration of six possibilties
<jugglinmike> Adam_Page_: I chose number 4 because that's the most like the one that I'd tried previously
<jugglinmike> Adam_Page_: Essentially, it was making the additional button inside the tab to be focusable only when the tab itself is focused
<jugglinmike> Adam_Page_: If you're tabbing through the page, and you arrive on the first tab, but then you hit the arrow key, you'll move focus to one of the unselected tabs
<jugglinmike> Matt_King: I think this is good for people to play with it and see what they think
<jugglinmike> Matt_King: I just like that I can arrow across the tabs and the buttons aren't in my way
<jugglinmike> Matt_King: The one thing I was thinking about when tabbing to that actions button: as a screen reader user, I hear "Carl Anderson tab action buttons menu". I was thinking that, from a labeling perspective, it might be better if it said, "Actions for Carl Anderson menu"
<jugglinmike> Matt_King: That way, I would only have to hear one word to know the element that I'm on. That would be especially helpful for long tab names, where you would have to wait a while to learn that information
<jugglinmike> Adam_Page_: That makes sense to me
<jugglinmike> Adam_Page_: Cognitively, it makes the most sense to lead with the most important piece of information
<jugglinmike> Adam_Page_: I know aria-labeledby can be dicey with localized content
<dmontalvo> q+
<jugglinmike> Adam_Page_: I'm glad that you like that you can use the arrow keys like that. That was a primary motivation for my choice of the fourth alternative
<jugglinmike> Matt_King: There was also the option of left- and right- arrows moving through the tabs and the down arrow selects
<jugglinmike> Matt_King: But I'm really curious to learn how people respond to this when they try it out
<jugglinmike> arigilmore: In Carbon, we have a similar interaction with tabs
<jugglinmike> Matt_King: So, it's already showing up in design systems working this way. That's good feedback!
<jugglinmike> Adam_Page_: I also wanted to ask how best to demonstrate the fake operations
<jugglinmike> Adam_Page_: I didn't know how far to take those kind of "mock operations"
<jugglinmike> Matt_King: I love the copy-to-clipboard one because it doesn't have to change the state of the page
<dmontalvo> q?
<jugglinmike> Matt_King: So what if we only had two actions here, since the idea is only to demonstrate that its a menu
<jugglinmike> s/its a/it's a/
<jugglinmike> Matt_King: Implementing "move" is cool, but it's a bunch of complicated code that doesn't really add demonstration value
<jugglinmike> Matt_King: The "close" one is interesting because people always ask about close e.g. where focus should go
<jugglinmike> Matt_King: So that might be a good one to do because it answers some accessibility questions
<jugglinmike> Matt_King: So maybe just "Copy" and "Close", then
<jugglinmike> dmontalvo: "Close" raises a lot of questions
<jugglinmike> Matt_King: And I'd like to answer them!
<Adam_Page_> here’s where I landed on this a couple years ago: https://adampage.github.io/a11y_tab_widget/tests/closeable-tabs.html
<jugglinmike> Matt_King: I was thinking that if you're deleting the first one, then the second one would get focus. If you're deleting the last one, you focus the one that was prior
<arigilmore> looks like carbon has similar functionality for that as well: https://react.carbondesignsystem.com/?path=/story/components-tabs--dismissable
<jugglinmike> Adam_Page_: Adding this functionality would be relatively easy if I could just modify the existing tabs JavaScript, but would you see that as polluting the existing code?
<jugglinmike> Matt_King_: I think we should make a copy for tabs-actions.js (or similar) just so we keep the simplest examples with the simplest code
<jugglinmike> arigilmore: I kind of thought the arrows just meant that, "oh I'm looking down now", so I'm wondering if an ellipsis would work
<jugglinmike> Adam_Page_: Absolutely; I was trying to re-use a design from elsewhere in the APG (the menu), but i could go either way
<jugglinmike> Adam_Page_: I might poll some of my colleagues to see if they have input because I had the same intuition as arigilmore

[adampage]

Heya @mcking65 and @ariellalgilmore, here are a few more updates. What do you think?

Just for the short term, I’ve put 3 tab set examples on the page to test 3 different scenarios:

1. “Interesting Sharks”, where each tab has 1 aria-action reference: a menu button that reveals 4 menuitem operations.
2. “Tropical Fruit”, where each tab has 2 aria-action references: 2 buttons that each perform an individual operation.
3. “Danish Composers”, a tab set with no aria-action references, to make sure the new JS still supports this simple case.

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed Tabs with action buttons.

The full IRC log of that discussion

<jugglinmike> Topic: Tabs with action buttons
<jugglinmike> github: https://github.com//pull/3071
<jugglinmike> Adam_Page: We took a preliminary look last week. Since then, I made a few changes and pushed them up
<jugglinmike> Matt_King: In your comments, you mentioned some of the different options you considered
<jugglinmike> Adam_Page: Basically, I had two motives for creating three examples. One was to test my own JavaScript for robustness and handle different scenarios. But it's also because ARIA Actions is still somewhat pending. I thought multiple examples might help move that discussion along
<jugglinmike> Adam_Page: The first example is maybe the most complex. It's a tab set where the menu button is the referenced ARIA Action
<jugglinmike> Adam_Page: Though each tab has four actions that can be performed on it
<jugglinmike> Adam_Page: The menu button is inside the tab list. Then I have a "div" element with role "presentation" that collects the tab
<jugglinmike> Matt_King: Well, a "div" element is generic by default, so it doesn't need the "presentation" role
<jugglinmike> Adam_Page: Good point
<jugglinmike> Adam_Page: In the second example, instead of having a menu item with a popover, I just stuffed two proper buttons inside each tab
<jugglinmike> Adam_Page: For ARIA Actions, that's where I'm now referencing both of those buttons
<jugglinmike> Adam_Page: For the third example, there are no ARIA Actions at all. This is just a sort of "standard" tab set. I included this to ensure that my JavaScript changes didn't interfere with the most basic use-case
<jugglinmike> Matt_King: The way I was thinking we might want to present different use cases like this (e.g. multiple actions versus a single menu button approach), I was thinking we might want to do it on different APG examples
<jugglinmike> Matt_King: ...and think a little bit about what people tend to do in the wild the most
<jugglinmike> Matt_King: I was imagining in a tab list... it's hard to imagine that people are going to stuff a lot of buttons into each tab
<jugglinmike> Matt_King: People DO actually do that with trees sometimes
<jugglinmike> Matt_King: Isn't it more likely that you're going to have a single button in a tab?
<jugglinmike> Adam_Page: Probably, yes, and it will probably by a "close" button
<jugglinmike> Matt_King: It's also very common for people to put a button at the end of tab lists which pops open a list of tabs that couldn't fit
<jugglinmike> Matt_King: In that case, though, the actions wouldn't be associated with any individual tab but rather with the tab list itself
<jugglinmike> Matt_King: I was thinking for this multiple button one, we might want to try to do that on the "file viewer tree" (or whatever it is called). I'm kind of wondering what it might look like if you had an option for "Delete", "rename" and more--right in the file tree
<jugglinmike> Matt_King: Because that seems like how people want to use it in a tree--to be able to contextually expose Actions on each individual tree item
<jugglinmike> Adam_Page: I've been thinking about Gmail
<jugglinmike> Matt_King: Well, Gmail has implemented a tree grid
<jugglinmike> Matt_King: The one I was thinking about is in VSCode, where you have the trees of Git history, or the outline of your code
<jugglinmike> Matt_King: ...and they have a toolbar next to it (though I don't know how that works visually)
<jugglinmike> Adam_Page: I'm looking at some of VSCode's tree views right now. It looks like they're doing it with persistent toolbars, but there are a number of places where they use lists of things--I need to explore their interface some more
<jugglinmike> Adam_Page: There's certainly the context menu
<jugglinmike> Matt_King: The context menu is very similar to what you made here
<jugglinmike> Adam_Page: I would say so, except there is no explicit visual affordance to know that a context menu is available. Users just have to know that it's available and how to activate it
<jugglinmike> Matt_King: There's some more exploration to do here, just in terms of making decisions of what we put forward
<jugglinmike> Matt_King: I would love it it these examples are based on things that we know people do or things that we know people want to do, just so we're sure that we're solving real problems
<jugglinmike> Matt_King: So it kind of feels like we should stick with your first example
<jugglinmike> Matt_King: If we do that, then if we take this concept of "multiple actions per focusable element" (I'd also like to do that on something like the tab container)... I just don't know how this is going to work
<jugglinmike> Adam_Page: The "overflow" use case you mentioned earlier is interesting to me because the tab list is not traditionally a focusable element
<jugglinmike> Matt_King: We have a separate issue for that. I could bring it up and we could maybe address that issue as well
<jugglinmike> Matt_King: What you said about the way VSCode works, where only the active tab has a "close" button on it, do you think that might work for another example with the overflow, where we put a "close" button on each tab which would only be visible on focus...?
<jugglinmike> Adam_Page: I misspoke about that; the tab doesn't have to be active for the button to be visible
<jugglinmike> Matt_King: What do you think of, for this pull request, doing what you have in the first one?
<jugglinmike> Adam_Page: That sounds great. I think the second example could be adapted in the direction of what you're talking about. It could have just the "close" button, and we might extend it to demonstrate the "overflow" case
<jugglinmike> Adam_Page: That feels like it transcends ARIA Actions and starts to re-think what a tab-list could actually contain
<jugglinmike> Matt_King: I think ARIA Actions is supposed to handle this case, too
<jugglinmike> Bryan_Garaventa: If you're including the buttons inside the tab, what does that mean for the accessible name of the tab?
<jugglinmike> Adam_Page: Well, the parent-child relationship is only suggested visually in that case. In the actual structure of the document, the tab and buttons are siblings
<jugglinmike> Matt_King: This will be on the agenda at TPAC!
<jugglinmike> Matt_King: So we made a decision: Adam_Page is going with the first one and pulling out the other two. I'll share a link to the existing issue about the "overflow" scenario
<jugglinmike> Zakim, end the meeting

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed Tabs with action buttons.

The full IRC log of that discussion

<jugglinmike> Topic: Tabs with action buttons
<jugglinmike> github: https://github.com//pull/3071
<Daniel> s/Remi/Rémi/
<jugglinmike> s/Remi/Rémi/
<jugglinmike> Adam_Page: I made three examples on the one page, and I removed two as we discussed in the previous meeting
<jugglinmike> Adam_Page: I had put "presentation=role" on the tab wrapper to contain the tab and the button, but since it was just a "div" element, that wasn't necessary. So I removed it
<jugglinmike> Matt_King: We don't have any documentation in the tables down below about ARIA actions or about the keyboard interaction changes
<jugglinmike> Matt_King: That's something I can add
<jugglinmike> Matt_King: Under "keyboard support", currently we have the "tab" key documented. That one would need to be changed
<jugglinmike> Matt_King: When you press the "tab" key on the selected tab, you would get to the actions menu button...
<jugglinmike> Matt_King: If you're tabbing backward, that's the only time this distinction matters
<jugglinmike> Matt_King: But we don't have "shift+tab" documented in this table, so I would have to add a row to document "shift+tab"
<jugglinmike> Matt_King: None of the others--left, home--they're not affected
<jugglinmike> Matt_King: Is that it for keyboard documentation?
<jugglinmike> Matt_King: I don't think we need to document the keyboard interaction for the menu itself. I wonder if I should add a reference to the "menu" page
<jugglinmike> Adam_Page: That's what I was thinking
<jugglinmike> Matt_King: Then for "roles, states, and properties", the only new property is "aria-actions". I think that would be the only change to that table
<jugglinmike> Adam_Page: I think you're right
<jugglinmike> Matt_King: Do you have any time to add any of that yourself before some time tomorrow?
<jugglinmike> Adam_Page: I think so. Can you give me a deadline?
<jugglinmike> howard-e: I will make the pull request on Thursday morning
<jugglinmike> Matt_King: Then a good deadline for Adam_Page would be 17:00 PT tomorrow
<jugglinmike> Adam_Page: That works for me
<jugglinmike> howard-e: Just to confirm: I usually make the pull requests on Thursday by 13:00 ET, which I believe is 10:00 PT
<jugglinmike> Adam_Page: I have linting errors in the pull request; can we take a look at those?
<jugglinmike> Adam_Page: It seemed like linting was set up to run on my local environment, so I'm not sure why they passed on my machine but that the CI tests are failing
<jugglinmike> howard-e: It mentions aria-actions...
<jugglinmike> Matt_King: Ah. We have a set of lint exceptions for HTML that are related to either bugs in the HTML linter or new things like this
<jugglinmike> Matt_King: This hasn't been picked up yet--it doesn't know what's valid or not because the spec isn't final
<jugglinmike> Matt_King: I think we need to modify the .vnu.rc file
<jugglinmike> howard-e: Right; the line you would add there is whatever follows the "error:" in the error message itself
<jugglinmike> howard-e: This is something you can do in your pull request, Adam_Page
<jugglinmike> s/.vnu.rc/.vnurc/
<jugglinmike> howard-e: There's also some spell check errors here. You'd add those to the "cspell.json" file in the root of the project. It's an object; you just add the words to the root of that object
<jugglinmike> Adam_Page: I should be able to take care of this, no problem. If I have any trouble, I'll ping you folks
<jugglinmike> Adam_Page: I shared the deployment preview with a colleague. He tried to use the CodePen and found that it was broken. Is that a problem for now?
<jugglinmike> Matt_King: We could merge with it broken since this is experimental and not many people will see it...
<jugglinmike> Matt_King: But why isn't it working?
<jugglinmike> Adam_Page: I think that because I am setting a new precedent with this example--the example uses the code from another example (the menu pattern's JavaScript and CSS)
<jugglinmike> Matt_King: I think we've often copied them for that reason, even though doing so creates redundancy
<jugglinmike> Adam_Page: For what it's worth, the code pen works somewhat; the tab functionality is there--it is just rendered incorrectly and it doesn't have any functionality of the menu
<jugglinmike> Matt_King: While it might seem more efficient to not duplicate the code; I think it makes sense to copy here to keep the example self-contained
<jugglinmike> Matt_King: We do have some shared JavaScript, but that's mostly related to the template for the page itself rather than the example it's demonstrating
<jugglinmike> Adam_Page: Understood. I'll go ahead and just copy those files into the directory for the tabs
<jugglinmike> Matt_King: Great!
<jugglinmike> Matt_King: Does anybody else have feedback on this pull request?
<jugglinmike> Matt_King: Remember that it is experimental, so we expect to continue gathering feedback over time
<jugglinmike> Matt_King: Hearing none, we'll move forward with just the fixes we've identified today
<jugglinmike> Matt_King: Thank you, Adam_Page

[adampage]

Hi @mcking65, I’ve just pushed up all the changes we chatted about in today’s APG meeting:

• Fixes for the linting errors
• Updates to the keyboard support section
• aria-actions added to the attributes section
• Fix for the Codepen integration

For the Codepen issue, I discovered that that the transmitted source code is actually governed by this JavaScript and CSS Source Code section toward the bottom of the page. I updated the file list there and included a cross-reference to the menu button Javascript; cloning that file turned out to be unnecessary. Everything now appears to work correctly for both the Codepen and the running example on the APG page itself.

Please have a look and let me know what you think?

[mcking65]

@adampage Fantastic! Thank you!!!