import { Badge } from 'terra-section-header/package.json?dev-site-package';
import { Notice } from '@cerner/terra-docs';
import Whitespace from "../../common/layout-helpers/Whitespace";
import AccordionSectionHeaderAccess from "./example/AccordionSectionHeaderAccess";


<Badge />

# Accessibility Guide for Terra Section Header

## Why the accessibility of Terra Section Header?

> The accessibility of Section Headers is important because headers are used on virtually every page and in every product. Section Headers convey the visual and programmatic structure and informational hierarchy of the page. The context headings provide also help users understand what to expect within the content. However, if section headers are not coded correctly or use words that accurately describe the content they represent, they can cause confusion, prevent users from understanding, and create accessibility barriers.
> 
> The code behind the headings provides context to the structure of the page and allows additional navigational methods for some assistive technology users. Improperly coded headings create accessibility barriers to these users.

## Accessibility Considerations.

### Content Considerations

- Ensure each Section Header has a meaningful label that describe the purpose of the heading.
  - Section Headers must accurately describe the content they represent.
  - Provide engineers the meaningful label that matches for each heading.
- Work with engineers to convey the structure of the page.
  - For each heading on the page, provide the engineers with an appropriate heading level to use to match the placement of the heading on the page.
- When implementing section header, do not override default theme colors of section header to ensure the Section Header be easily perceived against its background color. If changing the default colors, the text color must meet a minimum contrast ratio against the background color. See [WCAG 1.4.3 Contrast Minimum](https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html) and [1.4.11 Non-text Content](https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html) for more information.
- Do not cause any unexpected events to occur on focus or on input of any actionable controls.

### Code Considerations

> - Section Headers must programmatically have a heading level that is set to match the structure of its placement on the page. Work with the Content creators to understand what level to assign each Section Header used.
>   - Developers must apply the appropriate heading levels (1 to 6) prop to the heading. The heading level should match the hierarchical structure of the page. 
<div aria-label="Example Demo">
  <AccordionSectionHeaderAccess />
</div>
> ```jsx
> const AccordionSectionHeader = () => {
>   const [isOpen, setIsOpen] = useState(false);
> 
>   const handleClick = () => {
>     setIsOpen(!isOpen);
>   };
> 
>   const sectionHeaderProps = {
>     isOpen,
>     level: 3,
>     onClick: handleClick,
>   };
> 
>   return (
>     <div>
>       <Card>
>        <Card.Body>
>           <AccoordianExampleTemplate title="Patient is Allergic to:" heading="Documented Allergies" sectionHeaderAttrs={sectionHeaderProps}>
>             <p>Cats</p>
>             <p>Dogs</p>
>             <p>Dust</p>
>             <p>Mold</p>
>             <p>Latex</p>
>           </AccoordianExampleTemplate>
>        </Card.Body>
>       </Card>
>     </div>
>   );
> };
> ```
>   - Terra Section Headers must always follow the correct heading level order and arrangement for where it is placed within other content on the page.
>   - **IMPORTANT**: If a value to the `level` prop is not provided, default heading level will be rendered with heading `text` which would not be appropriate if level is not provided as per its placement in an application.
> - For accessibility best practices, it is recommended that consumers should always use `only one` `<h1>` per page or view. The one `<h1>` should be the page title.
>   - A section header should never be a heading level 1.
> - Do not implement any action to activate on the down event. All actions must be initiated on the up event.

## Usability Expectations:

- User expects headings to describe the content they represent.
- User does not expect to navigate to or interact with a Section Header unless it is expandable or collapsible.

## Interaction Details

- Terra Section Header, when expandable or collapsible, must be able to be accessed, interacted with, and acted upon using only the keyboard. Engineers must also ensure actional elements inside a Section Header can:
- Receive focus in the logical reading order of the user.
- Display a visible keyboard focus when the control is in focus.
- Setting a Tabindex should not be required. However, if any elements are assigned a Tabindex, it is critical that a Tabindex higher than 0 is never used.

### Keyboard Navigation

The basic keyboard navigation expectations: 

| Key/Sequence | Description |
|---|---|
|*Tab*| Moves focus on to and off an expandable/collapsible Section Header. User expects to navigate from element to interactable element User expects elements to receive focus in the logical reading order of the page. |
|*Space & Enter*| When focus is on the Section Header of a collapsed section, expands the section and vice-versa.    |

<Whitespace newline={4} />

## Support Compliance:

### Primary criteria related to Terra Section Header
- [1.3.1 Info and Relationships](https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships.html) — Supports 
  - Terra provides the ability for information, structure, and relationships to be programmatically determined. 
  - Engineers must ensure any visual relationship with a section header and other content that conveys meaning must programmatically set associations to the content for visual relationships can be understood by screen reader users.
  - Content creators should provide engineering with Section Header level to match structure within the page. Must also express to the engineer any visual relationships of a Section Header to other content for them to ensure engineers can programmatically convey the visual relationships.
