Inclusive Citizen Experience: Beyond Accessibility Compliance

Picture a woman renewing her disability benefit online. She is blind, using a screen reader, and the government portal's session times out after ten minutes of inactivity — the same ten minutes her assistive technology needs just to read the form aloud. She restarts three times before giving up and calling a hotline that puts her on hold for forty minutes. Nothing on that portal broke the letter of the law. It was, technically, accessible. It was also unusable.

That gap — between "compliant" and "usable" — is where most public-sector accessibility work quietly fails. The thesis of this piece is simple: accessibility is not a checklist bolted onto a digital service; it is the design of the default path, and if the default excludes anyone, the service is broken for everyone, not just the citizen who can't get through it. Inclusive citizen experience means building the primary journey so that disabled people, older citizens, non-native speakers, and people in crisis can complete it without asking for help — not building a parallel "accessible version" that gets maintained twice a year and trusted never.

What does "inclusive citizen experience" actually mean?

Inclusive citizen experience is the design discipline of making a public service completable, first time, by the widest realistic range of citizens — including those with visual, auditory, cognitive, motor, or situational impairments, and those with low digital or language confidence. It differs from accessibility compliance in one crucial respect: compliance measures whether a page meets a technical standard; inclusion measures whether a real person, under real conditions, gets the outcome they came for.

The technical baseline still matters. The Web Content Accessibility Guidelines (WCAG) 2.2, maintained by the World Wide Web Consortium, set the internationally recognised standard for perceivable, operable, understandable, and robust digital content, and most government digital services in the region and beyond are now expected to meet at least the AA conformance level. But WCAG tells you whether a screen reader can parse a button. It does not tell you whether a citizen who is grieving, frightened, or simply exhausted after a night shift can get through your bereavement form or benefits application without abandoning it halfway. That second question is the one citizen experience design actually has to answer.

Why do so many "accessible" public services still exclude people?

Because most accessibility programmes are run by compliance teams auditing against a standard, not by service designers watching someone try to actually finish a task. The World Health Organization's 2022 Global Report on Health Equity for Persons with Disabilities estimates that around 1.3 billion people — roughly 16% of the global population — live with significant disability. That is not an edge case to be patched after launch. It is a sixth of every citizen population a government serves, and most public digital services were not designed with them in the room from the start.

The failure pattern is consistent: an accessibility audit runs late in the build, alt-text and colour contrast get fixed, a conformance statement gets published to satisfy the regulator, and the underlying journey — the number of steps, the density of the language, the assumption that everyone has a stable internet connection and a spare hour — never gets touched. You end up with a form that a screen reader can technically read but that still takes eleven pages to renew a parking permit. Accessible, and still hostile.

What has behavioral economics got to do with accessibility?

Everything, because exclusion is rarely about a missing alt tag — it is about friction that able-bodied, digitally fluent, time-rich citizens don't notice and everyone else cannot absorb. The economist Cass Sunstein gave this friction a precise name in his 2019 paper "Sludge and Ordeals" in the Duke Law Journal: sludge is friction that serves no legitimate purpose and exists mainly through neglect — repeated logins, redundant document uploads, confusing navigation, unnecessary waiting. Sunstein's core argument is that sludge is not neutral. It taxes citizens unevenly, and the tax falls hardest on people with the least capacity to pay it: someone with a cognitive disability, someone reading in their third language, someone juggling a disability and two jobs.

This is also where the public administration research on administrative burden earns its place in a CX conversation. Pamela Herd and Donald Moynihan's 2018 book Administrative Burden: Policymaking by Other Means distinguishes three costs citizens absorb when dealing with government: learning costs (working out what you're entitled to and how to apply), compliance costs (gathering documents, meeting deadlines), and psychological costs (the stress and stigma of the interaction itself). Every one of those costs compounds for a disabled or marginalised citizen. A sighted citizen skims a confusing form in ninety seconds and moves on; a citizen using a screen reader has to listen to every confusing word in sequence. The learning cost isn't the same cost twice — it's an order of magnitude larger.

The behavioral lever governments consistently under-use is the default. Choice architecture tells us that whatever path requires the least active decision-making becomes the path most people take — and for citizens with limited cognitive bandwidth or executive function, the default is often the only path they can complete. If the default route to renew a licence is a fourteen-field digital form, that is the journey your most vulnerable citizens are stuck with, because the "assisted" alternative usually requires exactly the confidence and stamina they don't have. Design the default for the person with the least capacity, and everyone above that line moves faster too. Design it for the confident majority, and you've quietly built an exclusion mechanism.

How do you actually build an inclusive citizen journey?

Inclusion has to be engineered into the journey from the first workshop, not reviewed in at the end. This is the sequence that holds up in practice:

