Enhance Tabs Examples to Demonstrate Panel Focus and Scroll Considerations

[mcking65]

The examples of
Tabs With Manual Activation
and
Tabs With Automatic Activation
have identical tabpanel content.

Per discussion in March 13, 2017 meeting, Develop enhancements to the content to demonstrate:

1. Focusable panels that are scrollable.
2. Panels with interactive content where focusing on the panel is not desireable.
3. Add notes that explain rationale for deciding whether to make the panels focusable.

[ZoeBijl]

I’ll have a look at this.

[carmacleod]

Just a note to say I did some very quick testing of one of the Tabs examples with Chrome/FF and NVDA/JAWS. I modified the DOM slightly so that the tabindex="0" was not on the tabpanel, and instead was on the tabpanel descendant (happens to be a <p>, which is admittedly not a great test).

I (personally) found the Windows screen reader behavior to be slightly better when the tabpanel wasn't focusable and it's descendant was, because the user (me) would select a tab, then type the Tab key, and both screen readers announced the tabpanel's name and role and began reading the focused descendant content.

I found that when the tabpanel was focusable, typing Tab focused the tabpanel and both Windows screen readers only announced the tabpanel's name without its role. Then if I typed down arrow to read, they began reading part-way through the text, i.e. on the Joke tabpanel, the user only hears the punch line (kinda sub-optimal for a joke). It is as if the Windows screen readers don't expect the tabpanel to take focus.

I was unable to reliably test VoiceOver (in Safari or Chrome) with non-focusable tabpanels because it has odd behavior (even without my DOM modifications) where left/right arrow keys in the tablist sometimes focus the next tab, but sometimes navigate unexpectedly into the tabpanel. Ignoring the odd behavior, I did notice that since VO announces containers after reading the current element, reading a paragraph first is not the best experience because you don't know for sure that you've entered a tabpanel until the end. That behavior works best when the focused element has a short name.

This was only from quick testing on one example, however I now think that adding new types of panels to the Tabs examples is important, because it will turn up differences in behavior that we need to discuss to ensure that our guidance works well everywhere.

In addition, it would be great if we could perhaps prioritize Tabs component testing in ARIA-AT (after there's a variety of tabpanels to test with, and we've fixed whatever is occasionally messing up arrow keys in VO). We may want to take some of the differences in behavior to the AT developers, and perhaps recommend changes.

See also #323 (comment). Would be great if one of the new tabpanels contained a form, because that's fairly common tabpanel content. Consider also the following 2 items from #452:

• add support for contextmenu event on the tabs (the event works with Shift+F10 on Windows, but will have to add keyboard handling for Shift+F10 on Mac).
• add a visible close (X) "button" on the joke tab for mouse users to click on, hidden from screen readers, and not in tab order.