Non-optional popup menu on Tab seems problematic

[mbgower]

A team I'm working with is trying to add secondary functionality to a tab item.
I advised them not to do that for what I thought were decent reasons:

• A tab item is fairly analogous to a menu item. It does one thing, which is to allow someone to act on the tab and update the associated tabpanel
• I don’t understand the context where additional informative material needs to be provided on the tab item itself. Such info can reside in its tab panel — it's not like activating a tab commits someone to an action; it just displays a panel
• a tab item should have a label, so the essential purpose can already be conveyed by its label
• a tab item is actionable, so putting a secondary action on it is going to create challenges — what’s the equivalent to the mouse hover for keyboard and touch users? What's the visual affordance? What's the programmatic affordance, for that matter?

It was then pointed out to me that the Aria Authoring Practices lists an associaited pop-up menu as a feature of a tab and provides a non-optional key for its activation.

Shift + F10: If the tab has an associated popup menu, opens the menu.

I'd like to understand the rationale behind that, and how the recommended implementation addresses my points and questions above.

[mbgower]

@carmacleod @mcking65 Do you have any input on this?

[scottaohara]

what was the secondary functionality? it's not uncommon for authors to want to at least add a delete function to a tab, or potentially even create a tab that can then serve as a means to invoke a 'more tabs' sub-menu or sub-tablist

[JAWS-test]

@scottaohara

it's not uncommon for authors to want to at least add a delete function to a tab

There is a separate entry and access key in the ARIA APG for deleting. This functionality is not usually hidden in a context menu, but is directly visible via the x icon and can be operated via Del or mouse click.

a tab that can then serve as a means to invoke a 'more tabs'

This is often the case, but should this element really be marked with role=tab? It would not be operable like a tab, but rather a menu button (role=button aria-haspopup=menu). In addition, the question would be how, when marked with role=tab, it is recognisable with a screen reader that a menu can be opened with Shift+F10.

or sub-tablist

I have never seen that before. Rather, nested tabs are then used. But even if I can call up sub tabs directly via a parent tab, the question would be how the Shift+F10 functionality should be perceptible with the screen reader.

I think the reference to Shift+F10 should be removed. Alternatively, the open questions should be answered in ARIA APG or possibly even shown with an example

[scottaohara]

@JAWS-test thanks, and I generally agree with you. my comments were specific in wording to comments made by @mbgower, as I was trying to get more information.

I think the reference to Shift+F10 should be removed. Alternatively, the open questions should be answered in ARIA APG or possibly even shown with an example

why? while mentioned in APG, a tab allows for an aria-haspopup. so this is at least spec related in the question of should a tab allow for this attribute. My opinion is that the attribute is necessary ... likely not for many developers making informational websites, but for complex web apps, yeh... i've seen the need for this quite a bit.

I don't think it wise of the APG to remove mention of this key combo so long as a tab can have a popup. And to be clear, APG says "If the tab has an associated pop-up menu". So, the title of this issue is not correct. It is optional to have a pop-up menu on a tab, but if there is one then Shift+F10 is the recommended keys to open it.

[JAWS-test]

@scottaohara Thank you, for the answer. I understand it now. I only see a small problem: aria-haspopup is probably mostly used for popups that can be shown directly, i.e. with left mouse click or by pressing Enter. But in the case of Tab it is now talking about a context menu, which is opened with right mouse click or Shift+F10. Elements with a context menu are usually not visually recognizable, i.e. they can only be found by trial and error. However, I wonder if a user who hears that there is a popup in Tab with screen reader will get the idea that it is a context menu. Maybe an ARIA attribute for context menus should be introduced in the future?

[tay1orjones]

what was the secondary functionality? it's not uncommon for authors to want to at least add a delete function to a tab

@scottaohara Some secondary functionality cases we're seeing in our project are for close/delete as you mention, additionally a tooltip for more info, "pinning" or "bookmarking" a tab. Some WIP specs can be seen in carbon-design-system/carbon#8487

My question through all of this is how do these things (even just a close/delete x button) reconcile with the tab role having only presentational children? My (limited) understanding is all semantic value is stripped, seeming to include any potential interactive elements?

[JAWS-test]

@tay1orjones

tab must not contain interactive elements as child elements because of implicit role=presentation. But tab may contain a context menu and this can offer the required functions. In addition, the functions can be accessed via access keys at the tab (Del for delete, Ctrl+B for bookmark etc)

I would recommend to refer to the context menu by description (e.g. aria-description), so that the functions can also be perceived with the screen reader.

The icons in the tab must not receive keyboard focus with the tab key. For sighted keyboard users, the challenge is that they have to guess that the icon functions can also be accessed via context menu.

[carmacleod]

This issue seems relevant: #1440