Originally drafted 30 September 2026. First published 7 October 2026; revised for publication.

Consider an illustrative benefits-application journey. A citizen opens the form on a phone at a service centre. The form has no visible focus state for keyboard navigation, the error message is marked only in red, and the identity-document upload control does not explain what has gone wrong. A staff member eventually helps to complete the task. The institution may record a successful submission. The person experienced a service that was not designed to be completed independently.

That gap is often filed under compliance, branding or a later user-experience improvement. It is more consequential. Digital accessibility is a service-reliability requirement: if people cannot perceive, navigate, understand or recover a core journey, the service has failed before its underlying system has a chance to deliver. The consequence is not confined to people with recognised disabilities. It also appears when a user is on a small screen, has low vision, is stressed, uses a keyboard, works in a second language, shares a device or receives help through an assisted channel.

For organisations across Africa, this is an operational question. When an interface turns ordinary variation in vision, literacy, device use or language into a barrier, the burden reappears as repeat contact, incomplete cases, manual correction and lost trust. Accessibility belongs in the same conversation as uptime, security and data quality.

A successful click is not a successful service

Teams commonly test whether a page renders, whether a button works and whether a transaction reaches the back end. Those checks are necessary. They do not establish that a person can use the service. A screen reader user may encounter an unlabelled control. A user with limited dexterity may be unable to operate a time-limited interaction. Someone who cannot distinguish colour may miss the only indication that a form has failed. A customer using a small handset may lose the context needed to correct an error.

The UN Convention on the Rights of Persons with Disabilities, Article 9 calls on States Parties to ensure equal access to information, communications and electronic services, and to promote accessible information and communications technologies at an early stage. These treaty obligations are addressed to States Parties. The duties of a particular institution or private provider depend on the applicable national framework; Article 9 is not a uniform directly enforceable rule for every organisation. It also offers sound engineering logic. Late remediation is usually more expensive because inaccessible assumptions have already reached design systems, content, identity journeys and support scripts.

Completion is the proper unit of quality. A service owner should be able to answer whether a user can find the task, understand what is required, enter information, receive a meaningful status, correct a mistake and obtain assistance without being forced to start again. The answer needs evidence from the actual end-to-end journey, rather than a technical claim that an interface has passed an automated scan.

This changes what teams measure. Registration volume or page traffic can coexist with abandonment, reliance on informal help and incorrect submissions. Track completion and recovery at important stages, distinguish technical errors from comprehension problems, and include assisted handovers in the picture. A service that moves difficulty to a branch or call centre has not digitised the work; it has changed who absorbs it.

Standards provide a shared baseline, not a finished experience

The Web Content Accessibility Guidelines 2.2 first became a W3C Recommendation on 5 October 2023. The cited edition was published on 12 December 2024, as shown in W3C’s WCAG 2.2 publication history. They provide testable, technology-neutral success criteria for web content across devices, covering issues including visual, auditory, physical, speech, cognitive, language and neurological disabilities. W3C explicitly notes that conformance does not address every need, and recommends the current version for work on accessibility policies.

That maturity matters. WCAG 2.2 is not a vendor feature or a speculative framework. It is a well-established common reference for procurement, design and quality assurance. But it is not a substitute for observing whether a real service makes sense. A technically conformant page can still contain opaque language, request unnecessary information or create an unworkable recovery path after a failed identity check.

A useful distinction is between baseline conformance and service usability. Baseline conformance asks whether an interface exposes headings, names controls, supports keyboard operation, supplies text alternatives and meets other defined criteria. Service usability asks whether a person can complete a consequential task with confidence. An institution needs both. The first makes quality expectations explicit; the second exposes workflow, content and support failures that code inspection alone cannot see.

This is also why a one-time certification mindset is weak. Content changes, embedded vendor components change, and a new authentication step can break a journey that was previously workable. Accessibility needs to be part of component design, content governance, release testing and change management. It must be treated as a property that can regress.

African operating conditions make the design question sharper

Africa is not a single accessibility context. Languages, disability policy, public-service structures, connectivity, device availability and support arrangements vary substantially across countries and sectors. Yet several conditions make the operational case unusually clear: mobile-first access, shared and lower-spec devices, uneven bandwidth, multilingual delivery, decentralised service points and the continuing importance of agents and frontline staff.

