Why Is Accessibility Important for UK Products?.

27% of surveyed UK digital identity services didn't know whether they met WCAG 2.0 Level AA or higher in 2024, according to the UK Government's inclusion monitoring report. That's a delivery risk, not just a reporting gap. If your team can't establish whether people can use your service, it can't confidently distinguish a customer choosing to leave from a customer being unable to continue.

Key Takeaways in Brief

Accessibility matters because disabled people represent a mainstream UK audience, inaccessible tasks lose customers, and exclusion creates reach, conversion and legal risk.

• 1. Design for a mainstream audience. Include disabled customers in discovery rather than treating their requirements as an exceptional use case.
• 2. Test before checkout. Search results, campaign landing pages, product explanations and onboarding can prevent customers from ever reaching the transaction.
• 3. Establish your legal responsibilities. Public-sector accessibility requirements are explicit. Private businesses shouldn't mistake different obligations for an exemption.
• 4. Treat barriers as defects. Missing focus indicators, unreadable controls and broken keyboard interactions belong in the engineering backlog, with owners and acceptance criteria.
• 5. Measure successful tasks. An automated checker can identify some failures, but it can't establish whether someone understands your pricing or completes an application independently.

The practical starting point is to connect exclusion evidence with commercial priorities, legal responsibilities, engineering fixes and a discovery-led launch checklist.

Who Digital Exclusion Leaves Out

In 2018, 20% of disabled adults had never used the internet, compared with 6% of non-disabled adults, according to the Office for National Statistics. These are historical figures, not an estimate of today's market. They show why moving a service online doesn't automatically make it available to everyone.

The audience is substantial: the Family Resources Survey reported 16.8 million disabled people, 25% of the UK population, in 2023–2024, with the working-age proportion rising from 16% in 2013–2014 to 24% in 2023–2024. That doesn't mean every disabled person encounters every accessibility barrier. It means a delivery team can't reasonably assume a narrow set of abilities across its audience.

Availability isn't the same as access

Say a banking app requires someone to drag a small slider precisely to confirm a payment. A customer with a tremor may understand the task and have sufficient funds, yet still be unable to complete it. A form that expires while a screen reader user is reviewing its instructions can discard an otherwise valid application.

A shop with a step at its entrance is open, but some customers can't enter. A website with inaccessible authentication creates the same distinction between theoretical availability and practical access.

Discovery rule: Describe what people need to accomplish and how they interact, rather than treating a diagnosis as a complete set of requirements.

Social participation belongs in that discussion too. Resources such as Special Bridge's dating sites for disabled people provide context for teams considering relationships and community, not only transactional services. Their relevance isn't proof of any particular accessibility standard, but a reminder that independence includes ordinary social choices.

Build recruitment around interaction needs, supported by user-centred design:

• Screen reader users who move through headings, landmarks and control names.
• Keyboard-only users who need visible focus and a sensible flow order.
• People with low vision who enlarge content or change display settings.
• People managing cognitive load who need clear instructions and recoverable mistakes.
• People on older devices or limited data whose service journey must remain workable.

The Business Case for Accessible Products

Accessibility protects the route from interest to action. A customer may first encounter your service in a search result, comparison page or campaign. If the landing page fails to explain what you offer, the journey can end before registration.

Reach and conversion start before registration

If your acquisition plan includes disabled customers, check whether they can use the pages that introduce and explain your service. Small text, videos without accessible alternatives, or controls that require precise pointer use can make the audience you reach larger than the audience that can act.

In UK Government research on private-sector accessibility, 36% of disabled respondents encountering technology-sector barriers met them while first searching or researching, rising to 50% when finding information about a suitable product or service. Improving a payment button cannot fix an inaccessible comparison tool earlier in the journey.

The problem can continue into purchasing and use. 26% of respondents to a 2024 UK Government survey reported barriers or accessibility issues when buying or using technology products or services in the previous twelve months, according to its published data tables.

For a subscription product, test whether customers can check compatibility, understand recurring charges and find cancellation information. If important pricing conditions appear only in an inaccessible tooltip, a polished page can still leave customers without the information they need.

Search clarity and commercial risk

Descriptive headings, meaningful links and logical page structure help assistive technology interpret content. They also make a page's information clearer to search engines, without guaranteeing higher rankings.

Poor accessibility can also create legal and reputational risk. Resolving a complaint is harder when no one owns the affected component, support cannot offer another route, and marketing continues sending customers into a broken journey.

An accessible entrance is like a wider shop door. You don't need a larger shop to let more customers through.

