Accessibility & support · prototype standard

Accessibility is part of the product, not a page at the bottom of it.

This concept sets WCAG 2.2 AA as the delivery target, combines technical testing with disabled-user feedback, and makes accessibility information part of opportunities, profiles, content and support.

Target standard

Build to WCAG 2.2 AA, then test the real journeys people use.

The prototype is not claiming full compliance before an audit. A production successor should be tested across representative pages, forms, search, applications, dashboards, media and account journeys, then publish a clear accessibility statement and roadmap.

Prototype targetWCAG 2.2 AAIndependent audit + ongoing regression testing before claiming compliance.

Keyboard first

Every interactive control should work without a mouse, with visible focus and sensible focus order.

Screen readers

Semantic headings, labels, status announcements, descriptive links and sensible landmarks throughout.

400%

Zoom & reflow

Content should remain usable at high zoom without horizontal scrolling for ordinary reading journeys.

Accessible media

Captions, transcripts and meaningful alternatives for video, audio, images and graphics.

Readable content

Plain language, strong contrast, useful headings and Easy Read or alternative formats where needed.

Reduced motion

Respect operating-system preferences and avoid motion or flashing that is unnecessary to the task.

Accessibility preferences

Let people describe what helps, without turning disability into a label.

Preferences can be private by default and used for matching. A volunteer decides what, if anything, is shared with an organisation.

Sam's accessibility preferencesPrivate unless Sam chooses to share

Remote first

Step-free if onsite

Accessible toilet

Written instructions

Flexible breaks

Captions on video calls

Camera optional

Low sensory environment

Consent-led sharingThe matching engine can use these preferences without exposing a diagnosis. Organisations only see the practical adjustments the volunteer elects to share.

Accessible content formats

One message should not depend on one format.

Important guidance, policy and onboarding content should be designed so people can consume it in the format that works for them.

HTML

Accessible web page

The default source of truth with semantic structure, responsive text and assistive-technology support.

Easy Read

Simple language + images

For important processes such as joining Reach, benefits guidance, safeguarding and reporting concerns.

Large print

Print-friendly alternatives

High-contrast, large-type versions where downloadable or printable information is useful.

Captions + transcript

Every important video should have accurate captions and a usable text transcript.

BSL

Signed content where justified

Priority guidance and campaign content can have BSL versions where the audience need supports it.

TXT

Plain-text fallback

Simple alternatives for complex documents, charts and downloadable resources.

Production test plan

Test the journeys, not just the homepage.

Automated checks catch only part of the problem. The release process should combine code-level checks, manual keyboard testing, assistive technology and disabled-user testing.

KeyboardNavigation, filters, forms, mega menus, modals, dashboards

Screen readerVoiceOver, NVDA and representative browser combinations

Zoom / reflow200% and 400%, portrait mobile and narrow desktop windows

ContrastText, controls, focus indicators, status colours and disabled states

Speech / voiceControls have usable accessible names and predictable labels

Real usersPeople with physical, sensory, cognitive and neurodivergent access needs

Support centre

Give people somewhere obvious to go when they hit a barrier.

Accessibility support should be visible in the product, not hidden inside legal text.

Using Reach with assistive technology

Short guides for keyboard navigation, screen readers, zoom, browser settings and reduced motion.

Prototype guide

Report an accessibility problem

A dedicated route that asks what someone was trying to do, what blocked them and what alternative they need now.

Request another format

Ask for Easy Read, large print, plain text, audio or another reasonable format for important Reach information.

Adjust how Reach communicates

Choose email frequency, written-first communication and other practical account preferences.

See profile preferences

Accessibility roadmap

Never declare victory and walk away.

Every substantial release should keep accessibility inside definition-of-done, and the public statement should be reviewed after major changes and at least annually.

1Baseline auditIndependent WCAG 2.2 AA review of representative journeys.
2Fix systemic issuesTheme, components, forms and dashboard patterns first.
3Disabled-user testingValidate whether technically compliant journeys are actually usable.
4Publish statementBe explicit about known issues, workarounds and contact routes.
5Continuous checksRegression testing on releases and ongoing content governance.

Accessible volunteering & Right to Try GOV.UK accessibility guidance

Our proposed platform-wide standard

Independent WCAG 2.2 AA audit and disabled-user testing are required before production launch.

Read the accessibility standard