Viewee accessibility conformance programme. Prepared 16 September 2026 by Instinct (for Alex). Lives in Legal alongside the other compliance requirements docs.
1. Purpose and scope
Accessible feedback collection is Viewee's core pitch to care providers. The product must stand up to WCAG 2.2 Level AA scrutiny: the people using it include elderly residents and people with visual, motor and cognitive impairments, and buyers (care home operators, and potentially local authorities / NHS-adjacent bodies) increasingly ask for accessibility evidence in procurement. This document is the standing audit plan and checklist for all Viewee product surfaces:
Marketing site - Astro static build (apps/web), roughly 45-54 pages: home, waitlist, platform, solutions, sectors, product tour, pricing, case studies, blog, FAQ, company, careers, legal, account, refer.
Waitlist - part of the marketing build but called out separately: it is a form, and forms are where accessibility failures concentrate.
Admin dashboard - planned SaaS (client admin + Viewee ops admin + restricted super-admin). Not yet built; this plan applies at build time, not after.
Resident/family feedback collection flows - the most critical surface and the reason Viewee exists. End users may have visual, motor or cognitive impairments, may be using shared care-home tablets, and may be assisted by staff. Highest audit priority.
2. Conformance target and legal context
Target: WCAG 2.2 Level AA - all Level A and Level AA success criteria. W3C advises WCAG 2.2 as the conformance target for new and updated sites.
UK Equality Act 2010 - service providers must make reasonable adjustments; WCAG 2.2 AA is the accepted technical benchmark for web services.
PSBAR - public sector bodies (local authority commissioners, NHS) must meet WCAG 2.2 AA and publish accessibility statements. If Viewee sells into public-funded care, buyers will inherit or ask for this evidence.
Accessibility statement - publish one per site/app and keep it current; include a feedback/contact route for accessibility problems.
3. Methodology
Follow W3C's Website Accessibility Conformance Evaluation Methodology (WCAG-EM 1.0):
Define scope - each surface above is a separate conformance target with its own report. Conformance claims apply to full pages only; no partial-page claims.
Explore the target - inventory page types, templates, key processes (waitlist signup, feedback submission, login, action management).
Select a representative sample - for the ~54-page marketing site: every unique template + every page in a key process + a random sample of template instances. Homepage, waitlist, pricing, product tour, one page per nav section, all forms, all legal pages. Dashboard and feedback flows: every screen, every state (empty, error, success, loading).
Audit the sample - automated scan (axe-core, WAVE, Lighthouse CI) as a first pass, then manual testing. Automated tools catch roughly 30-40% of issues; manual keyboard, screen reader, zoom and cognitive review is not optional.
Report - use the WCAG-EM Report Tool structure: per-criterion pass/fail/not-present, with screenshots, severity and reproduction steps.
Before any staged pages exist, run W3C's Easy Checks as a first review on whatever renders; it is a fast triage, not a conformance audit.
4. Test environment and assistive technology matrix (care settings)
Care homes mean shared Android/iPad tablets, older hardware, variable wifi, gloves and tremors, staff assisting residents, and users with low vision, hearing loss, arthritis, dementia and learning disabilities. Test matrix:
| Category | Tools | Priority surfaces |
|---|---|---|
| Screen readers | NVDA + Chrome (Windows, free), JAWS + Chrome/Edge, VoiceOver + Safari (iOS and macOS), TalkBack + Chrome (Android tablet) | F, D, W |
| Voice input / control | iOS Voice Control, Windows Voice Access, Dragon - label-in-name and visible focus are critical | F, D |
| Zoom and magnification | Browser zoom to 400%, text-only zoom to 200%, Windows Magnifier, iOS Zoom | All |
| Contrast / display | Windows High Contrast / forced colors mode, dark mode, reduced motion OS setting | All |
| Keyboard only | Tab / Shift+Tab / Enter / Space / arrows / Esc through every flow, no mouse | All |
| Switch / alternative input | Switch Control (iOS) spot-check on feedback flows | F |
| Devices | One budget Android tablet, one iPad, one small phone (320px CSS width), one desktop | All |
Wherever possible, involve real users - residents, family members and care staff - in at least one moderated round before launch. W3C's guidance on involving users covers how to do this cheaply and early.
5. WCAG 2.2 A/AA checklist by principle
Surface key: M marketing site, W waitlist, D admin dashboard, F feedback collection. "New in 2.2" marks criteria added in WCAG 2.2 (the ones auditors now check that older audits missed). Each links to its W3C Understanding page under https://www.w3.org/WAI/WCAG22/Understanding/.
5.1 Perceivable
| SC | Level | Surfaces | Viewee-specific test |
|---|---|---|---|
| 1.1.1 Non-text Content | A | M W D F | Logo, hero images, icons, dashboard charts and status icons all have text alternatives; decorative images properly hidden from AT. Star/NPS rating widgets expose value as text. |
| 1.2.1-1.2.5 Time-based Media | A/AA | M D F | Product tour and any demo videos: captions (1.2.2), audio description or media alternative (1.2.3/1.2.5). Applies to marketing video and any in-product help video. |
| 1.3.1 Info and Relationships | A | All | Real heading hierarchy (h1-h3, no skipped levels for styling), form fields have programmatic labels, data tables use th, related radios grouped in fieldset/legend. Dashboard theme/action groupings conveyed structurally, not just visually. |
| 1.3.2 Meaningful Sequence | A | All | Reading order matches visual order when CSS reorders layout (especially mobile reflow of marketing sections and dashboard cards). |
| 1.3.3 Sensory Characteristics | A | D F | Never "click the green button" or "use the panel on the right" as the only cue. Important in staff-facing help text. |
| 1.3.4 Orientation | AA | All | Works portrait and landscape; do not lock orientation on tablets (care homes mount tablets in both). |
| 1.3.5 Identify Input Purpose | AA | W D F | autocomplete tokens on name/email/org fields (waitlist, account, staff-invite forms) so autofill and cognitive aids work. |
| 1.4.1 Use of Color | A | D F | Feedback themes, action status (open/in progress/done), CQC evidence states must not be color-only - pair with icon, text or pattern. Critical for the "what improved" evidence trail. |
| 1.4.3 Contrast (Minimum) | AA | All | 4.5:1 body text, 3:1 large text (18pt+/14pt bold+). Check brand palette on marketing site (pastel-on-white hero sections are a classic fail) and muted gray secondary text in dashboard. |
| 1.4.4 Resize Text | AA | All | 200% text zoom without loss of content or function; no fixed-height clipping in cards, nav or form fields. |
| 1.4.5 Images of Text | AA | M | Headlines and testimonials must be real text, not baked into hero graphics. |
| 1.4.10 Reflow | AA | All | No two-dimensional scrolling at 320px CSS width (400% zoom). Check dashboard tables and charts - provide list alternatives rather than horizontal scroll. |
| 1.4.11 Non-text Contrast | AA | All | 3:1 for input borders, focus indicators, icon-only buttons, chart series and control boundaries. The most commonly failed criterion on modern minimal designs. |
| 1.4.12 Text Spacing | AA | All | Override line-height 1.5x, paragraph 2x, letter 0.12x, word 0.16x - nothing clips or overlaps. |
| 1.4.13 Content on Hover or Focus | AA | M D | Nav dropdowns and tooltips: dismissible with Esc, hoverable (pointer can move onto them), persistent until dismissed. |
5.2 Operable
| SC | Level | Surfaces | Viewee-specific test |
|---|---|---|---|
| 2.1.1 Keyboard | A | All | Every function keyboard-operable: nav, carousels, forms, dashboard actions, feedback widgets. Custom components (rating scales, multi-select chips) need roving tabindex and arrow-key support. |
| 2.1.2 No Keyboard Trap | A | All | Modals, embedded video players, chat widgets: focus can always leave with standard keys. |
| 2.1.4 Character Key Shortcuts | A | D | Any single-key shortcuts in dashboard must be remappable or active only on focus - otherwise they break speech input users. |
| 2.2.1 Timing Adjustable | A | D F | Session timeouts on feedback forms and admin: warn, allow extension, never silently lose a resident's half-written feedback. No auto-advancing steps. |
| 2.2.2 Pause, Stop, Hide | A | M D | Hero animations, auto-playing carousels, live-updating dashboard widgets: pause/stop control. Honor prefers-reduced-motion everywhere (advisory AAA 2.3.3 - treat as required for this audience). |
| 2.3.1 Three Flashes | A | All | No flashing content above thresholds in any animation or video. |
| 2.4.1 Bypass Blocks | A | All | Skip-to-content link first in tab order on every page; landmark regions (header/nav/main/footer) so AT users can jump. |
| 2.4.2 Page Titled | A | All | Unique descriptive title per page - with 45-54 pages on a shared template, verify each page overrides the template title. |
| 2.4.3 Focus Order | A | All | Tab order follows meaning; modal focus moves in and returns correctly; no positive tabindex hacks. |
| 2.4.4 Link Purpose (In Context) | A | M | No bare "Read more" / "Click here" lists on blog and case studies; link text meaningful in context. |
| 2.4.5 Multiple Ways | AA | M | Nav + footer sitemap + search or clear IA to reach pages. |
| 2.4.6 Headings and Labels | AA | All | Headings describe topic; labels describe purpose. Dashboard filter/sort controls labeled descriptively. |
| 2.4.7 Focus Visible | AA | All | Visible focus indicator on everything interactive - never outline:none without a styled replacement that passes 1.4.11. |
| 2.4.11 Focus Not Obscured (Minimum) - new in 2.2 | AA | M D F | Sticky headers/footers, cookie banners and chat widgets must not fully hide the focused element. Marketing sites with sticky nav + cookie bar fail this constantly - check at all viewport heights. |
| 2.5.1 Pointer Gestures | A | M D F | No multipoint/path-based gestures (swipe carousels need buttons; pinch-zoom charts need +/- controls). |
| 2.5.2 Pointer Cancellation | A | All | Actions fire on up-event, not down-event; accidental touches cancelable. |
| 2.5.3 Label in Name | A | W D F | Accessible name starts with the visible label text - critical for voice input users saying "click Submit feedback". Icon-only buttons need matching aria-labels. |
| 2.5.4 Motion Actuation | A | D F | No shake/tilt-only functions; always a UI alternative. |
| 2.5.7 Dragging Movements - new in 2.2 | AA | D | Any drag interaction (reordering actions, kanban-style boards, drag-to-prioritize themes) must have a single-pointer alternative (buttons, menus). High relevance to the "owned actions" board. |
| 2.5.8 Target Size (Minimum) - new in 2.2 | AA | All | 24x24 CSS px minimum (or sufficient spacing exception). For the care audience, design to 44x44px (Apple HIG) on feedback flows - AA floor is the legal minimum, not the goal. Check mobile nav, icon buttons, close buttons, pagination. |
5.3 Understandable
| SC | Level | Surfaces | Viewee-specific test |
|---|---|---|---|
| 3.1.1 Language of Page | A | All | html lang="en-GB" (or en) set on every page - trivial in Astro layout, easy to forget. |
| 3.1.2 Language of Parts | AA | M F | Any Welsh-language or quoted resident content marked with lang attribute. |
| 3.2.1 On Focus | A | All | Focusing an element never triggers navigation or popups. |
| 3.2.2 On Input | A | W D F | Changing a field (select, checkbox) never auto-submits or redirects without warning. |
| 3.2.3 Consistent Navigation | AA | All | Nav order identical across all marketing pages and dashboard sections. |
| 3.2.6 Consistent Help - new in 2.2 | A | All | If contact/help/chat appears on multiple pages, it sits in the same relative position on each. Decide one help pattern (e.g. footer contact + fixed help button) and keep it identical everywhere. |
| 3.3.1 Error Identification | A | W D F | Errors identified in text, tied to the field, announced to screen readers (aria-describedby + focus management on submit). |
| 3.3.2 Labels or Instructions | A | W D F | Every input has a visible label (placeholder is not a label); required fields marked in text, not color/asterisk alone; format hints before the field (e.g. phone format). |
| 3.3.3 Error Suggestion | AA | W D F | Suggest corrections ("Did you mean .co.uk?") where detectable, especially email fields. |
| 3.3.4 Error Prevention (Legal, Financial, Data) | AA | D F | Feedback submissions and anything affecting records: review/confirm step or reversible. Consent checkboxes need explicit confirmation copy. |
| 3.3.7 Redundant Entry - new in 2.2 | A | D F | Multi-step flows never re-ask for information already given (name, email, care home). Auto-populate or offer previous answers. Directly relevant to multi-step feedback forms. |
| 3.3.8 Accessible Authentication (Minimum) - new in 2.2 | AA | D | Staff/admin login must not require cognitive function tests (puzzles, memorized characters). Allow password managers and paste; offer magic link or passkey. Remember many care staff have low digital confidence. |
5.4 Robust
| SC | Level | Surfaces | Viewee-specific test |
|---|---|---|---|
| 4.1.1 Parsing | - | - | Removed in WCAG 2.2 (obsolete). Still run a validator to catch real issues, but no conformance requirement. |
| 4.1.2 Name, Role, Value | A | W D F | Every custom component exposes correct name/role/state to AT: rating widgets (role=slider or radiogroup), toggles (aria-pressed/switch), tabs, accordions, toasts, progress indicators. This is where React component libraries fail - audit the chosen library before committing. |
| 4.1.3 Status Messages | AA | D F | "Feedback submitted", "Action saved", error banners: role=status / aria-live so screen readers announce them without focus change. |
6. Beyond WCAG - care-sector requirements
WCAG AA is the floor. For Viewee's actual users, also require:
Plain language - resident-facing copy at lower-secondary reading level; short sentences, one idea per screen, no jargon. (WCAG 3.1.5 is AAA, but for this audience treat it as required.) Follow W3C's Writing for Web Accessibility tips.
Large touch targets - 44x44px+ on feedback flows (above the 24px AA floor), generous spacing between adjacent targets for tremor users.
One thing per screen option - feedback flow usable as a stepped wizard with progress saved, as well as a single form.
Staff-assisted completion - design for a carer holding the tablet and reading questions aloud: big text, clear question wording, obvious back/save.
Shared devices - no reliance on persistent login on shared tablets; easy sign-out; no sensitive data left on screen.
Print / verbal fallback - an accessible printable version of feedback forms for homes with low device coverage is a differentiator, not a concession.
Design for ageing - follow W3C's Older Users guidance: higher default font sizes, generous spacing, clear error recovery, no time pressure.
7. Cadence, ownership and reporting
| When | What |
|---|---|
| Every commit | axe-core / pa11y CI on changed pages; lint rules (jsx-a11y on the Next.js app, astro-eslint equivalents) fail the build on A-level violations. |
| Every new feature/page | Manual keyboard pass + NVDA/VoiceOver smoke test before merge. Checklist section 5 as the PR template. |
| Pre-launch (staging) | Full WCAG-EM audit of all surfaces, including the assistive tech matrix in section 4, plus at least one moderated session with care-sector users. |
| Quarterly after launch | Re-audit sample + review analytics for accessibility feedback; update accessibility statement. |
| Annually | Full re-audit; consider a VPAT/ACR if enterprise or public-sector buyers ask. |
Report format: WCAG-EM Report Tool output (per-criterion, per-page) plus an issue register ranked: Blocker (A-level fail on a key process) / High (AA fail on key process) / Medium / Low. Track fixes in the same system as other product bugs - accessibility issues are bugs, not a separate programme.
8. Sources (W3C WAI)
WCAG 2.2 Recommendation: https://www.w3.org/TR/WCAG22/
How to Meet WCAG (Quick Reference, filterable by level): https://www.w3.org/WAI/WCAG22/quickref/
What's New in WCAG 2.2: https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/
WCAG-EM 1.0 (evaluation methodology): 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/
Selecting Web Accessibility Evaluation Tools: https://www.w3.org/WAI/test-evaluate/tools/selecting/
How People with Disabilities Use the Web: https://www.w3.org/WAI/people-use-web/
Involving Users in Web Projects: https://www.w3.org/WAI/planning/involving-users/
Older Users and Web Accessibility: https://www.w3.org/WAI/older-users/
Writing for Web Accessibility (plain language tips): https://www.w3.org/WAI/tips/writing/