Topic 1.9 — Digital Inclusion & Accessibility

In health and care, a digital service that excludes some people is not a neutral technical choice — it withholds care from those who often need it most, so inclusion and accessibility are matters of clinical safety, equity, and public trust, not optional polish.

Why this matters in health and care#

In most sectors, an inaccessible website loses a sale. In health and care, it can mean a person misses a screening invitation, cannot book an urgent appointment, cannot understand their discharge instructions, or cannot see the medication warning that would have kept them safe. Digital exclusion here is not an inconvenience; it is a route to harm and to widening inequality, delivered with public money under statutory duty.

The people most likely to be digitally excluded — older people, disabled people, people in poverty, people with low literacy, people whose first language is not English, people in areas with poor connectivity — are very often the same people who carry the greatest burden of ill health. This is the uncomfortable core of the topic: digital exclusion maps almost exactly onto health inequality. When you digitize a service without a plan for those who cannot use the digital route, you can actively move resource and attention towards those already best served, and call it progress — the "inverse care law" in a new medium.

Accessibility is also a legal duty, not a nicety. Public sector bodies in the United Kingdom must meet accessibility standards in law, and health and care organizations carry additional statutory obligations to meet the communication needs of disabled patients and carers. Access to digital services is itself increasingly a wider determinant of health — connectivity, a device, and the confidence to use them now shape whether a person can reach care at all. Treating inclusion as a bolt-on is how organizations end up in breach of the law, of trust, and of their own equity commitments. Inclusion and accessibility must be designed in from the first discovery conversation (see Topic 3.4 — Discovery Phases) and measured as a first-class outcome (see Topic 10.0 — Objectives & Key Results (OKRs)).

Core concepts#

The digital divide and digital exclusion. The digital divide is the gap between those who can access and use digital technology and those who cannot. Digital exclusion is usually driven by five interacting factors: access (a device and a reliable connection), affordability (data and hardware cost money), skills (the confidence and ability to use digital tools), motivation and trust (believing digital is safe and worthwhile), and design (whether the service is usable at all). A person is rarely excluded by one factor alone; an older person on a low income in a rural area with poor broadband faces several at once, which is why simplistic fixes fail.

Who is excluded, and the equity link. Exclusion clusters by age, disability, income and poverty, literacy, language, and connectivity. Because these same characteristics predict poorer health, digital exclusion compounds existing health equity gaps. The mental shift required is to stop treating "digital access" as a background utility and start treating it as one of the social determinants of health — a factor that shapes health outcomes as surely as housing or income.

Core20PLUS5. NHS England's Core20PLUS5 is a national framework for reducing health inequalities. It focuses effort on the most deprived 20% of the population (the "Core20"), plus locally identified inclusion groups experiencing poorer access or outcomes (the "PLUS"), and five clinical areas of particular focus. It gives you a ready-made lens for asking who is your service failing, and a shared vocabulary with clinical and public-health colleagues for targeting inclusion work where the inequality is greatest.

Web accessibility and WCAG 2.2. Web accessibility is the practice of removing barriers that stop disabled people using digital services. The recognized technical standard is the Web Content Accessibility Guidelines (WCAG), currently version 2.2, organized around four principles — content must be perceivable, operable, understandable, and robust — at three conformance levels, A, AA, and AAA. UK public sector services are expected to meet WCAG 2.2 level AA.

The Public Sector Bodies Accessibility Regulations 2018. The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 make WCAG conformance a legal requirement for most public sector websites and apps, and require a published, accurate accessibility statement. This sits alongside the Equality Act 2010 duty to make reasonable adjustments. Accessibility is a compliance floor with legal consequence, not an aspiration.

The Accessible Information Standard. The NHS Accessible Information Standard (data standard reference DCB1605) is a mandatory standard requiring health and adult social care providers to identify, record, flag, share, and meet the information and communication needs of patients, service users, and carers with a disability, impairment, or sensory loss — for example, providing information in easy-read, braille, large print, or via a British Sign Language interpreter. It is a statutory duty, not guidance.

