Tabs section mentions tabs with pop-up menus - any examples?

[patrickhlauke]

The tabs section https://www.w3.org/TR/wai-aria-practices-1.1/#tabpanel mentions, quite in passing, tabs with pop-up menus ... under keyboard interactions

Shift + F10: If the tab has an associated pop-up menu, opens the menu.

and again under WAI-ARIA Roles, States, and Properties

If a tab element has a pop-up menu, it has the property aria-haspopup set to true.

However, no examples are provided. I don't recall ever encountering tabbed interfaces of this kind, so a clear working example would be helpful.

[patrickhlauke]

By "popup-menu" do you mean something akin to a "context menu", rather than something like a dropdown that shows sub-tabs or something?

[ZoeBijl]

Would be interested in this too. Perhaps @jnurthen knows? Isn’t Shift + F10 the default shortcut to open context menus?

For what it’s worth, the pattern should also explain how a touch screen user accesses this menu, but that’s a different story…

[patrickhlauke]

yeah on reading it more thoroughly, it does hint towards context menus.

for touch, firing the context menu there is usually achieved with a long-press. would probably require a whole new "pointer behavior" section to match "keyboard behavior" throughout the document...

[devarshipant]

If a tab element has a pop-up menu, it has the property aria-haspopup set to true.

I don't think it even needs to be there.

When an arrow key sets focus on an element with role = tab, the DIV with role = tabpanel becomes active, which means it (i.e. element with role tab) is not a candidate for aria-haspopup.

Also, note the role tab may not even support aria-haspopup -- http://www.w3.org/TR/wai-aria-1.1/#tab.

Example -- https://assets.cms.gov/resources/framework/2.0/Pages/tabs.html

[ZoeBijl]

According to ARIA in HTML the tab role doesn’t support aria-haspopup. That’s not necessarily an issue as that can be changed. However, we should see if the popup feature is something that actually happens in real life.

I think @StommePoes worked on something like this.

---

Also, focus remains on the element with role=tab after activation. The tabpanel isn’t automatically focused. It could even be something that’s limited to the Tabs with manual activation although I don’t necessarily see why.

[patrickhlauke]

on the same topic, would be interested in this - tabs that can be deleted...

Delete (Optional): If deletion is allowed, deletes (closes) the current tab element and its associated tab panel. If any tabs remain, sets focus to the tab following the tab that was closed and activates the newly focused tab. Alternatively, or in addition, the delete function is available in a context menu

[ZoeBijl]

@patrickhlauke that’s actually implemented in the APG tabs example; you can delete the last tab when it has focus.

[patrickhlauke]

not very obvious, and seems to be a functionality that can exclusively be triggered through keyboard. would be best to make a far more explicit example, which also provides mouse/touch capability to do same

[ZoeBijl]

Agreed. Any ideas as to what that might look like? Oracle’s JET has an implementation with delete buttons. Something like that could work.

[mcking65]

Yes, what is meant by this in the pattern is a context menu. I could change the wording accordingly if people think that would be more clear. I would first want to look across other patterns to see what words are used.

The standard key for context menus is shift+f10 and on mobile this is often long press.

Context menus typically provide functions like renaming, reordering, deleting, and adding tabs.

The ARIA in HTML doesn'define which props are valid for aria roles; that is defined by ARIA. The aria in html is only listing explicitly supported props; haspopup is global so is valid on any element.

@patrickhlauke, Would you like for us to morf this issue into an enhancement request? Or, leave it as a question and close?

[ZoeBijl]

@mcking65 I stand correct, thanks 👍.

• Add touch support for deletion of tabs

[StommePoes]

