Develop tabs example with actions on each tab using aria-actions property

[mcking65]

Develop an example of the tabs pattern that illustrates how to use aria-actions to provide a actions menubutton for each tab. The actions in the menu could include actions like move left, move right, and remove.

Authoring requirements from the draft ARIA specification:

• Authors MUST ensure that elements referenced by aria-actions have an accessible name.
• Authors MUST ensure that related action elements respond to a click event and are not limited to modality-specific activation such as the keyup or touchend events.
• Authors MUST ensure each referenced action element is either directly navigable with the keyboard or that there is a keyboard shortcut to directly activate it when focus is on the referencing element.
• Authors SHOULD ensure that related actions elements are visible and activatable when the current element is focused by the user agent or assistive technology.

Design the example to resolve questions from the following issues:

• Tabs section mentions tabs with pop-up menus - any examples?  #452
• Tabs With Manual Activation example: consistency of activation Behaviour when deleting a tab #1740
• Tabs With Manual Activation example: lack of instructions/feedback for tab deletion #1813
• The tab role does not specify how it should be associated with the popup menu described in the Tabs pattern 3.24 #2247
• In regard to the Tab pattern, do we need to try to accommodate mobile screen readers? #2973

[mcking65]

Pull request #3071 provides a starting point based on the example of tabs with manual activation.

The task force is looking for a volunteer to adopt this issue and #3071 to help advance the aria-actions specification (w3c/aria#1805).

[mcking65]

How should the keyboard interface change when the action buttons are added? The ARIA specification requires that:

Authors MUST ensure each referenced action element is either directly navigable with the keyboard or that there is a keyboard shortcut to directly activate it when focus is on the referencing element.

Some possibilities (not ranked):

1. When a tab is focused, the actions menu opens with down arrow (presence of menu could be indicated by a down arrow icon). This would enable left/right to focus only the tabs.
2. The actions menu button could be focusable by down arrow and open on enter or space. In the horizontal tab strip, down arrow would navigate to both tabs and buttons but left/right would focus only the tabs.
3. Buttons and tabs are focusable by left/right.
4. When focused on a tab, the button for that tab is added to the tab sequence. No change to current arrow key nav.
5. Hijack shift+f10 when a tab is focused; this would block access to browser context menu on Windows and Linux.
6. Distinct actions for enter and space, e.g., enter selects a tab and space opens the menu.

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed Design keyboard interface for tabs with action buttons.

The full IRC log of that discussion

<jugglinmike> Topic: Design keyboard interface for tabs with action buttons
<jugglinmike> github: https://github.com//issues/3070
<jugglinmike> Matt_King: Adam Page will be joining the meeting next week, and I think he has volunteered to take this one one
<jugglinmike> Matt_King: It will be our first experimental example. It's very simple
<jugglinmike> Matt_King: Most of the authoring requirements for aria-actions are pretty straightfoward
<jugglinmike> Matt_King: One of them, though, opens a lot of questions
<jugglinmike> Matt_King: It's about the way actions are focusable
<jugglinmike> Matt_King: There are a couple ways of doing that
<jugglinmike> Matt_King: I just started brainstorming and made a list of ideas; they're available in my most recent comment on the issue
<jugglinmike> Matt_King: I don't know if there are any conventions here
<jugglinmike> CurtBellew: I don't know if we have any of these in my product
<jugglinmike> Matt_King: I know of an implementation that I don't like...
<jugglinmike> dmontalvo: I think I would prefer the first of the six points you have listed here
<jugglinmike> dmontalvo: Though, as you note, the arrow keys depend on the orientation of the tab strip
<jugglinmike> Matt_King: Option 4 might work better with a vertical tab strip, and option 1 or 2 might work better with a horizontal tab strip...
<jugglinmike> jongund: I'd like to think about this some more
<jugglinmike> CurtBellew: I'd like to think on it more, too
<jugglinmike> jugglinmike: With vertical tab lists, I wonder if the direction of the "open" action should be informed by the document's language. Maybe it makes more sense for the "left" arrow to open a menu that's presented in a left-to-right language
<jugglinmike> Matt_King: That's an interesting thought and worth considering
<jugglinmike> Matt_King: ...but we're out of time. Thanks, everyone!
<jugglinmike> Zakim, end the meeting