Inclusive design and universal design. Universal design aims to make products usable by as many people as possible without adaptation; inclusive design is the process of deliberately designing with and for people who are usually excluded, on the principle that solving for the edges improves the service for everyone — the "curb-cut effect".

Assistive technology. Assistive technologies — screen readers, magnifiers, voice input, switch access, alternative keyboards — are how many disabled people use digital services. Accessible design is what lets these technologies work; an inaccessible interface silently breaks them.

Assisted digital and offline routes. "Assisted digital" describes support for people who cannot use a digital service independently — by phone, in person, through a trained helper, or via an intermediary. Offline and analog routes (post, telephone, face-to-face) are not legacy debt to be switched off; for some people they are the only safe route to care. Treat them as first-class channels with their own service levels.

Plain language, readability, and health literacy. Plain language is writing that a reader can understand the first time they read it. Readability is measurable — reading-age formulas estimate how hard text is. Health literacy is a person's ability to find, understand, and use health information; a large share of adults find standard health materials too complex, so clear content is a safety intervention, not a stylistic one.

Best practices#

1. Design for inclusion from discovery, never as a retrofit. Bring accessibility and inclusion into the first discovery conversations, user research, and design decisions (see Topic 3.0 — User Research & Service Design and Topic 3.4 — Discovery Phases). Retrofitting accessibility onto a finished product is more expensive, less effective, and often impossible without rebuilding. Make "who might this exclude?" a standing question at every design review.

2. Meet WCAG 2.2 level AA as a floor, and test with real assistive technology. Treat WCAG 2.2 AA conformance as the minimum, not the target, and verify it with automated tools and manual testing using screen readers, keyboard-only navigation, and magnification. Automated checkers catch perhaps a third of issues; the rest need human testing, ideally including disabled users. Publish an honest, specific accessibility statement and keep it current, as the regulations require.

3. Meet the Accessible Information Standard as an operational reality, not a policy on a shelf. Ensure your systems can capture a person's communication needs, flag them, share them across settings, and actually deliver information in the required format — easy-read, large print, braille, BSL. This is a legal duty and a safety issue: a deaf patient who cannot understand appointment changes, or a person with a learning disability given only dense text, is a patient at risk.

4. Make assisted digital and offline routes first-class channels. Resource, monitor, and improve the telephone, in-person, and paper routes with the same seriousness as the app. Never decommission an analog route until you have evidence that everyone who relied on it has a genuine, tested alternative. "Digital by default" must never become "digital only" in a service where exclusion means missed care.

5. Write in plain language and test readability. Aim health and care content at a reading age around 9 to 11 years, use short sentences and common words, expand or avoid jargon, and structure content so the most important information comes first. Test with readability tools and, better, with people who have low literacy or English as an additional language. Offer easy-read and translated versions where your population needs them.

6. Use Core20PLUS5 to target inclusion effort where inequality is greatest. Rather than spreading inclusion work thinly, use Core20PLUS5 and local population data to identify who your service is failing and concentrate improvement there. This connects your digital delivery to the organization's health-inequalities strategy and gives clinical and public-health colleagues a shared frame for prioritization.

7. Design with excluded people, not just for them. Recruit research and testing participants who are older, disabled, digitally unconfident, on low incomes, or speak other languages — the people usually absent from convenience samples — and pay them properly. Co-design and lived-experience input surface barriers no checklist predicts, and build the empathy that sustains inclusion work under delivery pressure.

8. Measure inclusion, not just averages. Headline metrics hide exclusion: a service used successfully by most people can be quietly failing exactly the groups most in need. Segment your data by the characteristics that predict exclusion, track completion and drop-off for each, and watch the gap between groups, not just the mean (see Topic 1.3 — Evidence-Driven Decisions and Topic 10.0 — Objectives & Key Results (OKRs)).