- [2.4.6 Headings and Labels](https://www.w3.org/WAI/WCAG21/Understanding/headings-and-labels.html) — Supports
  - Terra provides the ability to create labels that are descriptive of their purpose. 
  - Engineers must implement meaningful text for labels to accurately describe their purpose. 
  - Content creators must ensure Section Headers and labels accurately describe the purpose of the content they represent.  
### Other accessibility criteria consuming teams are responsible for 
- [1.1.1 Non-text Content](https://www.w3.org/WAI/WCAG21/Understanding/non-text-content.html) — Supports
  - Terra provides the ability to use icons inside a Section Header.
  - Engineers must ensure appropriate alternate content is added to graphics, icons, or images that convey meaning.  
  - Content creators must provide engineers with alternate content that conveys meaning to the user. 
- [1.3.2 Meaningful Sequence](https://www.w3.org/WAI/WCAG21/Understanding/meaningful-sequence.html) - Supports
  - Terra Section Header provides the ability for components to be presented in the order in which they are coded.
  - Engineers must ensure content is meaningful and logical. If there is a visual presentation of content that is important for the user to understand, that must be available programmatically.
  - Content creator must ensure content is read in a meaningful and logical order so as to not lose context. Must also convey to the engineers any visual presentation of the use of Section Header which creates meaning in the order so that it can be programmatically understood.
- [1.4.10 Reflow](https://www.w3.org/WAI/WCAG21/Understanding/reflow.html) — Supports
  - Terra provides the ability for components to reflow when the viewport is resized to 320x256 px without loss of information or function.
  - Engineers must ensure content within Terra Section Header can reflow when the viewport is resized to 320 x 256 px without scrolling in two directions or loss of information or functionality.
  - Content creators must consider the responsive nature of Terra Section Header and provide engineers guidance on how it should content should reflow when the viewport is resized to 320 x 256 px
- [1.4.11 Non-Text Contrast](https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html) — Supports
  - Terra provides components that, by default, meet color contrast requirements. 
  - Content creators must ensure any graphical elements used within Section Header that convey information meets a 3:1 color contrast ratio.
- [1.4.3 Contrast (Minimum)](https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html) — Supports
  - Terra Section Header provides components that, by default, meet color contrast requirements.
  - Engineers must work with content creators to implement Section Header so that Section Header text color and the background color meet appropriate color contrast ratios.
  - Content creators must ensure that the Section Header text color meets the appropriate contrast ratio against background color(s) based on text size of the visual structure text. Contrast ratios should be above 4.5:1 for normal text and 3:1 for bold and large text.
- [2.1.1 Keyboard](https://www.w3.org/WAI/WCAG21/Understanding/keyboard.html) — Supports
  - Terra provides the ability for all interactable elements to receive focus, be interacted with, and be acted upon via keyboard.
  - Engineers must ensure that all interactable elements can receive focus, be interacted with, and are able to be acted upon using the keyboard.
  - Content creators must ensure that all interactable elements can receive focus, be interacted with, and are able to be acted upon using the keyboard.
- [2.4.3 Focus Order](https://www.w3.org/WAI/WCAG21/Understanding/focus-order.html) — Supports
  - Terra provides the ability for actionable components to receive focus in the order they are coded.
  - Engineers must ensure that the focus order is expected and preserves page meaning. Code order should follow the logical reading order of the user. Though a TABINDEX attribute should not be required to ensure keyboard use, if used, never use a TABINDEX value higher than 0.   
  - Content creators should convey to the engineers the logical reading order of the page.
- [2.4.7 Focus Visible](https://www.w3.org/WAI/WCAG21/Understanding/focus-visible.html) — Supports
  - Terra provides the ability for actionable elements to receive visual focus.
  - Engineers must ensure a visible keyboard focus is maintained on all interactive elements. 
  - Content creators must inform engineers that whenever Section Header receives focus, the focus must be visible and maintain existing Terra Keyboard Focus styles.
- [2.5.2 Pointer Cancellation](https://www.w3.org/WAI/WCAG21/Understanding/pointer-cancellation.html) — Supports
  - Terra components use the up event to perform actions.
  - Engineers must ensure actionable controls always take on the up event (never the down event).
- [3.2.1 On Focus](https://www.w3.org/WAI/WCAG21/Understanding/on-focus.html) — Supports 
  - Terra components do not cause a change of context on focus by default.
  - Engineers must ensure that no unexpected change of context happens when interactive elements receive focus.
  - Content creators must inform engineers that Section Header should not cause any change when an interactable control receives focus. 
- [3.2.4 Consistent Identification](https://www.w3.org/WAI/WCAG21/Understanding/consistent-identification.html) — Supports 
  - Terra provides the ability for elements to be consistently identified. 
  - Engineers must ensure that elements used for the same function are identified consistently.
  -	Content creators must ensure any icons used are used to represent the same function consistently. Additionally, the alternate content used to describe icons must be consistent for users to understand their function predictably.
- [4.1.1 Parsing](https://www.w3.org/WAI/WCAG21/Understanding/parsing.html) — Supports 
  -	Terra components are tested and validated before release to ensure proper code parsing. 
  - Engineers must ensure their code is valid HTML.
- [4.1.2 Name, Role, Value](https://www.w3.org/WAI/WCAG21/Understanding/name-role-value.html) — Supports 
  - Terra provides the ability for `Name` `Role`, and `Value` attributes to be programmatically determined so as to be read by screen readers. 
  - Engineers must ensure child elements added into Section Header have an accessible name, proper role, and value for the intended use.  
  - Content creators must provide engineers with names to appropriately identify controls added within Section Header.
### Supported Features and Technology.
- Keyboard Interactions
- JAWS Support with Chrome (PC).
- Voice Over Support with Chrome, Safari (MAC).
- Speech Input Interactions with assistive technology.
- Mobile Touch Interactions with Screen Reader assistive technology.
### Partial Support & Requiring Further Enhancement.
- [Report a problem with this component on GitHub](https://github.com/cerner/terra-core/issues/new/choose)
## References:
- [Web Content Accessibility Guidelines (WCAG) ](https://www.w3.org/WAI/WCAG21/Understanding/)
- [WebAim.org: Semantic Structure: Regions, Headings, and Lists](https://webaim.org/techniques/semanticstructure/#headings)
- [WebAim.org: Keyboard Accessibility](https://webaim.org/techniques/keyboard/)
