Condition builder: Draft Accessibility docs

[elycheea]

Draft the Accessibility docs for Condition builder

Figma file here

Write a rough draft of the Accessibility docs for Condition builder covering keyboard interactions (tab stops and selecting from the dropdown menus)
Can work with @mbgower and Jess Lin as needed.

Sections to cover:

• Page description
• What Carbon Provides
• Keyboard interactions

Reference

Accessibility docs

• Accessibility content template copy the markdown file
• Accessibility keyboard visuals
• Figma file for Accessibility keyboard visuals

Carbon components examples

• Dropdown
  • Keyboard interaction: Enter space keyboard
• Data table
  • Keyboard interaction: tab stops
• Pagination
  • Keyboard interaction
  • Labels

Page contents:

PageDescription

There are 2 stock page descriptions.
Choose the first example if designers need to include annotations in their wireframes to make the component accessible. Choose the second if the component is accessible without additional design decisions.
** If example 2 is used, the Design recommendations section and its anchor link should be removed.

Example 1:
Design annotations are needed for specific instances shown below, but for the
standard [component_name] component, Carbon already incorporates accessibility.

Example 2:
No accessibility annotations are needed for [component_name]s, but keep these considerations in
mind if you are modifying Carbon or creating a custom component.

What Carbon provides

Carbon bakes keyboard operation into its components, improving the experience of
blind users and others who operate via the keyboard. Carbon incorporates many
other accessibility considerations, some of which are described below.

Keyboard interaction

This keyboard section introduction text can give details of keyboard operation. For actionable components, begin by talking about the navigation via the tab stop, then discuss common interactions keys. For components with subcomponents, unless there is little interaction for the subcomponent, consider splitting the subcomponent considerations into a separate paragraph, separated by an illustration. Where operation is more complicated, separate headings for Keyboard navigation and Keyboard interaction can exist.Keyboard keys should be referred to with code styling.

Example 1:

Each accordion is a tab stop. Space or Enter keys expand or collapse
accordions, which are collapsed by default. Interactive elements within expanded
accordions integrate into the tab order automatically.

Example 2:
Each page link in the breadcrumb is reached by Tab and activated by Enter. The current
page, if listed in the breadcrumb, is not a link. If the breadcrumb is truncated, the ellipsis button
for the overflow menu is in the tab order. See overflow menu for details on its keyboard operation

Images
Use one image to document keyboard navigation. If the component has limited operation functionality, it may also be incorporated in the same image. Otherwise, the operation should be dealt with in a separate image.
Normally these images go across 8 columns.
images should follow the naming convention (component_name-accessibility-1.png
The ALT text text for the first image can be fairly generic, since the image is just restating information in the prior paragraph.
The caption should likewise summarize something already described in the preceding paragraph. No new information should be given in the caption. Due to technology constraints, keystroke names in the captions are not given any markdown styling.
Example:

The breadcrumb's links are reached by Tab and activated by Enter.

The (component_name) is reached by Tab and activated by Enter.

The Design recommendations section should only be included if annotations are needed

Design recommendations

Design annotations are needed for the following instances.

Some of the possible subheadings here include:

• headings
• alignment
• labeling
• meaningful order

Each should have a level 3 heading, a descriptive paragraph and a supporting image.

Example:

Headings

Carbon accordions are not set as headings by default. For improved accessibility, annotate accordions as headings on the first occurrence in a product. Annotate the heading level of accordions as needed.