Questions to discuss with your team#

1. Who does our service currently exclude — and have we actually looked, or are we reassured by an average? This question forces the team past comfortable headline figures to the distribution underneath them. In health and care it matters acutely because the people a digital service is most likely to shut out — older, disabled, poorer, less literate, non-English-speaking, poorly connected — are disproportionately those with the greatest health needs, so exclusion and inequality reinforce each other. The tension to surface is that segmenting your data may reveal an uncomfortable truth that a strong overall completion rate was hiding, and that fixing it costs money and slows the roadmap. Look concretely at drop-off rates by age band, by device, by whether an assisted route was used, and by any inclusion groups your organization tracks under Core20PLUS5. Consider whether you even collect the data needed to see exclusion, or whether your analytics are blind to it by design. A good, honest answer names specific groups the service is failing, admits where you lack the data to know, and commits to measuring the gap between groups rather than celebrating the mean.

2. Are our non-digital routes genuinely first-class, or are we quietly starving them so we can declare a digital success? Digital transformation programs are often incentivized on digital uptake, which creates a subtle pressure to let telephone, paper, and face-to-face routes wither — or to close them before a safe alternative exists. This matters because for some patients the analog route is not a preference but the only safe way to reach care, and withdrawing it can cause real harm while the dashboard shows progress. Debate the honest trade-off: maintaining multiple channels costs money and effort, and there is legitimate value in moving willing users to efficient digital routes, but "digital by default" must never slide into "digital only". Look at whether your offline routes have proper service levels, funding, and monitoring, or whether they are treated as legacy debt. Examine what evidence you would need before decommissioning any route, and whether you have it. A strong answer treats assisted-digital and offline channels as first-class services with owners and standards, and sets an explicit, evidence-based bar that must be cleared before any route is closed.

3. When we say we meet our accessibility and Accessible Information Standard duties, is that a tested reality or a statement of intent? Many organizations have an accessibility statement and a policy referencing the Accessible Information Standard, yet fail in practice — the screen reader breaks on the booking flow, or the deaf patient still gets an unreadable letter. This question matters because these are legal duties with real consequences, and because the gap between paper compliance and lived experience is where patients actually get harmed. The tension is that genuine assurance requires manual testing with assistive technology and disabled users, capturing and acting on recorded communication needs across systems, and ongoing effort — all harder than publishing a statement once. Probe specifics: when did a real screen-reader user last complete your core journey; can your systems flag and share a communication need from one setting to another; who is accountable when an easy-read version does not exist. Consider that automated accessibility tools miss most issues, so a green automated report proves little. A good answer distinguishes clearly between what has been tested with real users and assistive technology and what is merely asserted, and owns the gaps with a plan and an accountable owner rather than a reassuring form of words.

4. Do we design and test with excluded people, or only for them — and are we willing to pay for that involvement? It is easy to build an idea of the excluded user from personas, assumptions, and checklists, and much harder to put a screen-reader user, a person with a learning disability, or someone with English as an additional language in the room and act on what they show you. This matters because lived experience surfaces barriers no automated tool or well-meaning designer predicts, and because inclusion work loses momentum under delivery pressure unless the team has met the people it affects. The tension is practical: recruiting excluded participants takes longer, costs more, requires paying people properly for their time, and sometimes returns findings that force an uncomfortable rework late in a sprint. Probe whether your research samples reach beyond the confident, able, connected users who are easiest to find, and whether procurement and delivery timelines leave room for genuine co-design rather than a token consultation. Consider who holds the budget for participant payment and whether "no budget" is quietly excluding the very people you most need to hear. An honest answer shows excluded people shaping decisions, not merely validating them, and treats their involvement as a funded, recurring practice rather than a one-off exercise.

