Review updates to Example Page for Tabs With Manual Activation

[mcking65]

This issue tracks review of final editorial, template, and functional updates to the
Example of Tabs With Manual Activation.

Requested Reviews

• Review by @MichielBijl
• Review by @annabbott
• Review by @accdc
• Review by @shirsha

Summary of changes

1. Move examples.js script element to head and fix src attribute path so HTML source will display.
2. Make H1 content match page title.
3. Editorial revisions to introduction.
4. Correct href of link to tabs design pattern in introduction.
5. Added link to section that provides guidance on selection follows focus.
6. Per example template, Removed region around example and replaced with screen reader sepearator elements.
7. Added aria-label="Entertainment" to the tablist.
8. Added tabindex="0" to the tabpanel elements.
9. Added information about the delete function to the accessibility features section.
10. Editorial revisions to the keyboard table.
11. In roles, states and properties table:
    • added scope attribute and TH elements per template.
    • Added row for aria-label on tablist
    • Added rows for aria-selected true and false on tab
    • Added row for aria-labelledby on tabpanel
    • Added row for tabindex on tabpanel.
12. Per template, Added screen reader separators around HTML source display and removed role region from the source code display div.
13. Corrected href attribute of link to tabs design pattern in footer nav.

[ZoeBijl]

Remove delete from keyboard table since it is not supported.

Delete is supported, but only on the last tab (same as in the other example). We can mention that in the text if that’d make it clearer.

[mcking65]

I restored information about the delete function and added it to the accessibility features section. I am also editing the head comment in this issue to reflect this.

I noticed, however, that focus is not correctly set after delete so raised issue #286.

[mcking65]

@michielBijl, thank you very much for the speedy resolution of issue #286!!!!!

[ZoeBijl]

No problem @mcking65 :).

[ZoeBijl]

I noticed that design we used wasn’t usable in Windows High Contrast mode. So I’ve made a new design that does. This doesn’t impact the functionality or HTML code.

[annabbott]

When navigating the page using only the keyboard in FF, Tab keystroke activates the "Nils Frahm" tab. I expected the next Tab keystroke to exit the widget and put focus on the first link that follows the tab panel. Instead, the next Tab keystroke puts focus on the tabpanel boundary. Same behavior occurs when the "Agnes Obel" tab is activated and I press Tab key.

[mcking65]

@annabbott, focusing the tabpanel is intentional as described in the keyboard section.

This is an optional behavior. Do we need guidance to suggest when it is advisable?

[annabbott]

I don't see that moving focus to the tabpanel is "optional" nor do I see any guidance regarding when it is advisable. Both are needed.

[mcking65]

@annabbott, your concerns will be resolved at a later time with issues #322 and #323.

Still looking for feedback from @accdc and @shirsha.

[shirsha]

Looks good.
Working as per design pattern.

[accdc]

Hi, I've gone through this, and it seems to me that for a manual activation tab control there needs to be a distinction between an expanded tab versus a selected one, which this paradigm does not address.

E.G There are some instances where multiple tabs may be selected in order to perform a batch operation on all at once such as deleting 3 out of 5 tabs, which is a totally separate action from expanding one specific tab for viewing. This may be accomplished by holding down the control key while moving using the arrow keys and pressing Ctrl+Space to toggle aria-selected on the focused tab in order to toggle selection, or pressing Space or Enter by itself will expand the currently focused tab instead.

In a case such as this, then aria-selected cannot be used to indicate which tab is open, but aria-expanded must instead be used to convey this, and there needs to be an example of this within this archive if not within this specific example.

Here is an example that shows this particular difference where aria-selected is separate from aria-expanded:

http://whatsock.com/tsg/Coding%20Arena/ARIA%20and%20Non-ARIA%20Tabs/ARIA%20Tabs%20(Internal%20Content)/demo.htm

[mcking65]

@accdc commented:

It seems to me that for a manual activation tab control there needs to be a distinction between an expanded tab versus a selected one, which this paradigm does not address.