Assess complete journeys, not just home-page screenshots. Arch's work includes mobile projects such as Boiler Juice, Findr and Deploy, as well as the web project Cultaholic. These provide product contexts to consider, not substitutes for an accessibility assessment.

For an internal business case, distinguish:

• Observed barriers from assumptions based on traffic volume.
• Usability-related support contacts from unrelated account enquiries.
• Marketing-page exits from failures in registration, payment or ongoing use.

The UK Legal Duty Behind Accessibility

The Equality Act 2010 recognises disability as a protected characteristic and requires organisations to consider reasonable adjustments. That duty matters whenever a service's design makes it harder for disabled people to access or use it. A digital service is still part of the service.

For private businesses, the practical question is whether their service arrangements disadvantage disabled people and what reasonable adjustments are needed. A regulation does not have to name a website for accessibility to matter.

Public-sector requirements are explicit

The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018, made by the Cabinet Office, set specific requirements for covered public-sector bodies. They must meet the applicable accessibility requirements and publish an accessibility statement.

Teams should establish whether their organisation is covered, which exemptions apply and what requirements govern the service. An accessibility statement is not a certificate of compliance. It should accurately describe the service's accessibility and give users a useful contact route.

The responsibilities differ by organisation:

• Public-sector organisations must assess and address accessibility, and publish a statement.
• Private-sector organisations must consider their Equality Act responsibilities; the public-sector regulations do not define the full legal position.
• Delivery teams need testable requirements, evidence of checks and clear ownership of unresolved barriers.

Include content and internal services

Accessibility reviews should cover more than customer-facing page templates. Procurement, recruitment, workplace training and embedded media can also create barriers.

For video used in workplace training, check caption quality for workplace training. Review caption accuracy and timing, and make sure meaningful non-speech audio is represented. Automatically generated captions need human review, especially when specialist terminology could change the meaning.

Legal responsibility and technical conformance are different. A standards assessment gives teams structured evidence about an interface, but it does not replace an understanding of the service, its users or the adjustments they may need.

Common Barriers and How to Fix Them

Government Digital Service monitoring covered 1,203 public-sector websites and 21 mobile apps between January 2022 and September 2024. The government's monitoring report recorded 70% overall WCAG compliance and identified the leading issues as Focus Visible, 13.3%; minimum colour contrast, 13.0%; keyboard operation, 10.8%; reflow, 9.2%; and accessible naming, roles and values, 8.6%, while identifying WCAG 2.2 Level AA as the public-sector benchmark.

Those percentages describe shares of identified issues, not the proportion of all UK websites with each defect. The engineering lesson is more useful than a broad claim about national website quality: recurring interface failures have concrete fixes.

Repair the interaction, not just the appearance

• Focus visible. Removing the browser outline without replacing it leaves keyboard users unable to locate themselves. Add a clearly visible focus indicator, then tab through the journey and check that sticky banners don't obscure it.
• Minimum colour contrast. Pale text and subtle control boundaries can disappear against their backgrounds. Check actual colour combinations with a contrast analyser, including error, hover and disabled states. Don't rely on how a design looks on a bright studio monitor.
• Keyboard operation. Click handlers on non-interactive elements can create controls a keyboard user can't reach. Prefer native buttons and links. Test menus, dialogs and date pickers, including closing them and returning focus correctly.
• Reflow. Fixed-width containers and inflexible layouts can clip content when users enlarge it. Use responsive layouts and inspect the actual reading order at increased zoom. Shrinking the text to make everything fit defeats the purpose.
• Names, roles and values. An icon-only button without a meaningful name gives assistive technology little useful information. Use semantic markup, persistent labels and correctly exposed states. Listen to the control with a screen reader rather than inspecting its appearance alone.

Form errors deserve equal attention: identify the affected field, explain how to fix it and preserve valid information already entered.

Combine automation with human checks

Run axe-core or an equivalent automated checker in the build pipeline, then test keyboard navigation, screen reader behaviour, zoom and reflow, followed by manual WCAG review. Use NVDA on Windows and VoiceOver on Apple devices where relevant to your supported platforms. Automated checks don't establish whether instructions make sense.

Only 13% of respondents in a government survey of 525 disabled adults agreed that new technology is often designed with disabled people in mind, and 39% of respondents not using assistive technology didn't know what was available, according to Digital inclusion for connection. Don't make successful use depend on discovering an unfamiliar workaround.

For learning interfaces, Queens Online School's discussion of online lesson design for diverse learners offers useful context for presenting information through different routes. For apps, make these decisions during mobile app design, not after visual approval.