5. How will digitizing this service change the equity picture — could we widen the gap even as the headline improves? Digitizing a service redistributes effort, attention, and convenience, and it rarely does so neutrally: the people quickest to adopt a new digital route are often those already best served, so a service can improve on average while the most excluded fall further behind. This is the "inverse care law" playing out in a new medium, and in health and care it maps almost exactly onto existing health inequality, which is why it deserves explicit scrutiny rather than optimistic assumption. The trade-off to name is that the efficiencies and savings that justify a digital program are real, but banking them can mean withdrawing resource from the slower, costlier routes that keep the most excluded connected to care. Look concretely at your population through Core20PLUS5 and local data: which cohorts carry the highest need, how do they currently reach the service, and what happens to them under the new design. Ask whether your success measure is "more people use digital" or "no group is worse off and the most excluded improve" — the two can point in opposite directions. A good answer sets equity as an explicit design goal from the outset, models the effect on the most excluded before build, and commits to monitoring the gap after go-live rather than assuming digitization lifts everyone.

6. When digital and non-digital budgets compete, how do we decide — and who is accountable for the people a cut would exclude? Inclusion is ultimately a resourcing decision, and it is usually made implicitly, through where money and management attention flow rather than through an explicit, owned choice. This matters because the assisted-digital and offline routes that protect the most excluded are the easiest line to trim when budgets tighten, and their users are often those least able to complain loudly or visibly. The real tension is that every pound spent maintaining a telephone or paper route is a pound not spent on new digital capability, and the savings case for a program frequently depends on eventually reducing those routes — so the pressure to cut is structural, not accidental. Examine whether inclusion has a named senior owner with actual budget authority, whether inclusion metrics reach the board alongside financial and clinical ones, and whether anyone is formally accountable when a cut re-excludes a group the organization is statutorily committed to reaching. Consider how a proposed saving would be scrutinized: is there an equity impact assessment, or does the number simply get banked. An honest answer places accountability for the excluded with a specific, senior person, makes the trade-off visible at the level where money is allocated, and refuses to treat inclusion funding as a discretionary extra to be raided when times are hard.

In practice: a health & care example#

An integrated care system (ICS) is rolling out a new online route for patients to book and manage outpatient appointments, aiming to cut the volume of phone calls to booking teams and reduce missed appointments. The first business case is framed entirely around digital uptake and call-center savings.

The digital inclusion lead intervenes early, during discovery. She maps the outpatient population against Core20PLUS5 and finds that a large share of the highest-need patients are older, live in the most deprived neighbourhoods, or have a recorded communication need under the Accessible Information Standard. She reframes the success measure: not "percentage of bookings made online" but "no group is worse off than before, and the most excluded groups improve." User research deliberately recruits older patients, a blind man who uses a screen reader, a woman with a learning disability, and a family who speak Sylheti at home, paying them for their time.

The research is sobering. The prototype booking flow breaks under keyboard-only navigation; the confirmation letter is written at a reading age far above most patients; there is no route at all for someone who cannot use the app. The team fixes the flow to meet WCAG 2.2 level AA, verified by manual testing with the same assistive technology real patients use. Content designers rewrite letters in plain language, tested for readability and available in easy-read and translated versions, with communication-need flags carried through from the shared record. Crucially, the telephone route is not cut but strengthened: funded, given a service standard, and staffed to help people who cannot or will not use the digital route.

At go-live, the dashboard segments booking success and appointment attendance by age, deprivation decile, communication need, and channel, and watches the gap between groups. Three months in, digital uptake is healthy among younger patients, and — the metric that matters most — attendance among the most deprived cohort has held steady rather than fallen, because the telephone route absorbed those who could not go digital. When a board member asks why the phone lines were not closed to bank the savings, the inclusion lead points to the segmented data: closing them would have re-excluded exactly the patients the ICS is statutorily committed to reaching.

Sector lenses#

Startup#