1. Map the journey with disabled and marginalised citizens in the room, not as a proxy panel. Recruit citizens who use assistive technology, who have low literacy, who don't speak the dominant language at home, and who are older and less digitally confident — and watch them attempt the real task, not a sanitised prototype.
2. Identify the moments of truth where friction turns into abandonment. Every service has two or three steps where a confused or overwhelmed citizen gives up — a document upload, an identity check, a payment screen. Find them before you redesign anything else.
3. Set the default path to the lowest-capacity user, not the median one. If your median user can handle a dense form, that tells you nothing about whether your most burdened citizen can. Build for the edge and the middle inherits the benefit.
4. Strip every step that exists for the institution's convenience rather than the citizen's need. Redundant uploads, repeated identity verification across departments, and "come back later" loops are sludge dressed up as due process.
5. Write in plain language and offer it in the citizen's own language and format. Easy-read versions, audio alternatives, and translated forms aren't a courtesy add-on; for a large share of any population they are the difference between completing a task and not.
6. Keep an assisted channel that is genuinely fast, not a punishment for going offline. If the phone line takes forty minutes, you have built two services — one for the capable and one for the excluded — and called it inclusion.
7. Test with assistive technology on the actual production build, not a design file. Screen readers, switch access, and voice control behave differently on a live form than in a mockup; the last mile is where most conformance work quietly falls apart.
8. Publish an accessibility statement and act on what it admits. A conformance statement that lists known issues and never fixes them is a liability document, not a commitment.

None of this is exotic. It is the same discipline behind any well-run service design engagement — mapping the real journey, finding where it breaks, and rebuilding around the person with the least slack, rather than the process with the least friction for the back office.

What does exclusion actually cost a government?

Every citizen who abandons a digital form doesn't disappear — they migrate to the most expensive channel a government operates: the phone line, the walk-in counter, the escalation to a caseworker. Inclusion failures don't reduce demand; they redirect it upward in cost. A benefits application that a disabled citizen cannot complete online becomes a call centre ticket, then a home visit, then a complaint, then — increasingly — a formal appeal. The service didn't get cheaper because it excluded someone. It got more expensive somewhere else in the system, and the citizen paid the difference in time, stress, and often in missed entitlements they were legally owed.

There's a trust cost too, and it compounds. Citizens who struggle repeatedly with government services don't file a helpful bug report — they conclude the system wasn't built for them, and they stop trying. That's a political and social cost as much as an operational one: the citizens most dependent on public services — the elderly, the disabled, the newly arrived — are precisely the ones most likely to disengage when the default journey defeats them. Behavioral economics has a name for the compounding effect of small frictions repeated across every interaction: they don't just cost time, they erode the affect heuristic — the citizen's gut feeling about the institution — long after the specific form is forgotten.

What does good inclusive citizen experience actually look like?

It looks unglamorous, which is exactly the point. It's a benefits form that pre-fills what the government already knows instead of asking a citizen to re-enter their own name for the fourth department in a row. It's a plain-language summary sitting above the legal text, not replacing it but translating it. It's a call centre script that doesn't require a citizen to repeat their case history to every new agent because the case history travels with them. It's an accessibility statement that lists three known issues and a fix date, rather than a blanket assurance that everything already works.

Under the UK's Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018, government digital services are required to meet WCAG standards and publish an accessibility statement — a legal minimum that has pushed genuine improvement in some services and produced box-ticking in others. The difference between the two isn't the regulation; it's whether the organisation treats the statement as a design brief or a legal shield. Citizen experience teams that treat every published accessibility gap as an open item on a roadmap — owned, prioritised, and dated — close that gap faster than teams that treat the audit as an annual event to survive.

Governments serious about this also stop treating inclusion as a separate workstream from digital transformation. The organisations that get furthest run a proper baseline first — understanding where the journey currently sits across the full range of citizen capability — before redesigning anything. A structured CX maturity assessment is a useful forcing function here: it makes an organisation state, out loud, whether inclusive design is a genuine capability or an aspiration in a strategy deck. And because exclusion typically clusters at a handful of predictable moments — identity verification, payment, document upload — the same discipline used to find and fix moments of truth in the customer journey applies directly to public services: find the two or three steps doing the most damage, fix those first, and resist the temptation to redesign the whole service before you've proven the fix works.

Listening has to be structural, not occasional. A single annual satisfaction survey will never surface the citizen who couldn't complete the form at all — she's not in your respondent pool, because she never finished the transaction you're surveying her about. A deliberate voice of customer strategy built to capture the citizens who dropped out, not just the ones who succeeded, is the only way to see the exclusion your own analytics dashboard is structurally blind to.

The line worth holding

Every public service was, at some point, designed around an imagined citizen — able-bodied, fluent, patient, connected. That imagined citizen doesn't exist, and building for them anyway is how government ends up running two systems: a fast digital one for people who don't need help, and a slow, expensive, humiliating one for everyone else. The fix isn't a bigger accessibility budget or a more thorough audit. It's the harder discipline of designing the one true path — the default everyone walks — around the citizen with the least capacity to cope with your mistakes. Get that right, and you haven't built an accessible service. You've built a government that actually works for the people who need it most, which was always meant to be the same government, not a separate one.

Renascence works with public-sector organisations across the region to rebuild citizen journeys around inclusion rather than retrofit it — explore our approach to public services customer experience and digital transformation, or get in touch to talk through where your own service is quietly excluding the citizens it was built to serve.