The ITU’s Facts and Figures 2025 reports that 2.2 billion people globally remained offline, mostly in low- and middle-income countries, while quality and affordability gaps persisted despite near-universal mobile-broadband coverage. This should not be used to portray African users as a single constrained group. It does mean that an interface designed only around a current flagship phone, stable broadband and fluent reading of one language will be a poor proxy for many real service conditions.

Good accessibility often improves resilience under those conditions. Clear labels make a form easier to understand on a small screen. Logical focus order makes it easier to use a keyboard or switch device. Plain error messages reduce the need for support. Captions and transcripts help in noisy settings as well as for people who are deaf or hard of hearing. Flexible text and reflow reduce the cost of zooming and help users whose devices or browser settings differ from the design team’s.

Do not confuse simplification with exclusion. A low-bandwidth version that removes essential explanations, accessible labels or recovery options is not inclusive. Nor is a polished primary channel that assumes every difficult case can be sent elsewhere. The design task is to preserve the minimum information, control and dignity needed to complete the service in more than one operating condition.

Assisted service needs the same evidence and control

Digital accessibility is sometimes framed as a self-service matter, while assisted service is treated as an unrelated operational fallback. That division creates avoidable risk. A person who moves from a website to a call centre should not have to repeat a failed journey without a clear record of what happened. A frontline officer helping with an application needs a way to explain the status, correct an error and provide a durable receipt without assuming the user has a personal email account or continuous access to the same device.

The service model should therefore define the handover. What case reference can the person carry? What can an agent or officer see and change? Which consent, identity and access controls apply when assistance is given? How is a correction recorded? Which tasks must remain available during an outage? These are accessibility questions because they determine whether a person can actually obtain the service, rather than merely view its digital front door.

They are also governance questions. Assisted access must not weaken privacy or turn a helpful intermediary into an unaccountable holder of credentials and personal information. Use role-appropriate permissions, clear consent and receipts, limited retention and auditable correction paths. Where a person uses a shared device or seeks help from an agent, build an explicit safe exit and account-recovery route.

The strongest systems integrate these channels around one service state. They do not pretend every task can be self-served, and they do not force every exception into a manual black box. They let users move between digital and human support without losing evidence, control or dignity.

Procurement must describe the journey, not just the interface

Accessibility is frequently introduced after a platform has been chosen, through a clause that requires a supplier to “meet accessibility standards”. That language is better than silence, but it is too easy to satisfy superficially. Buyers should make the core journey visible in requirements and acceptance testing.

Specify the service outcome. Name the high-value journeys: applying, paying, submitting evidence, receiving a decision, correcting a record or escalating a complaint. State that each must be testable with keyboard-only operation, assistive technology where relevant, small-screen layouts and comprehensible error recovery. Avoid treating an accessible landing page as proof that the service is accessible.

Require artefacts that can be maintained. Suppliers should provide component guidance, accessibility test evidence, known limitations and a process for assessing changes. Where third-party identity, payment or document components are involved, identify which party owns a defect and what happens when it blocks a user from completing a protected service.

Test with people before acceptance. Automated tools can identify missing labels and structural issues quickly. They cannot decide whether instructions are understandable or a recovery route is credible. Include people with relevant lived experience and frontline staff in realistic task testing; compensate participants properly and record what the service team will change.

This prevents predictable rework. A small set of tested journeys is more valuable than an accessibility statement no one can connect to a citizen, customer or employee outcome.

Reliability includes who can use the system

The next accessibility improvement should start with the service that produces the most avoidable friction: a government application, insurance claim, mobile payment, employee portal or customer-support journey. Follow it through the conditions in which it is actually used. Test the keyboard path, zoom the interface, interrupt the session, try to correct a mistake, and see what happens when a person seeks help.

Xelius supports organisations to research service journeys, design inclusive digital workflows and build maintainable software and data systems. For teams redesigning a high-volume service, the most useful first step is usually a focused review of where users lose control, lose context or have to ask another person to complete work that the system should support.

A dependable service does not merely remain online. It remains usable when the person at the other end has different needs, devices, language patterns or support options from the team that built it. That is the standard against which digital inclusion should be designed and governed.