We believe accessibility is a core requirement and not an optional feature. Our approach to accessibility closely aligns with our HashiCorp principles, such as our core principle of integrity.
Integrity requires a consistency of our thoughts, words, and actions and a dedication to the truth.
Because we build the Helios Design System with accessibility as a core requirement, we’re giving HashiCorp product designers and engineers a greater ability to deliver accessible product experiences for all HashiCorp users.
Ensuring accessible outcomes
Because we’re firm in our commitment to accessibility, we take practical steps to ensure our outcomes are accessible. This means that we integrate accessibility at every step of our creation cycle. In addition to formalizing our commitment to WCAG 2.1 AA conformance with an internal policy, we take the following actionable steps:
- Provide education and training for our team.
- Design with accessibility as a core requirement.
- Conduct design reviews specifically focused on accessibility.
- Ensure our code renders to the browser in a conformant way.
- Use available accessibility automation (through ember-template-lint and ember-a11y-testing).
- Manually test our code with assistive technologies.
We intend to be compatible with the following assistive technologies:
- Safari with VoiceOver on macOS
- Chrome with JAWS on Windows
- Firefox with JAWS and NVDA on Windows
The Web Content Accessibility Guidelines (WCAG) define requirements for designers and engineers to improve accessibility for people with disabilities. It defines three levels of conformance: Level A, Level AA, and Level AAA. Helios intends to be fully conformant with WCAG 2.1 Level AA. Fully conformant means that the content fully conforms to the accessibility standard.
Limitations and alternatives
Despite our best efforts to ensure accessibility of Helios, there may be some limitations.
If we can’t provide conformance through the component, we’ll provide documentation for implementing an equivalent experience. We outline other accessibility-related exceptions and considerations and provide the relevant WCAG Success Criteria within each component’s documentation.
- Breadcrumb component: keyboard-only users may be unable to access truncated data. This occurs due to a combination of user-provided content and browser-based technical limitations. We encourage teams to refactor the design if it includes truncated data.
- Card component: this component has
overflow:hiddenapplied to contain content by default. Consumers must self-edit content to conform to the available space, as truncated content is unavailable to keyboard-only users.
The Design Systems Team self-assesses the accessibility of Helios by the following approaches:
- Manual testing with assistive technologies
- Use of available automated checks
We welcome your feedback on the accessibility of Helios. Please let us know if you encounter accessibility barriers in the design system:
- GitHub: file an issue on the design-systems repository
- E-mail: firstname.lastname@example.org
We are committed to responding to feedback in a timely manner.