Process & Registry

Family Accessibility Baseline

The target: the latest published WCAG, AA

Every live repo aims for WCAG AA at whichever version is current — not a version pinned once and left to go stale. As of this writing that's WCAG 2.2 (a W3C Recommendation since October 2023). When a newer version publishes, this doc's target updates in the same commit that starts treating it as current — the same "the spec and the reasoning move together" rule every other file in this repo already follows. AA, not AAA: AAA is not a realistic bar for most real content (colour choice, video captioning cost) and this family has never claimed it.

Status: real work exists, but scattered and never stated as a target

Unlike family-seo.md's baseline (checked 2 Sept 2026 and found nowhere), accessibility work has actually been happening across this family for weeks — it just never got written down as its own commitment, so it reads as a side-effect of other fixes rather than a real standard. What already exists, found across other specs while writing this one:

• Contrast ratios calculated and enforced per accent colour (tools/tokens/base.tokens.json — Rissbrook's teal, Pets' terracotta, Editions' crimson all have their AA math shown in their own $description; Rissbrook's original #183d4a was rejected specifically for failing WCAG AA).
• The large-text 3:1 accommodation used deliberately, not stumbled into (docs/family-wordmark.md: 19px bold clears the 18.66px large-text threshold, which is why every product accent can stay one colour with no separate dark-mode value).
• 44px touch targets on the footer's mobile stacked rows and the header's touch controls, citing WCAG 2.2 AA's target-size criterion by name (docs/family-footer.md, docs/family-header.md) — though the Website itself still ships 40px and is flagged in its own doc as "the one that should change."
• WCAG 2.1 SC 1.4.1 (Use of Color) cited twice independently (docs/family-wordmark.md, docs/family-footer.md) to justify a link's hover state matching its neighbours rather than being the only colour-only signal in a row.
• A repo-specific accessibility reviewer already exists — the wcag-accessibility-auditor agent, scoped to Amoleo-Pets today. Whether it generalises to a family-wide reviewer or every repo gets its own is open (see below).

What doesn't exist: a stated target anyone could point to before starting work, systematic keyboard/screen-reader testing beyond the specific fixes above, and any check that would catch a new AA violation the way check-brand.mjs catches a colour drifting. The pattern so far has been reactive — a real bug got found and fixed properly — not proactive.

What "AA" actually obliges, restated plainly

Not a re-derivation of WCAG itself — the four POUR principles, restated at the level this family actually designs at:

• Perceivable — 4.5:1 contrast for normal text, 3:1 for large text/UI components (already the working bar for every accent, see above); real alt text, not filename-shaped; captions on anything with audio, once this family has video.
• Operable — real keyboard navigation and visible focus states (already a stated rule for the wordmark's own link behaviour); 44×44px touch targets (2.2's new criterion, already partially adopted); no keyboard trap in any drawer/panel/modal (the header's drawer and panel patterns need a real audit against this, not assumed).
• Understandable — consistent navigation and naming across the family (largely already the point of this whole repo); form errors that say what went wrong and how to fix it, matching this family's own writing voice rather than a generic "invalid input."
• Robust — real semantic HTML and ARIA only where it adds information screen readers can't otherwise get (aria-hidden on the footer's separator dots is the existing pattern to match, not the exception).

What's still open

• No check-accessibility.mjs and no manifest — same starting point family-seo.md had. A real audit (automated — axe-core or similar — plus manual keyboard/screen-reader passes) per live repo hasn't happened; this doc is the stated target, written before the tooling or the audit exist.
• Whether wcag-accessibility-auditor generalises to a family-wide role or stays Pets-specific with siblings created per repo — not decided.
• The Website's 40px vs. 44px touch targets — already flagged in family-footer.md as owed work, restated here since it's the one known, named, un-fixed AA gap this family already has written down.

Generated from docs/family-accessibility.md + docs/family-footer.md + docs/family-wordmark.md + tools/tokens/base.tokens.json. Edit there and re-run npm run build in docs-site-src/ — never hand-edit a page.