Structural audit of the Viewee build against WCAG 2.2 Level AA. Prepared 16 September 2026 by Instinct (for Alex). Companion document: "WCAG 2.2 AA - Audit Plan + Checklist" (same folder). This pass audits what exists structurally and flags exactly what needs testing once pages are staged; it is not a conformance claim.
1. What exists today (verified state)
| Surface | State as of 16 Sep 2026 | Auditable now? |
|---|---|---|
| Marketing site (Astro, static) | ~45-54 static pages built covering home, waitlist, platform, solutions, sectors, product tour, pricing, case studies, blog, FAQ, company, careers, legal, account, refer. Homepage and waitlist at highest fidelity; secondary pages on a shared production-ready template. Per-page fidelity, forms, consent and mobile QA are known-unfinished. | Source only - no staging URL yet |
| Waitlist | Part of the Astro build; highest-fidelity page. Form behaviour (validation, errors, consent) on the remaining-work list. | Source only |
| Admin dashboard | Not built. Planned Next.js + React + TypeScript + PostgreSQL, client admin + Viewee ops admin + restricted super-admin planes. | No - checklist applies at build time |
| Resident/family feedback flows | Not built. Planned as part of the SaaS product. | No - checklist applies at build time |
| Repo | github.com/alex-viewee/viewee (private) currently empty - full source tree packaged for a one-shot desktop upload. Verified via GitHub API 16 Sep 2026: no code reachable at any path. | - |
Consequence: there is no rendered DOM to test against any success criterion yet. Everything below is a structural risk assessment plus an exact test protocol to run the moment pages are staged. Nothing in this document should be read as "passed".
2. Structural findings and leverage points
F1 - The shared template is the single highest-leverage audit target. Roughly 40+ marketing pages render from one shared template. Any accessibility defect in that template (missing skip link, weak focus styles, low-contrast muted text, no landmark regions) replicates across the whole site; conversely, fixing the template fixes most of the site. Audit order when staged: template first, then per-page content.
F2 - The biggest risk is not the marketing site. It is building the dashboard and feedback flows inaccessibly and retrofitting later. Retrofitting accessibility into form-heavy React apps typically costs 3-5x more than building it in. The checklist in the companion doc (sections 5-6) should gate those builds: component library choice (4.1.2 Name/Role/Value is where React apps fail), form patterns, drag alternatives, status messages, accessible auth.
F3 - WCAG 2.2's new criteria are the likely blind spot. The six new A/AA criteria (2.4.11 Focus Not Obscured, 2.5.7 Dragging Movements, 2.5.8 Target Size, 3.2.6 Consistent Help, 3.3.7 Redundant Entry, 3.3.8 Accessible Authentication) postdate most templates, component libraries and auditors' habits. Each maps to a concrete Viewee feature (see risk register).
F4 - Known-unfinished work is accessibility-relevant. Forms, consent and mobile QA are explicitly unfinished in the build - these three areas carry a disproportionate share of A/AA failures (3.3.1-3.3.4 error handling, 2.5.8 target size, 1.4.10 reflow). Do not treat "mobile QA done" as "accessibility done"; they overlap but are not the same check.
3. Risk register - exact tests to run once staged
Ranked by expected impact on care-sector users. Each entry: the WCAG 2.2 criterion, why it is likely, and the exact test.
| # | Risk | SC | Surface | Why likely | Exact test once staged |
|---|---|---|---|---|---|
| 1 | Touch targets below 24px on mobile nav, icon buttons, close buttons | 2.5.8 (AA, new) | M W | Minimal marketing templates routinely ship 16-20px icon targets | Measure every interactive target at 375px and 320px viewport; list every target under 24x24px CSS or failing the spacing exception |
| 2 | Sticky header / cookie banner / chat widget fully hiding focused elements | 2.4.11 (AA, new) | M W D | Sticky nav + consent banner both planned/typical on this build | Tab through every page at 3 viewport heights (short laptop, tablet portrait, phone); any focused element fully hidden = fail |
| 3 | Brand-palette contrast failures (muted grays, pastel-on-white) | 1.4.3, 1.4.11 (AA) | All | Most common automated-audit failure class; secondary text and input borders are the usual culprits | axe/Lighthouse full-site scan + manual check of focus indicators, input borders, chart series at 3:1; body text 4.5:1 |
| 4 | Waitlist form: placeholder-as-label, no autocomplete tokens, errors not announced | 3.3.2, 1.3.5, 3.3.1/3.3.3 (A/AA) | W | Forms explicitly unfinished; the waitlist is the first conversion point and the first accessibility impression for care-sector buyers | Inspect each field: visible label? autocomplete token? Submit with errors using keyboard + NVDA: is focus moved to the error and the message announced and tied to the field? |
| 5 | Shared-template page titles/headings duplicated across ~45 pages | 2.4.2, 2.4.6 (A/AA) | M | Template pages often inherit identical titles/h1s | Crawl staged site; verify unique descriptive title and one h1 per page |
| 6 | No skip link / landmarks on template | 2.4.1 (A) | M | Astro starters vary; must be verified, not assumed | First Tab press on any page reveals a working skip-to-content link; header/nav/main/footer landmarks present (NVDA elements list) |
| 7 | Drag-only interactions on the "owned actions" board | 2.5.7 (AA, new) | D | Kanban-style action boards are the natural UI for feedback-to-action; drag is the default pattern | When built: every drag operation achievable by single pointer (move buttons/menu) and by keyboard |
| 8 | Login requires cognitive tests or blocks password managers | 3.3.8 (AA, new) | D | Care staff have low digital confidence; CAPTCHA puzzles or paste-blocking are common defaults | When built: log in with a password manager; verify paste works in password fields; no puzzle/memory CAPTCHA; offer magic link or passkey |
| 9 | Multi-step flows re-asking for known info | 3.3.7 (A, new) | F D | Multi-step feedback forms and onboarding wizards commonly re-ask name/email/org | When built: enter info in step 1, verify it is auto-populated or selectable later, never retyped |
| 10 | Silent loss of half-written feedback on timeout or navigation | 2.2.1, 3.3.4 (A/AA) | F | Residents type slowly; sessions on shared tablets expire | When built: start feedback, wait for session timeout / navigate away; verify warn + extend and that input survives (local save or confirm step) |
| 11 | Status-by-color only in themes/actions/evidence views | 1.4.1 (A) | D F | Dashboard status chips default to color-only | When built: view in grayscale / ask a color-blind check (simulator); every state distinguishable by text/icon too |
| 12 | "Feedback submitted" not announced to screen readers | 4.1.3 (AA) | D F | Toast/confirmation patterns rarely include role=status by default | When built: submit with NVDA/VoiceOver running; confirmation must be announced without moving focus |
| 13 | Hero/background motion with no pause and no reduced-motion fallback | 2.2.2 (A), 2.3.3 advisory | M | High-fidelity homepage likely has animation | Check for pause control on any auto-playing element; emulate prefers-reduced-motion and verify motion is suppressed |
| 14 | Product tour / demo video without captions | 1.2.2 (A) | M | Demo videos routinely ship uncaptioned | When video ships: captions verified against audio (not just auto-captions left unchecked) |
| 15 | Reflow failure at 320px on dashboard tables/charts | 1.4.10 (AA) | D | Data tables are the classic horizontal-scroll fail | When built: 320px viewport, no two-axis scrolling; tables get list/card alternatives |
4. Care-setting assistive technology considerations (baked into the tests above)
Screen readers: NVDA+Chrome and VoiceOver+Safari (iPad) as the primary pair; TalkBack on a budget Android tablet as the care-home reality check.
Voice input: label-in-name (2.5.3) is the make-or-break criterion - visible labels must match accessible names so "click Submit feedback" works.
Motor impairments / tremor: design feedback flows to 44x44px targets even though the AA floor is 24px; keep destructive and submit actions far apart (risk #1 and the 2.5.8 persona case - hitting Cancel instead of Submit).
Cognitive impairments and low digital confidence: plain language, one thing per screen, consistent help position (3.2.6), no re-typing (3.3.7), no puzzle logins (3.3.8).
Low vision / ageing: 200% text resize (1.4.4), 400% reflow (1.4.10), forced-colors mode check, high default font sizes. W3C's Older Users guidance applies directly to the resident population.
Shared devices: session behaviour (risk #10), easy sign-out, no residual sensitive data on screen.
5. What happens next
Source tree lands in the repo (pending Alex's one-shot upload), then staging deploy.
Run the risk register in section 3 against staging - items 1-6 apply to the marketing build immediately; items 7-15 gate the dashboard and feedback builds.
Fix the shared template first (finding F1), re-scan the site, then per-page content.
Adopt the companion checklist as the PR gate for the Next.js dashboard and feedback flows before those builds start (finding F2).
Publish an accessibility statement per surface at launch, with a feedback route.
6. Sources (W3C WAI)
WCAG 2.2 Recommendation: https://www.w3.org/TR/WCAG22/
How to Meet WCAG (Quick Reference): https://www.w3.org/WAI/WCAG22/quickref/
What's New in WCAG 2.2 (the 9 new criteria): https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/
WCAG-EM 1.0: https://www.w3.org/TR/WCAG-EM/
WCAG-EM Report Tool: https://www.w3.org/WAI/eval/report-tool/
Easy Checks - A First Review: https://www.w3.org/WAI/test-evaluate/easy-checks/
Older Users and Web Accessibility: https://www.w3.org/WAI/older-users/
How People with Disabilities Use the Web: https://www.w3.org/WAI/people-use-web/