Healthcare ADA
Brik's canonical accessibility & compliance standards for healthcare clients — HIPAA + ADA Title III + Section 1557, the technical floor, and BDS component-level rules.
Status: Canonical — promoted to BDS 2026-04-21.
Scope: Marketing sites AND product portals for healthcare clients.
Owner: Nick Stanerson (nick@brikdesigns.com).
The full canonical standards live alongside this page in healthcare-ada.md. That file ships with BDS (node_modules/@brikdesigns/bds/content-system/compliance/healthcare-ada.md) and is what every consumer repo's CLAUDE.md points to under its Compliance Profile section.
This page is the browse companion — same shape, web-readable, easier to cross-link.
When does this apply?
Default for any Brik healthcare client: HIPAA + ADA Title III. Confirm Medicare/Medicaid status before assuming Section 1557 applies — it significantly expands notice requirements.
| Regime | Trigger | What it requires |
|---|---|---|
| ADA Title III | Public accommodation open to patients | WCAG 2.1 AA, Accessibility Statement, auxiliary aids |
| HIPAA | Covered entity handling PHI | Privacy Policy, Notice of Privacy Practices, PHI encryption |
| Section 1557 | Receives federal financial assistance | Notice of Nondiscrimination, taglines in top 15 state languages, Civil Rights Coordinator |
| Section 504 | Same as 1557 | Mirrors 1557 |
Record the regime answers in each consumer repo's CLAUDE.md under a Compliance Profile section.
Non-negotiable technical floor
- WCAG 2.1 AA on every page — marketing and portal, same floor, no AAA bump
- Lighthouse a11y ≥ 95 on every published page
- axe-core CI check — blocks merge on
seriousorcritical, warn-only formoderate/minor - Manual keyboard + VoiceOver pass before any new flow ships
- Quarterly audit on every live client site; annual refresh of Accessibility Statement audit date
AA is the ceiling, not the floor. Healthcare sites are frequent ADA-lawsuit targets — never silently bump to AAA without a decisions-log entry, and never partial-disable a rule whole-app (per-selector baselines only).
Component-level rules (enforced in BDS)
These graduate from "good practice" to TypeScript-required as the a11y-props rollout lands.
| Component | Required prop |
|---|---|
Button | accessible text — children or aria-label |
IconLink | aria-label |
Modal | ariaLabelledBy + ariaDescribedBy, focus trap, focus return |
FormField | label |
Image | alt (empty string allowed only for decorative imagery) |
Rollout order
See Step 7 of healthcare-ada.md for the current schedule. Rough shape:
- ✓ TNCLD legal pages adopted
- ✓ This doc promoted to BDS
- Compliance Profile sections in each portal repo's
CLAUDE.md+ axe-core CI pilot inbrik-client-portal - a11y-required props on 5 BDS components (one PR each)
- axe-core CI ported to remaining portals
- Accessibility Preferences panel in the shared portal layer
- Full portal audits against these standards
Reading the full document
Open healthcare-ada.md for:
- Step 1 — client classification questions
- Step 2 — required content (statements, notices, taglines)
- Step 3 — technical standards (marketing + portal)
- Step 4 — audit cadence
- Step 5 — per-build documentation deliverables
- Step 6 — portal integration plan (CLAUDE.md, CI, component props, preferences panel, legal routes)
- Step 7 — rollout order
- Decisions log
Related
- Content System overview
- Cross-repo
CLAUDE.mdAstro a11y CI gate (brik-llm/websites/shared/CLIENT-ACCESSIBILITY-STANDARDS.md)
Brik Voice & Tone
The voice/tone substrate Brik uses when speaking as Brik — marketing copy, internal docs, client communications, and anywhere Brik's own voice is the brand on the page.
Image Mood
The 6-value photography/imagery-direction vocabulary captured in the client portal's Visual Direction intel topic — single source of truth for stock asset queries and mockup composition.