A small digital-health company faces the sharpest inclusion trade-off: accessibility and assisted routes cost scarce engineering time and runway, and the fastest path to a demo is to design for confident, able, English-speaking users on new phones. Resist this. Build WCAG 2.2 AA conformance and plain-language content in from the first sprint, because retrofitting later is far more expensive and because NHS buyers increasingly require accessibility evidence through the Digital Technology Assessment Criteria (DTAC). Small teams can still recruit a handful of disabled and digitally-excluded testers cheaply, and doing so early is the single highest-leverage inclusion investment a startup can make. Treat an honest accessibility statement and a clear plan for the excluded as a sales asset, not a burden.

Small business#

An established small provider — a GP practice, a community pharmacy, a care home, a domiciliary-care agency, a single-site clinic, or a small health-tech supplier past the startup stage — carries the same accessibility and Accessible Information Standard duties as a large trust, but with real patients and almost no dedicated digital or IT capability to meet them. The practical risk is that inclusion falls between the cracks of an off-the-shelf website, a booking widget, and a supplier's patient app that no one on site has ever tested with a screen reader or checked for reading age. Because cash is tight and operations are ongoing, the affordable moves are to demand accessibility and communication-need support as explicit conditions when choosing suppliers (using DTAC-style questions), to fix the handful of high-traffic materials — appointment letters, consent forms, the front door of any online service — into plain language and accessible formats, and to keep telephone and in-person routes genuinely open rather than pushed aside. Recording and honoring a patient's communication need is a legal duty that a small provider can meet with disciplined process even without technology. The mindset shift is to treat inclusion as a small set of non-negotiable basics baked into procurement and daily routine, not a project the organization lacks the staff to run.

Enterprise#

An NHS trust or ICS operates at a scale where exclusion becomes a population-level equity failure and a legal exposure, and where legacy systems and fragmented data make it genuinely hard to capture and share communication needs across settings. The enterprise challenge is institutional: accessibility and the Accessible Information Standard get owned by no one, offline routes get quietly defunded to hit digital targets, and inclusion becomes a policy no one operationalizes. The corrective is to give inclusion an accountable senior owner, wire Core20PLUS5 into portfolio prioritization, mandate accessibility testing in every delivery lifecycle (see Topic 3.5 — Delivery Lifecycles), and report inclusion metrics to the board alongside financial and clinical ones. Scale is also an asset: a large organization has the population data to measure exclusion properly, if it chooses to look.

Government#

A national body — NHS England, the Department of Health and Social Care, a devolved government — sets the standards and duties others must meet, so its ways of working shape inclusion across the whole system: WCAG expectations, the Accessible Information Standard, Core20PLUS5, and the accessibility regulations are instruments of population-scale equity. Its decisions attract legal, parliamentary, and public scrutiny, so transparency about where services still exclude people is a duty, not a courtesy. The distinctive risk at this scale is mandating a digital channel nationally without funding the assisted and offline routes that make it safe, thereby entrenching exclusion for millions in one policy. The corrective is proportionate, well-resourced standards, published inclusion data, and a firm principle that no national digital service goes live without a tested, funded route for those who cannot use it.

Common failure modes#

• Retrofitting accessibility. Bolting accessibility on after build, when it is costly and often impossible. Antidote: design in from discovery and test continuously.
• Digital by default becoming digital only. Closing phone and paper routes before a safe alternative exists. Antidote: treat offline routes as first-class; require evidence before any closure.
• Compliance theater. An accessibility statement and a policy, with no real testing behind them. Antidote: manual testing with assistive technology and disabled users; honest statements.
• Averages hiding exclusion. A strong overall metric masking failure in the groups most in need. Antidote: segment and watch the gap between groups, not the mean.
• Convenience-sample research. Testing only with confident, able, English-speaking users. Antidote: deliberately recruit and pay excluded participants.
• Jargon and dense content. Writing above the population's health literacy, causing safety errors. Antidote: plain language, readability testing, easy-read and translated versions.
• The Accessible Information Standard on a shelf. Recording communication needs but never sharing or meeting them. Antidote: operationalize capture, flag, share, and deliver.