At Arch, accessibility, speed and security are tested before anything goes public. Accessibility, performance and security checks run alongside device testing on iOS and Android before launch.

Measure Accessibility and Start With Discovery

Track task completion by user need, drop-off by task, usability-related support contacts and sessions encountering known barriers. Include marketing and product-information pages, not only checkout. Define what counts as success before collecting events, otherwise your dashboard may record button clicks while missing failed outcomes.

Segment carefully. Ask participants about relevant interaction needs during research, with consent, rather than inferring disability from browsing behaviour. In production analytics, record the affected component or failed task without collecting unnecessary sensitive information.

A launch sequence with clear ownership

1. Audit the whole service during discovery. Follow the route from acquisition to support. Ask about device ownership, data costs, built-in accessibility features and onboarding help. A technically compatible page won't solve an unaffordable connection or missing support route.
2. Write acceptance criteria into user stories. Replace “must be accessible” with observable behaviour. A dialog should receive focus when opened, keep keyboard interaction within it while active, close predictably and return focus to its trigger.
3. Test a clickable prototype before engineering handover. Recruit disabled participants whose interaction needs match the journey. Our UI/UX process is research-led and tested with users before handover to engineering. The design stage turns scope into a clickable prototype so clients can change direction before the build becomes expensive to change.
4. Check each release candidate. Combine automated checks with keyboard, screen reader and zoom tests. Use appropriate usability testing methods to separate a technical defect from unclear language or an unhelpful service policy. Run automated regression checks on builds, and repeat relevant manual checks when components or journeys change.
5. Publish an accurate accessibility statement. Name the standard assessed, explain known gaps and give a working contact route. Assign someone to receive reports, reproduce problems and communicate progress. Publishing a mailbox nobody monitors doesn't provide useful support.
6. Monitor after launch and prioritise blocked tasks. I recommend keeping a focused review period for at least three months, then incorporating accessibility into ongoing maintenance. Fix failures that prevent essential actions before cosmetic inconsistencies, while checking whether a shared-component repair can remove barriers across several journeys.

Make the trade-offs explicit

A bespoke control may fit a visual concept but require considerably more implementation and testing than a native alternative. Choose the custom version only when its user benefit justifies that extra responsibility.

Release decision: A blocker in an essential task needs an owner and a remedy, not a note hidden in the launch checklist.

Prototype testing makes structural changes easier because teams haven't yet committed the full implementation. It won't uncover every assistive-technology issue, so validate the coded experience too. This week's decision should be concrete: book an accessibility review of your next build before development starts.

Frequently Asked Questions About Accessibility

Is accessibility only for disabled users?

No, accessibility addresses disabled people's access needs while also improving usability in other circumstances. Captions help someone watching without sound, good contrast helps in poor light, and clear structure supports people reading on small screens. Keyboard support can help someone temporarily unable to use a mouse. These wider benefits matter, but they shouldn't displace the central requirement: disabled people must be able to use the service independently wherever possible.

Does WCAG 2.2 Level AA apply to private UK businesses?

It's a widely used technical benchmark, not a substitute for understanding a private business's Equality Act responsibilities. The distinction between public-sector regulations and private-sector duties matters: don't assume the same regulatory mechanism applies to every organisation. Use the legal distinction explained above to frame your requirements, then obtain advice where your service or contractual position needs interpretation. A conformance assessment helps make requirements testable, but it doesn't settle every reasonable-adjustment question.

Which accessibility improvements best protect acquisition and conversion?

Start with accessible discovery, understandable product information and reliable routes to help. Customers need to establish what you offer, whether it works with their setup, what it costs and how to proceed. Test pricing explanations, comparison tools and compatibility details alongside registration. Then prioritise the barriers that prevent a purchase decision or block an essential action. Post-launch interface repairs alone won't recover customers who couldn't understand the offer in the first place.

What if customers can't afford assistive technology?

Provide lightweight journeys, compatibility with built-in device features and a usable human-support alternative. The government's digital inclusion report found that 40% of surveyed people who go online used assistive technology, while only 25% of assistive-technology users could comfortably afford it. Don't require paid software to complete an ordinary task. Test low-bandwidth paths and recruit people with different levels of technology access, rather than assuming everyone has a current device and specialist tools.

About the Author

Hamish Kerry writes about digital products for Arch, including accessibility, apps, websites and emerging technologies.

Hamish's LinkedIn

Arch offers discovery, research-led design, mobile app development and web development, with accessibility built into delivery rather than deferred until launch. Visit Arch to discuss your next product, identify journeys exposed to accessibility failures and plan a review before engineering begins.