hpe-branding/05-accessibility.md

05 — Accessibility

HPE's stated position, quoted: "We believe that being accessible is a requirement, not an option."

The standard

HPE aligns to WCAG level A and AA, and to the four core principles (perceivable, operable, understandable, robust). The page states the level plainly: "The guidelines identified as level A and AA are the required design elements for all applications and are incorporated in the US Section 508 standard and HPE's Design System." AAA is not required.

One inconsistency to be aware of: the top of the page cites WCAG 2.2, while the government standards section further down links and cites WCAG 2.1. The level commitment (A and AA) is consistent across both; the version reference is not. Assume 2.2 for new work, since that is what the normative statement at the top of the page says, but expect to see 2.1 cited in older HPE material.

Named regulatory drivers on the same page: US Section 508, the Americans with Disabilities Act, and the European Accessibility Act. The EAA is the one most likely to bite on a product sold into the EU.

The scope the docs describe is broader than the usual reading of "accessibility." It covers keyboard navigation, speech input, screen readers, alternative input devices such as head pointers, screen magnification, and color blindness, and it explicitly includes temporary and situational disability. The figure cited is that about 25% of the United States population lives with some type of disability, permanent or not, sourced to the CDC.

Who is responsible for what

This is the part that decides arguments, so it is worth having straight. The answer depends on whether you use Grommet plus the HPE theme or only the tokens.

Consideration	Grommet + HPE theme	Design tokens only
Color contrast ratios	Handled	You apply the color, pairing, and usage guidance yourself
Typography (legibility, scaling, line height)	Handled	You implement from the typography system
Component behavior (keyboard nav, ARIA, focus)	Handled	You implement accessible behavior manually
Focus styles and states	Handled	You implement from the component-states tokens
ARIA roles and attributes	Handled, but you supply context-specific values	Fully your responsibility
Responsiveness across breakpoints	Handled	You implement from layout and spacing tokens
Semantic HTML structure	Handled	You ensure correct structure
Alt text and descriptions	Yours	Yours
Labeling (forms, buttons, errors)	Yours	Yours
Readability of copy	Yours (follow voice and tone)	Yours

Two conclusions fall out of this table.

First, Grommet plus the HPE theme buys most of the mechanical accessibility work. That is the strongest practical argument for the React path, stronger than the visual consistency argument.

Second, the bottom three rows are never bought. Alt text, labels, and readable copy are the product team's job under either path. A team that adopts Grommet and then ships unlabeled icon buttons has not become accessible.

Design-time coverage

Every component and asset in the HPE Design System Figma library is built on design tokens that align with accessibility standards. Using the prebuilt components or applying the tokens as Figma variables gets you WCAG-compliant styles without doing contrast math.

This is worth stating plainly to designers: the contrast work is already done inside the token pairs, and it is undone the moment someone picks a custom color off the Figma color wheel.

Testing

The rule that sets expectations

Automated testing tools catch approximately 30 to 50% of accessibility violations. Manual testing is not optional. Any plan that consists of "we run axe in CI" covers at best half the problem.

Recommended practice

• Shift left. Violations avoided at design time cost nothing to fix.
• Try it yourself. Turn the monitor off and use a screen reader. Unplug the mouse. Use simulator tools for color blindness, dyslexia, and tunnel vision.
• Test with real users with disabilities. The docs name Bill Tipton of the HPE Product Accessibility Office as an internal resource for usability testing. He has used a screen reader daily since losing his eyesight in 1999.

Tooling

CI and automation:

• Lighthouse GitHub Action (the design system runs this on its own PRs)
• axe-core (React integration available)
• axe-testcafe

Browser extensions:

• axe DevTools
• Access Assistant (Level Access), which saves reports to track compliance over time
• WAVE
• Lighthouse (built into Chrome DevTools)
• ANDI

Simulators:

• Silktide (color blindness, dyslexia, tunnel vision, cataracts, blindness)
• WebAIM Color Contrast Checker
• Colorblind Web Page Filter (Toptal)

Internal HPE resources

The docs link to the HPE Product Accessibility Program Office on SharePoint, which publishes designer and developer guides, and to HPE Accessible Design Training, a set of videos under 10 minutes each with an accompanying "Pocket Guide" of takeaways. Both are on hpe.sharepoint.com and need an HPE login.

Open questions

• Is there a required accessibility sign-off before a product release, and who gives it? The docs describe resources and advocacy, not a gate.
• Does HPE publish VPATs or ACRs per product, and who writes them? This matters for public sector deals where an ACR is a procurement requirement.
• Is the operative version 2.1 or 2.2? The page cites both. Worth asking the accessibility office which one an audit would be run against.
• Does the accessibility office have capacity to test every product, or is Bill Tipton's availability the practical bottleneck?
• What is HPE's compliance deadline posture on the European Accessibility Act, and does it change the priority of any of this?