Healing Process policy suite

Accessibility and Accessible Information Policy

1. Purpose

To make Healing Process information and functionality perceivable, operable, understandable and robust, and to support the identification, recording, flagging, sharing, meeting and review of individual information and communication needs.

2. Scope and status

This policy applies to website, mobile apps, clinician portal, documents, video, support, procurement, user research and provider deployment. It supports—but does not by itself discharge—a provider’s duties under accessibility, equality and NHS information standards.

Core supplier and product policy

3. Policy principles

• Accessibility is a product requirement and release criterion, not an optional adaptation after launch.
• The design target for public digital content is WCAG 2.2 AA unless a stricter contractual requirement applies. Conformance is claimed only after appropriate testing and with known limitations disclosed.
• A person must have an effective alternative where a digital function cannot reasonably be made usable for them.
• Accessible information needs are part of the care workflow and should follow the six-step cycle: identify, record, flag, share, meet and review.

4. Mandatory requirements

• Use semantic structure, keyboard operation, visible focus, text alternatives, captions/transcripts, sufficient contrast, reflow, scalable text and understandable errors.
• Ensure the camera and image-comparison journey works with relevant platform accessibility features, switch access, screen magnification and assisted capture where practicable.
• Do not rely only on colour, animation, drag gestures, time limits or tiny visual detail to convey a clinical or operational status.
• Provide accessible full-screen viewing of screenshots and clinical source images while preserving privacy and role permissions.
• Maintain an accessibility statement with tested status, known issues, alternative access, contact route, response target and review date.
• Record individual formats and communication support in structured fields and expose them to the authorised service at the point of need.
• Test with disabled users and assistive technologies, not solely automated tools. Prioritise defects according to user impact and safety.
• Procure third-party components only after assessing accessibility and include remediation and cooperation duties in supplier contracts.

5. Procedure and escalation

• Every design story includes accessibility acceptance criteria and is reviewed before development completion.
• Each release receives automated and risk-based manual testing. Critical barriers or safety-related failures block release unless an authorised temporary control and alternative route are approved.
• Users can report a barrier through an accessible route. The issue is acknowledged, triaged, given an owner and tracked to resolution or documented workaround.
• Providers configure how communication needs are shared with other systems and staff and how reasonable adjustments are delivered when the app alone cannot meet the need.

6. Roles and responsibilities

Accessibility Lead

owns standards, audit, statement and remediation governance.

Design/development

build and test accessible components and journeys.

Content owners

write plain content and provide accessible media and documents.

Support

offers accessible channels and records barriers.

Providers

identify and meet individual needs, maintain alternative routes and integrate reasonable-adjustment information.

7. Records, confidentiality and retention

Retain standards, test plans/results, user-research evidence, defect logs, exceptions, statements, complaints, format requests, provider configurations and remediation decisions.

Records created under this policy must be accurate, attributable, access-controlled and linked to the applicable retention schedule. Where a provider is the controller or authoritative record holder, its documented instructions and legal duties apply.

8. Monitoring, assurance and review

Review at least annually and after major design or standard changes. Monitor critical defects, completion with assistive technology, reported barriers, response times, alternative-route use and accessibility debt.

Material non-compliance is reported through the relevant clinical-safety, patient-safety, data, security, safeguarding, HR, contractual or whistleblowing route. Corrective actions receive an owner, target date and effectiveness check.

9. Training and communication

The policy owner identifies which roles require awareness, operational or specialist training. Training is accessible, version-controlled, role-specific and refreshed after material change or evidence that understanding is inadequate. Providers communicate local procedures and contact routes before users are granted access.

10. Related documents

• Equality, Diversity, Inclusion and Human Rights Policy
• English as an Additional Language Policy
• Information Security Policy

11. Approval record