Context on the Line: Auditing UK Service Channels Through the Assisted Journey
Accessibility work in UK organisations still tends to begin with a page and end with a checklist. A team tests a form against WCAG criteria, adds captions to a video, and records the result in a compliance file. That is necessary, but it is not the same as designing an accessible service. Assistive technology does not respect the boundaries between channels. A screen reader user may begin on a website, move to a relay call, receive an email confirmation and then need a face-to-face appointment. The customer experience is one journey. The organisation often sees four separate systems.
That gap is a channel-strategy problem. Accessibility should be treated as a constraint on how enquiries move through the organisation, not as a retrofit applied to individual surfaces. When assisted journeys are audited end to end, they reveal where context is lost, where handoffs fail and where customers are quietly pushed into a second channel to complete work they had already started.
Why accessibility belongs in channel design
A channel is not just a technology. It is a route through people, process and information. Voice, web, email, messaging and face-to-face contact each carry different assumptions about identity, urgency and record-keeping. Assistive technology makes those assumptions visible. A relay service introduces turn-taking delays that an interactive voice response system may interpret as silence. A screen reader may announce a form field differently from its visual label. A customer with a cognitive impairment may need the same explanation repeated across three touchpoints without being made to feel like a new case.
Most organisations measure accessibility at the interface level. Fewer measure whether an assisted journey completes. That distinction matters in the UK, where the Equality Act 2010 sets a broad duty to make reasonable adjustments and public sector accessibility regulations have pushed digital teams to document compliance. The regulatory floor is useful. It is not a channel design method.
The assisted journey audit
The practical starting point is to follow real assisted routes rather than inspecting isolated pages. An audit should combine observed journeys, staff interviews and system evidence. It does not need to be large to be useful. A small sample of assisted enquiries, traced from first contact to resolution, will expose more than a broad survey of interface features.
The audit can run in four passes. First, map the assisted entry points: web forms, contact pages, voice menus, relay routes, email addresses and appointment booking. Second, record the context each channel collects and the context it passes on. Third, observe where the customer must repeat information, re-authenticate or explain their access needs again. Fourth, test the handoff itself: what the next agent or system knows before the customer speaks.
A useful artefact is an assisted journey log. For each step, record the channel, the customer task, the access need in play, the information carried forward and the point of friction. The log should distinguish between a technical failure and a channel failure. A form that times out is technical. A form that times out and forces a relay customer to restart the whole enquiry by phone is a channel failure.
Where context leaks
Context leaks in predictable places. A web enquiry may capture a reference number that the voice queue cannot accept. A relay call may reach an adviser who has no way to send a written follow-up. An email thread may contain an accessible format request that the face-to-face booking system never sees. A customer may be asked to confirm their identity at every hop because the organisation treats each channel as a separate trust boundary.
The result is a second-channel tax. Customers who already face additional friction are the most likely to be pushed into another route to finish the same task. They may abandon the enquiry, ask a friend or family member to intervene, or accept a worse outcome because the service is exhausting to navigate. None of this appears in a standard accessibility audit, because each individual surface may pass.
Designing for persistent context and accessible routing
Forward-looking UK service teams are beginning to treat persistent context as a design goal. That means a customer's access preferences, communication history and current case reference can follow the enquiry with consent, rather than being re-established at every boundary. It also means routing rules that understand access needs. A relay call should not be treated as an empty line. A request for a callback should not be lost when the web session ends. A captioning or plain-language preference should be visible to the adviser who picks up the case.
This is not an argument for unlimited data sharing. Persistent context needs governance, consent and retention rules. But the choice is not between surveillance and amnesia. A service can carry the minimum context needed to avoid making the customer start again.
Accessible routing also changes the commercial case. In a UK market where service differentiation is increasingly about completion rather than contact volume, an organisation that can move an assisted enquiry through the estate without forcing a restart has a genuine advantage. It reduces repeat contacts, improves first-contact resolution and lowers the risk of complaints that arise from exhaustion rather than intent.
A 2026 agenda for channel owners
The next step is to give accessibility a place in channel governance. That means naming an owner for assisted journeys, adding assisted-route testing to procurement and change processes, and measuring completion by access need rather than by channel. It also means involving assistive technology users in the design of handoffs, not only in the testing of pages.
The organisations that get this right will not describe accessibility as a compliance achievement. They will describe it as evidence that their channels actually work. In 2026, that is a more credible position than another polished accessibility statement.