Review updates to Example Page for Tabs With Automatic Activation

[mcking65]

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

Requested Reviews

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

Summary of changes

1. Move script elements to head so HTML source will display.
2. Editorial revisions to introduction.
3. Added link to section that provides guidance on selection follows focus.
4. Per example template, Removed region around example and replaced with screen reader sepearator elements.
5. Added aria-label="Entertainment" to the tablist.
6. Added tabindex="0" to the tabpanel elements.
7. Added information about the delete function to the accessibility features section.
8. Editorial revisions to the keyboard table.
9. 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.
10. Per template, Added screen reader separators around HTML source display and removed role region from the source code display div.

[shirsha]

Where can I find the example?

Thanks,
Siri

[shirsha]

I found the example.
The link "design pattern for tabs" is not working.

[shirsha]

https://cdn.rawgit.com/w3c/aria-practices/d3caf713/examples/tabs/tabs-1/tabs.html --example

1. Aria-label is read by screen readers JAWS and NVDA only if the element has focus. Here

   that has role="tablist" has no tabindex. Therefore aria-label="Entertainment" is not read by the screen reader.

2. As per Keyboard support , this is how tab functionality should work

•     When the tab list is receiving focus, places focus on the active tab element .
  

•     When the tab list contains the focus, moves focus to the tabpanel element.
  

In this example tab list will never receive focus as it don't have tabindex as 0.

3. https://www.w3.org/TR/wai-aria-practices-1.1/#tabpanel
   Here the keyboard support is different:

• Keyboard Interaction

For the tab list:
Tab: When the tab list is receiving focus, places focus on the active tab element . When the tab list contains the focus, moves focus to the next element in the page tab sequence outside the tablist, which is typically either the first focusable element inside the tab panel or the tab panel itself.

[mcking65]

Note that The first link in the first comment in this issue, the same comment where requested reviews are listed, is a link to the page that needs review.

@shirsha wrote:

The link "design pattern for tabs" is not working.

I tested all the links; they are working for me. Specifically where is the link that is not working?

@shirsha wrote:

1. Aria-label is read by screen readers JAWS and NVDA only if the element has focus. Here
   that has role="tablist" has no tabindex. Therefore aria-label="Entertainment" is not read by the screen reader.

The tablist container should not be focusable and should not have tabindex unless we were using aria-activedescendant, which we are not.

You can consider the lack of screen reader announcement of the tablist container label a screen reader bug.

2. As per Keyboard support , this is how tab functionality should work

•     When the tab list is receiving focus, places focus on the active tab element .
  

•     When the tab list contains the focus, moves focus to the tabpanel element.
  

In this example tab list will never receive focus as it don't have tabindex as 0.

Hmm, now that you say this, I see how that wording is a little confusing and why you think the tablist should be focusable. The first phrase means that when focus is moving from outside the tablist to an element inside the tablist not that the tablist element itself is focused. The element that gets focus is the active tab.

We have phrasing like that in several places and in several patterns. I'd better fix that.

I guess I could change it to ...

"When focus is moving into the tablist: "

Would that make it more clear?

[mcking65]

@shirsha, I changed the misleading wording so that, I hope, it is now clear that the tablist element is not focusable.

[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.

[shirsha]

The "design pattern for tabs" is not at this link:
https://cdn.rawgit.com/w3c/aria-practices/d3caf713/examples/tabs/tabs-1/tabs.html

It is working fine at:
http://w3c.github.io/aria-practices/examples/tabs/tabs-1/tabs.html

[ZoeBijl]

@shirsha both seem to work fine for me.

[shirsha]

1. What is the use of separator in the Tab example?
   I found the following information at https://www.w3.org/TR/wai-aria/roles#separator
   "A divider that separates and distinguishes sections of content or groups of menuitems.
   This is a visual separator between sections of content. For example, separators are found between groups of menu items in a menu or as the moveable separator between two regions in a split pane."

In this example I don't see an visual separator or it is distinguish by the screen reader users as NVDA in FF and JAWS in IE is not recognizing that role.

2. I didn’t understand why aria-label and aria-labelledby has been used in the same div element in the following code:

Example

  It is not read by NVDA in FF browser. For JAWS in IE, it is read as “Start of” 

3. It has been more than three years the screen readers (JAWS and NVDA) are not reading aria-label if the elements are not having focus. Can you please add a text informing that aria-label is not supported by screen reader as of now for non-focusable elements?

• In virtual mode NVDA does not read it but when I tab to the first tab (Nils Frahm) then Entertainment is read along with the tab names.
• With JAWS in IE, it is not reading the aria-label at all.

Sorry for asking too many questions.
Thanks,
Siri

[mcking65]

@shirsha, per our phone conversation, the div elements with role separator are present in the code to tell screen reader users where the example begins and ends on the page. It is part of our template for examples. Today, most screen readers do not read the labels, but the separators are still useful even without the label. That problem will eventually be resolved.

BTW, we previously used regions, but the problem with that is that screen readers announce the region when you tab in and out, which creates a lot of distracting verbosity for people who are not familiar with screen readers and who are trying to focused strictly on the example.

[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!!!!! I tested and it is working as described.

[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]

In the Keyboard Support section > Delete. A space is needed between the comma and the word 'removes':
Delete When focus is on the "Joke" tab,removes the tab from the tab list and places focus on the previous tab.
Suggested edit:
Delete When focus is on the "Joke" tab, removes the tab from the tab list and places focus on the previous tab.

[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, the issue with tabpanel focus guidance will be resolved later with issue #323. The missing space typo in the keyboard table is fixed for both example pages in commit 9b3de6e.

[accdc]

This page and example looks good to me.

[mcking65]

Team, thank you! Our task force reviews for this example are complete. Another example done! Closing.