Tabs pattern needs to say whether tabpanel should take focus

[carmacleod]

This issue was raised during discussion of pull #1120.
The tabpanel in the tabbed carousel example has tabindex="0", which seems like an unnecessary tab stop. The Tabs Pattern doesn't say whether the tabindex is optional or required. One reason to make it required would be so that the experience is consistent across tabpanels. Another would be to ensure that non-interactive child content is read.

[JAWS-test]

https://raw.githack.com/w3c/aria-practices/issue955-add-tabbed-carousel-example/examples/carousel/carousel-2-tablist.html#

In my opinion, in the example 2 tab steps are too much: on the tabpanel and on the link around the graphic. The purpose of the link is not obvious (violation of WCAG 2.4.4).
When testing with Chrome and JAWS 2019, the role "Link" is output on the tabpanel at the tabstep.
In IE 11 there are a lot of invisible and unnecessary tabs because the SVG graphics are not marked with focusable=false.

[JAWS-test]

To be able to read the contents of the tabpanel:
I think Heydon Pickering's idea is great:
"In the operation of screen readers like NVDA and JAWS, the down arrow moves the user to the next element (focusable or otherwise) and reads it out. Without intervention, this would be the next tab in the tablist. Instead, we can intercept the down arrow key press and move focus programmatically to the open panel itself, making sure it isn't missed" (https://inclusive-components.design/tabbed-interfaces/). Would be good if that were integrated into the APG examples

[mcking65]

@JAWS-test commented:

To be able to read the contents of the tabpanel:
I think Heydon Pickering's idea is great:
"In the operation of screen readers like NVDA and JAWS, the down arrow moves the user to the next element (focusable or otherwise) and reads it out. Without intervention, this would be the next tab in the tablist. Instead, we can intercept the down arrow key press and move focus programmatically to the open panel itself, making sure it isn't missed" (https://inclusive-components.design/tabbed-interfaces/). Would be good if that were integrated into the APG examples

That's a creative idea. However, as a screen reader user, I'm not convinced it is one we would want to add to the pattern.

The up/down behavior Heydon describes for JAWS and NVDA is the behavior in reading mode, not forms or focus mode. When in forms mode, the user can't read the tab panel, so giving it focus isn't helpful. One way of solving that would be to convince the screen reader developers to auto-switch to reading mode when the panel gets focus, regardless of the mechanism for giving it focus. Today, tabbing out of a tablist will typically switch modes if the element receiving focus is not a widget.

The nice thing about tabbing is that it is reversable. Down arrow would not be reversable if the user was surprised by the destination.

Getting the right mode switching in place, however, would not fix the discoverability problem. This behavior is not part of native tabs. So we would also neet to get the screen readers to tell the user about this feature. The biggest difficulty I see there is that the screen reader would need to have a way of knowing whether or not this feature exists on the page. As of now, we do not have a way of communicating that. This is the kind of thing that could be communicated with control patterns, which is something we have on the roadmap for ARIA 2.0. In the mean time, I don't see a good way of doing this.

Another challenge is that we explicitly removed the ability to move the focus in the horizontal tablist with up/down. We received feedback that we should not take away the browser scroll features when focus is in the tab list. That is not a nice thing to do to sighted keyboard users. This, then, sets up a conflict between two different user cohorts. If we take over down arrow for moving focus to the tabpanel, we take scrolling down away from other users.

That is similar to tabbing to the tabpanel. It is nice for screen reader users but an inconvenient extra tab stop for sighted keyboard users. Nevertheless, in Tuesday's meeting, the consensus was this is a worthwhile trade off. The group was leaning toard recommending consistently focusing the tabpanel rather than only when there is no interactive content at the top of the tabpanel. There are multiple difficulties introduced by conditional behaviors of that nature.

[mcking65]

@JAWS-test commented:

https://raw.githack.com/w3c/aria-practices/issue955-add-tabbed-carousel-example/examples/carousel/carousel-2-tablist.html#

In my opinion, in the example 2 tab steps are too much: on the tabpanel and on the link around the graphic. The purpose of the link is not obvious (violation of WCAG 2.4.4).

I am unclear of the rationale for saying there is a WCAG violation. However, please add your comment and explanation to the relevant line in the PR. Please do not respond here.

[JAWS-test]

I understood Heydon's idea differently: The screenreader remains in form mode with arrow-down, but focus is set to the tabpanel via JavaScript and automatically then the screenreader exits form mode. I liked the idea, but if there are conflicts with other user needs, of course it doesn't work.

[JAWS-test]

However, please add your comment and explanation to the relevant line in the PR. Please do not respond here.

The question was whether the focus had to be on the tab panel by Tab key. I say: No, because in the example there is no content in the tabpanel except for the link that gets the focus anyway. Whether the other tab steps are useful or superfluous is hard for me to decide, because the links currently only contain a # in the href. But I can hardly imagine that the link around the graphic has a different link target than the link inside the graphic. So we probably have 2 links with the same destination and different labels. Unnecessary and confusing

[ZoeBijl]

The question was whether the focus had to be on the tab panel by Tab key. I say: No, because in the example there is no content in the tabpanel except for the link that gets the focus anyway.

I agree with this. This is similar to how a cell in a grid doesn’t get focus when there’s a focusable widget (such as a link) inside of it.

[mcking65]

PR #1274 proposes to resolve this issue with the following description of the Tab key in the keyboard interaction section of the Tabs Pattern:

Tab :

• When focus moves into the tab list, 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 the tabpanel unless the first element containing meaningful content inside the tabpanel is focusable.