Accessibility

Existing Pattern for reference - https://www.toronto.ca/explore-enjoy/parks-gardens-beaches/toronto-island-park/

User stories

• As a screen reader user, I want to be informed about the tab component and be able to access its contents.
• As a keyboard user I want to be able to control and access the tabs interface with logical keyboard commands

Acceptance Considerations+Criteria

• Screen reader should announce the number of tabs when user begins interacting with the component.
• Each tab should be announced as it receives focus.
• Keyboard user can select tabs with arrow keys
• Keyboard user can directly access tab panel content for currently selected tab using the Tab key
• Currently selected tab is indicated visually (active state style) and programmatically (aria-current attribute), and announced by screen reader
• Only the content for the currently selected (visible) tab panel can be accessed by screen reader

Keyboard interaction

Keyboard interactions to follow WAI-ARIA authoring practices 1.1 (example):

For the tab list:

• 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 typically either the first focusable element inside the tab panel or the tab panel itself.
• When focus is on a tab element in a horizontal tab list:
  • Left Arrow: moves focus to the previous tab. If focus is on the first tab, moves focus to the last tab.
  • Right Arrow: Moves focus to the next tab. If focus is on the last tab element, moves focus to the first tab.
• When focus is on a tab in a tablist with either horizontal or vertical orientation:
  • Space or Enter: Activates the tab

  • Home (Optional): Moves focus to the first tab.

  • End (Optional): Moves focus to the last tab.
• If the tabs in a tab list are arranged vertically:
  • Down Arrow performs as Right Arrow is described above.
  • Up Arrow performs as Left Arrow is described above.
• If the tab list is horizontal, it does not listen for Down Arrow or Up Arrow so those keys can provide their normal browser scrolling functions even when focus is inside the tab list.

Notes:

• The above interactions make note of a potential vertical tab alignment, if the proposed design does not account for or allow this alignment then these interaction points should be removed
• We must decide if we are going to include the optional ARIA interactions. If we are, remove the "(optional)" if we are not then remove them from the criteria.

For the tabpanel:

• Activating a tab places focus on the associated tabpanel element 

WAI-ARIA Roles, States, and Properties

• The element that serves as the container for the set of tabs has role tablist.
• Each element that serves as a tab has role tab and is contained within the element with role tablist.
• Each element that contains the content panel for a tab has role tabpanel.
• If the tab list has a visible label, the element with role tablist has aria-labelledby set to a value that refers to the labeling element. Otherwise, the tablist element has a label provided by aria-label.
• Each element with role tab has the property aria-controls referring to its associated tabpanel element.
• The active tab element has the state aria-selected set to true and all other tab elements have it set to false.
• Each element with role tabpanel has the property aria-labelledby referring to its associated tab element.
• If the tablist element is vertically oriented, it has the property aria-orientation set to vertical. The default value of aria-orientation for a tablist element is horizontal.

Note: Mentions of a vertical tab alignment, should be removed if the proposed design does not account for or allow this.