Bryan, this example follows the current tabs design pattern. The pattern does not include aria-expanded. I do not see a need for this distinction simply because the tabs are manually activated. Selection means the same thing regardless of the style of activation.

Bryan continues:

E.G There are some instances where multiple tabs may be selected in order to perform a batch operation on all at once such as deleting 3 out of 5 tabs,
which is a totally separate action from expanding one specific tab for viewing.
This may be accomplished by holding down the control key while moving using the arrow keys and pressing Ctrl+Space to toggle aria-selected on the focused tab in order to toggle selection,
or pressing Space or Enter by itself will > expand the currently focused tab instead.

Yes, A multi-select tablist that supports a variety of context actions is a slightly different animal. The design pattern currently does not cover this type of widget. We covered multi-select in tree, which is much more common than in tabs.

Bryan continues:

In a case such as this, then aria-selected cannot be used to indicate which tab is open, but aria-expanded must instead be used to convey this,

When we wrote the spec for aria-current,
we specifically dealt with this scenario. We added the following note:

NOTE
In some use cases for widgets that support aria-selected, current and selected can have different meanings and can both be used within the same set of elements.
For example, aria-current="page" can be used in a navigation tree to indicate which page is currently displayed, while aria-selected="true" indicates which page will be displayed if the user activates the treeitem.
Furthermore, the same tree may support operating on one or more selected pages (treeitems) by way of a context menu containing options such as "delete" and "move."

So, for ARIA 1.1, in a multi-select tab list that supports context actions on selected tabs, I suggest aria-current="true" be on tabs that currently have their tab panel displayed.

Bryan continues:

and there needs to be an example of this within this archive if not within this specific example.

Yes, I agree. I raised issue #341 to add aria-multiselectable and aria-current to the design pattern and issue #342 to develop an example that demonstrates this type of implementation.

[accdc]

That's fine.

From your comments there seems to be a bias to make sure that people not use aria-expanded on tabs. Why is this when aria-expanded is a supported attribute on role=tab and works across all platforms?

[mcking65]

@accdc commented:

From your comments there seems to be a bias to make sure that people not use aria-expanded on tabs. Why is this when aria-expanded is a supported attribute on role=tab and works across all platforms?

That's a really good question that we have not really discussed much.

To be sure aria-expanded is allowed, and it was the technique we had in mind during the drafting of ARIA 1.0 when thinking about using tab elements to represent accordion headers -- a technique we have since abandoned.

I am leaning toward aria-current instead because:

1. When we wrote the aria-current spec, we specifically suggested that it applies to this scenario.
2. aria-current can be used to communicate this semantic in patterns where aria-expanded has other meaning (e.g., in trees). So by using aria-current, we can create more semantic consistency across patterns.
3. It seems the semantics more closely align with what needs to be communicated.
   • aria-current: Indicates the element that represents the current item within a container or set of related elements.
   • aria-expanded: Indicates whether the element, or another grouping element it controls, is currently expanded or collapsed.

In a set of tabs, where one panel can be displayed, we are communicating which one in the set is displayed. The many other types of widgets or structures that can be used to control the content of a panel or region, such as navigation tree, menu, listbox, grid, or even static list of links could all use aria-current in the same way.

We use aria-expanded to represent the state of tree branches, submenus, disclosure panels, and accordion panels. With the exception of some accordion implementations, these "appear" and "disappear" independently -- now you see it -- now you don't. By contrast, I understand the aria-current semantic to be saying that something is always current and this is the one that is now current (or active).

This is all sort of subtle and squishy, but I think, hope, that it is clear enough that assistive technologies could one day exploit it when helping users understand a user interface.

Given the variety of interpretations of ARIA that have developed over the last 5 years, assistive technologies have understandably avoided drawing too many conclusions from ARIA. On some pages an ARIA attribute means one thing and on another page the same attribute means something else and on other pages the attribute snuck in accidentally and has no meaning at all. So, the one day I speak of may be a ways off. It's our job here to build community consensus around what that day is like and to do what we can to accelerate its arrival.

[mcking65]

As discussed in the April 10, 2017 telecon, the task force review is now complete for this example page. Closing issue.