claude
0730557624
Readable mirror of https://design-system.hpe.design, sourced from github.com/grommet/hpe-design-system (Apache-2.0) at commit 567c4d5 (2026-07-16). The upstream site is a client-rendered Next.js export with no sitemap; it returns a 1.5 KB empty shell to curl. This repo is the same guidance in plain Markdown with every value resolved, plus the assets checked in. Docs: scope and authority model, brand foundations with resolved color and spacing tables, the design token tiers and version map, UI copy rules, accessibility conformance and the responsibility split, the component and template inventory, and an adoption/review checklist. Assets: 452 SVG icons, 5 HPE and Aruba word-marks, 282 documentation graphics. HOWTO-mirror-the-design-system.md is a verified runbook for rebuilding this from scratch against a newer upstream. Colors were resolved programmatically, not transcribed: token JSON stores references, not values. Apache-2.0 upstream. Note that it covers copyright, not trademark; Brand Central remains authoritative for the HPE marks.
130 lines
5.8 KiB
Markdown
130 lines
5.8 KiB
Markdown
# 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?
|