Our designers (who don't really know what a tab is or how they work, they just look at Material Design and call "tabs" whatever Google calls "tabs") wanted, for a responsive view (as the viewport collapses) a tab panel where one of the tabs becomes a "more" thing with a "dropdown" which contains what would have been the other tabs. Meaning if there's a 7-tab tab-panel, and the viewport has room for only 4, we get the first three tabs and the fourth becomes this "more" under which the other tabs can be found. They also wanted the tab order to change so that the current tab is one of the visible tabs (so if you're focussed on the last tab, it gets shuffled to be one of the first tabs so that it's visible and not under the "more" tab).

Since I could find no sane way to do this (and rearranging tab orders based on media queries seems quite wrong to me, since I'm constantly zooming into sites to read them and then zooming out so I can use them, and this triggering media queries and getting mobile views quite often), I just told them we should not build something like this.
But it continues to be asked and people will continue to build things that look something like this and since I wouldn't do it, I think they're just going to copy whatever Material Design does and use that anyway. The pattern is quite common for horizontal rows of site navigation (which are just an unordered list of links) for dealing with responsive views, but I can't see that same solution working for tab panels. Due to the prevalence of SPAs (basically all our tabs are changing "pages" as they're changing "views" but then only within the "pane"), it kinda makes some sense that designers stop seeing any difference between a row of tabs and a row of links.

[devarshipant]

@MichielBijl -- nice example of the delete feature in http://www.w3.org/TR/wai-aria-practices-1.1/examples/tabs/tabs-1/tabs.html, but it uses the conventional delete key. I was under the impression that shift F10 would get me delete as one of the options to select :)

For desktop users -- the use of context menu is not clear when the long press use is cited. Perhaps, the request should be modified.

Sidebar request -- users would find rearranging / reordering tabs helpful as well.

[carmacleod]

New location for the Oracle JET "Tab Bar with removable tabs" example mentioned by @MichielBijl.

It's quite nice. It uses "Roving tabindex" to move focus from tab to tab when user types arrow keys, and
it supports the Shift+F10 context menu on each tab (only has "Remove" on the menu, but one could imagine having "Move before" and "Move after" as well, and they do have a different example for Reorder).

It also supports Delete key on the focused tab. (Note that there's a bug using Delete key. I opened an issue... hope it's in the right place).

It uses the "Manual activation" technique (so focused tab is not necessarily selected), but one could imagine a context menu and delete key working on the selected tab for "Automatic selection" tabs as well.

For mouse, and presumably for touch as well?, it has an "x" (aka "Close") icon (an anchor) with tabindex="-1" role="presentation" aria-hidden="true" aria-label="Removable" (they really want to hide it from AT 😄). Since the "Remove" feature is available 2 other ways (Delete key and context menu) I guess that's ok.

As a sighted user navigating through these, the "x" gives a visual affordance that the tabs can be removed, so I would likely try Shift+F10 and/or Delete, but I also wonder if it makes sense to allow the "x" within the focused tab to take focus. i.e. Type arrows to focus a particular tab, then Tab key goes to its "x" button, where Space or Enter will remove the tab. Typing Tab twice would go to the tabfolder content. Anyone have thoughts on whether allowing the current "x" to take focus would work intuitively for all users?

[patrickhlauke]

For mouse, and presumably for touch as well?, it has an "x" (aka "Close") icon (an anchor) with tabindex="-1" role="presentation" aria-hidden="true" aria-label="Removable" (they really want to hide it from AT 😄). Since the "Remove" feature is available 2 other ways (Delete key and context menu) I guess that's ok.

Randomly revisiting this and thinking: what about switch access users? they navigate with a keyboard-like interface, true, but they still mostly rely on things that get focus (unless doing the visual scan type navigation). i think this user group is usually best served by having something that can indeed get focus. and to AT users I suspect, unless they're told by instructions, it'd be unusual to think that hitting Del would remove the tab they're on altogether (or that there'd be a context menu present). having an actual explicitly focusable extra control would be good - but that would obviously break the fairly rigid expected structure of a tablist/tab.

[patrickhlauke]

New location for the Oracle JET "Tab Bar with removable tabs" example mentioned by @MichielBijl.

as @stevefaulkner just mentioned to me, that example, as nice as it is, doesn't work in iOS/VO as VO simply ignores the "X" remove controls (probably due to VO bug that skips "empty" elements, even if they have an aria-label etc)

[stevefaulkner]

@patrickhlauke the close button is outside the role=tab:

<a href="#" role="tab" class="oj-tabbar-focused-element oj-tabbar-item-content oj-tabbar-item-no-icon" aria-selected="false" aria-describedby="ui-id-11" tabindex="-1"><span class="oj-tabbar-item-label">
          <!--oj-bind-text value='[[item.data.name]]'--><!--ko text:item.data.name-->Tools<!--/ko--><!--/oj-bind-text-->
        </span></a>

button for tab

<a class="oj-tabbar-remove-icon oj-clickable-icon-nocontext oj-component-icon" aria-label="Removable" role="presentation" aria-hidden="true" id="ui-id-11"></a>

[patrickhlauke]

well regardless of where it is, it's currently borked anyway - hidden, has a presentation role, effectively empty (content generated via CSS), and has aria-label ... not the best combination to make it announceable by AT (assume the intention here is that AT users never "need" this control either as they'll hit "del" on their keyboard, which then of course won't work for touch/AT users or voice control users