Maturity model#

Checklist#

• Inclusion and accessibility are considered from discovery, not retrofitted.
• The service meets WCAG 2.2 level AA, verified by manual and assistive-technology testing, with a current, honest accessibility statement.
• Communication needs are captured, flagged, shared, and met per the Accessible Information Standard.
• Assisted-digital and offline routes are funded, monitored, and treated as first-class channels.
• Content is in plain language, readability-tested, with easy-read and translated versions where needed.
• Core20PLUS5 and local data are used to target inclusion effort where inequality is greatest.
• Research and testing deliberately include, and pay, excluded participants.
• Metrics are segmented by exclusion factors, and the gap between groups is tracked — not just the average.
• No digital route is decommissioned without evidence that everyone reliant on it has a safe alternative.
• Inclusion is owned by an accountable senior leader and reported to the board.

Key sources#

• NHS England — Core20PLUS5 (approach to reducing healthcare inequalities).
• NHS England — Accessible Information Standard (DCB1605).
• World Wide Web Consortium (W3C) — Web Content Accessibility Guidelines (WCAG) 2.2.
• GOV.UK — Understanding accessibility requirements for public sector bodies (Public Sector Bodies Accessibility Regulations 2018).
• NHS Digital Service Manual — accessibility, inclusive design, and content guidance.
• GOV.UK Service Manual (GDS) — Making your service accessible and assisted digital support.
• Good Things Foundation — research on digital inclusion and the digital divide.
• Equality Act 2010 — duty to make reasonable adjustments.

References#

1. Digital divide — Wikipedia — https://en.wikipedia.org/wiki/Digital_divide
2. Health equity — Wikipedia — https://en.wikipedia.org/wiki/Health_equity
3. Social determinants of health — Wikipedia — https://en.wikipedia.org/wiki/Social_determinants_of_health
4. Web accessibility — Wikipedia — https://en.wikipedia.org/wiki/Web_accessibility
5. Web Content Accessibility Guidelines — Wikipedia — https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines
6. Inclusive design — Wikipedia — https://en.wikipedia.org/wiki/Inclusive_design
7. Universal design — Wikipedia — https://en.wikipedia.org/wiki/Universal_design
8. Assistive technology — Wikipedia — https://en.wikipedia.org/wiki/Assistive_technology
9. Plain language — Wikipedia — https://en.wikipedia.org/wiki/Plain_language
10. Readability — Wikipedia — https://en.wikipedia.org/wiki/Readability
11. Health literacy — Wikipedia — https://en.wikipedia.org/wiki/Health_literacy
12. Core20PLUS5 (adults) – reducing healthcare inequalities — NHS England — https://www.england.nhs.uk/about/equality/equality-hub/national-healthcare-inequalities-improvement-programme/core20plus5/
13. Accessible Information Standard (DCB1605) — NHS England — https://www.england.nhs.uk/about/equality/equality-hub/patient-equalities-programme/equality-frameworks-and-information-standards/accessibleinfo/
14. Web Content Accessibility Guidelines (WCAG) 2.2 — World Wide Web Consortium (W3C) — https://www.w3.org/TR/WCAG22/
15. Understanding accessibility requirements for public sector bodies — GOV.UK — https://www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps
16. The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 — legislation.gov.uk — https://www.legislation.gov.uk/uksi/2018/952/contents/made
17. NHS Digital Service Manual — accessibility and inclusive design — NHS England — https://service-manual.nhs.uk/accessibility
18. Making your service accessible: an introduction — GOV.UK Service Manual — https://www.gov.uk/service-manual/helping-people-to-use-your-service/making-your-service-accessible-an-introduction
19. Equality Act 2010 — legislation.gov.uk — https://www.legislation.gov.uk/ukpga/2010/15/contents