[Table of contents] Accessibility review

[RichKummer]

For v2 we need to review the accessibility of table of contents with an accessibility SME. Some questions:

• Is the focus trap working?
• Is it focusing in the proper order?
• Is it tabbable in a clear way?

Vertical:

• implementation
  • keyboard user perspective

Horizontal:

• Does the styling of the horizontal ToC conflict with Carbon tabs default or contained styling?
• implementation
  • keyboard user perspective

Determine:

• any required changes from a11y team
• if no changes: documentation on website ++ reasons for using each variant and component recommendations (ie not to use tabs with horizontal ToC?)

Tasks

• Set up review with Gower
• Get on accessibility guild agenda
• document review and any changes required

Resources

• Vertical design specs
• Horizontal design specs
• Web components
• React
• Example pages:
  • Vertical
  • Horizontal

Acceptance criteria

• Review with accessibility SME
• Explore any updates
• Review with Jeannie, Olivia, and Rich
• Update design specs
• Create Figma kit story, if needed
• Create website update story, if needed
• Create dev story

[oliviaflory]

A11y Review Mar 20 Notes

General

• The ToC is primarily there to orient the user where they are on the page
• What is the expected mouse & keyboard behavior for Table of Contents
• Would be easier if the ToC was not interactive

Vertical

• Not a failure as-is
  Suggestion:
• Change the Vertical toc to a navigation region
  • Lets you jump back to ToC
  • Focus would be on the item when you jump back into the region.
  • Execute and focus is shifted into section,
  • User can jump back into the navigation region.

Horizontal

• Not a failure, but not an ideal experience and would not promote this design
• Looks like a tab panel, so could confuse the user

Tab panel

• Exclusive information

Content switcher

• Changing/filtering information

ToC

• Re-positioning on the page
• Not necessarily a failure
• Doesn’t follow expected behavior conventions
• LOTs of inconsistencies throughout dotcom (older component libraries or older versions of C4IBM)
• Keyboard accessibility isn’t great
  • Either brings into view with no keyboard focus in the new section
  • Reading/focus order is a bit weird
  • Usability effects a person with a disability
  • Would not celebrate this design
• Don’t promote this interaction
  • Would prefer to NOT have

Explore alternatives for Horizontal:

• Non-persistant version
• Interaction problem with the horizontal –– most people would not understand it is not a tab panel.

[oliviaflory]

Additional notes from Michael G:

Tables of contents (TOCs)

TOCs provide a few different functions.

1. The first it to provide the user with the outline of the content (provide context).
2. The second is to orient the user to their current position in a long document (which happens by the ‘current’ TOCs item being indicated visually-- and hopefully programmatically).
3. The third is to provide a means of interacting/navigating to TOCs entries. For this, the user activates an entry, which re-orients the user to that location in the same large content. We discussed whether focus should remain in the TOC after activitation or move with the viewport re-orientation. Conclusion was that it was much better for the keyboard interaction (focus) to match the repositioning of the content in the viewport. It is not necessary for a focus indicator to appear around the heading that ‘has focus’; but providing each TOC entry with a tabindex=“-1” and then programmatically putting the focus there after activiation is desirable.

Horizontal TOCs need some disambiguation with tablists. But there are clear differences in navigation and interaction

1. For the tablist, the entire tabpanel is updated when a tabitem is activated. Focus does not move from the tablist on activation,BUT pressing Tab once should move the user to either the entire tabpanel, or to the first item with focus in the tabpanel.
2. Unlike a tabpanel, activating a TOC item does not alter/replace content on the page; it simply repositions the user.
3. Also unlike a tabpanel, the focus does not stay in the TOC when activated. It repositions to the top of the content in the main viewing area (as discussed under 1c above).
4. One possible way of disambiguating the two constructs is to handle the focus interaction and visual cueing on the whole component (the tablist takes a single tab stop and is navigated by arrow keys; the TOC is a series of individual tabstops)
5. There is SOME possibility of consideration a TOC as a continuum between tabpanels, content switches and TOCs; however, we did not explore this at all.
6. A simple solution is to not allow horizontal TOCs (they were offered to appease the Drupal, and their main advantage is that it does not take up horizontal space)
7. Discussed a potential to do a dropdown TOC which may be easier to differentiate
8. Discussed the idea of not ‘deprecating’ but not promoting it.

ACTION:

Determine what options we have to prioritize work (not just for TOC but for any component). Is it tactically valid to de-prioritize one thing as well as prioritize something else for remediation?