Clear by Design: Making UK Patient Communications Accessible Before Sign-Off
Patient-facing medical communications are judged not only on scientific accuracy but on whether people can actually use them. In the UK, expectations around accessible information are shaped by the NHS Accessible Information Standard, WCAG 2.2 guidance and a wider move towards inclusive service design. Yet accessibility is still too often treated as a final polish rather than a core review requirement.
For UK MedComms teams, the practical answer is to build accessibility into the sign-off process from the start. The checklist below is designed for account handlers, writers, designers and reviewers working on patient materials in 2026. It is not a substitute for specialist accessibility advice, but it gives teams a shared structure for catching common problems before they become deadline crises.
Why accessibility belongs in the review plan
Accessibility is not a niche concern. Patients may have low health literacy, visual impairment, dyslexia, motor difficulties, hearing loss or limited digital access. A leaflet can be medically approved and still fail if the reading order is broken, the contrast is poor or the PDF is a flattened image that a screen reader cannot interpret.
There is also a compliance dimension. Plain-language edits must not alter the meaning of approved claims, and accessible formats must remain fair, balanced and consistent with the source material. That is why accessibility should sit alongside medical and regulatory review, not after it.
Phase one: brief and scope
- Identify the audience and any known access needs. Ask the client whether the material must meet NHS Accessible Information Standard expectations, WCAG 2.2 AA where relevant, or internal brand accessibility rules.
- Agree formats at the outset: accessible HTML, tagged PDF, large print, easy read, audio or British Sign Language versions. Avoid scanned or image-only PDFs as the default.
- Set a plain-English approach and a realistic reading level. Do not claim a reading age unless the material has been tested.
- Name an accessibility lead and include accessibility acceptance criteria in the brief and statement of work.
Phase two: writing and content
- Use descriptive headings and keep paragraphs short. Front-load the most important information so readers can scan.
- Prefer common words and active voice. Explain clinical terms on first use, avoid idioms and keep acronyms to a minimum.
- Check that numbers, risk statements and instructions remain consistent. Medical review should confirm that plain-language changes have not distorted the evidence.
- Draft alt text and table summaries while writing, not after design. Decorative images should be marked as such.
- Use descriptive link text rather than phrases such as ‘click here’.
Phase three: design and build
- Check colour contrast for text and essential graphics. Do not rely on colour alone to convey meaning.
- Use a readable type size and left-aligned text. Avoid justified text, long line lengths and blocks of capital letters.
- Keep layouts uncluttered, with clear hierarchy and enough white space. Avoid placing text over busy images.
- For PDFs, confirm tagged headings, logical reading order, bookmarks and form labels. Test with a screen reader where possible.
- Provide captions or transcripts for audio and video. Consider BSL interpretation where the audience or client requires it.
Phase four: review and sign-off
- Add an accessibility check to the standard review template: structure, contrast, alt text, reading order, plain language and format.
- Run medical, regulatory and accessibility reviews in parallel. Accessibility should not wait for final design, and final design should not wait for accessibility.
- Triage issues into blockers, improvements and documented exceptions. A missing alt text or unreadable PDF is a blocker; a minor line-length issue may be an improvement.
- Confirm that accessibility fixes have not changed approved claims. Keep version control and an evidence trail.
- Record the accessibility review outcome in the sign-off file, including any agreed exceptions and their rationale.
Phase five: patient testing and launch
- Test with a small group of representative patients, including people with disabilities where possible. Task-based questions are more useful than general feedback: can they find the dose, understand the risk or locate the contact details?
- Check the material across devices and assistive technologies, and review a printed proof for large-print versions.
- Publish the accessible version alongside the standard version and provide a clear route for requesting alternative formats.
Phase six: after launch
- Monitor requests for alternative formats and log recurring issues.
- Update templates and guidance so that lessons are reused on the next project.
- Review materials when regulations, brand rules or clinical content change.
Where accessibility slips under deadline pressure
In practice, accessibility is rarely removed deliberately. It is squeezed. Design freezes arrive before alt text is written. A PDF is flattened to protect layout. Brand colours are accepted despite contrast concerns. Patient testing is cut to protect the launch date. The accessibility reviewer is not invited to the final meeting.
These are process failures rather than individual failures. The remedy is to create an accessibility gate before design freeze and another before final PDF release. Templates, approved components and a short review window of forty-eight hours can prevent last-minute negotiation. If a deadline is compressed, reduce optional scope rather than removing core checks.
Making sign-off faster, not slower
Accessibility checks become quicker when they are routine. Build a library of approved accessible components, train writers on plain-language review, and make the checklist part of project management rather than a separate document. Assign a named owner and track how often issues are found late.
For UK MedComms teams, accessible patient materials are both a quality marker and a risk control. Clear by design is not an extra step at the end of the process; it is a more professional way of running the process from the beginning.