# 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?