A customer portal can have a modern interface and still prevent someone from completing a basic task. A payment button may be difficult to reach with a keyboard. An error message may appear visually without being announced by a screen reader. A booking form may discard information when a user takes longer than expected. These failures concern the product itself, rather than simply the appearance of a website.
For companies, the practical question is whether customers and employees can complete the activities the technology was built to support. Accessibility therefore belongs alongside security, reliability and usability when teams decide what to build and how to release it. An accessibility programme becomes more useful when it connects technical requirements with specific journeys, delivery responsibilities and continuing maintenance.
This is an operational argument, rather than a claim that every accessibility improvement will generate measurable sales growth. The commercial effects depend on the product, its users and the barriers being removed. Companies can make a stronger case for investment by identifying those barriers and assessing the consequences of leaving them in place.
Start with the task people need to complete
Product planning often begins with features: a dashboard, an upload function or a new account menu. An accessibility review should also consider the task behind each feature. Can a person find a bill, understand the amount due, choose a payment method and confirm that payment succeeded? A technically accessible component is valuable, but the surrounding sequence also needs to work.
The Web Content Accessibility Guidelines 2.2, published by the World Wide Web Consortium, provide testable requirements organised around making content perceivable, operable, understandable and robust. They cover a wide range of disability-related needs, although the standard explicitly acknowledges that it does not address every individual need.
For product managers, this framework provides a common reference for design and acceptance criteria. It should be applied to complete activities, including authentication, error recovery and confirmation. A page that works well in isolation can still be part of a journey that fails when an external payment window opens or a customer must download an inaccessible document.
An initial review can concentrate on the journeys with the greatest consequences for users: accessing an account, paying, cancelling, requesting support or obtaining essential information. This is a practical way to organise remediation, rather than a reason to ignore less frequently used pages indefinitely.
Give accessibility a place in the business case
The W3C business case for digital accessibility discusses potential benefits including broader market reach, innovation and reduced legal risk. These are reasons to investigate investment, rather than guaranteed outcomes for an individual company. A credible internal proposal should explain which users encounter barriers and how those barriers affect the service.
For a subscription business, an inaccessible account page might prevent a customer from updating payment information. For an employer, an inaccessible procurement application could require an employee to ask a colleague to complete routine work. For a retailer, unclear form errors might increase calls to customer support. These are illustrative possibilities, not findings about named companies.
Teams should avoid estimating benefits from the total number of people with disabilities alone. That population is diverse, and a single design change will not address every need. A more useful analysis identifies the affected task, the expected improvement and the evidence that could establish whether the change worked.
The cost assessment should include design, engineering, research, training and maintenance. It should also consider shared components. Improving a form field used across many journeys may have wider value than correcting one isolated page. However, the most widespread defect is not always the most consequential; a less common barrier may entirely prevent access to an essential service.
Build requirements into the work that already happens
Accessibility becomes easier to manage when it is part of ordinary delivery rather than a separate review at the end. A product brief can describe the required task and relevant accessibility expectations. A design review can examine how focus moves through a dialogue. An engineering ticket can include the behaviour expected when an input is invalid.
The UK government Service Manual describes accessibility as a responsibility shared across a service team and calls for it to be considered in budgeting and delivery. Its specific requirements apply within the government service context. The wider organisational lesson is useful for companies: responsibility needs to reach the people making daily product decisions.
A company can assign a product owner to maintain the accessibility backlog, while designers, developers, content specialists and testers own the parts of delivery they control. A central specialist can provide guidance and review difficult issues. That specialist should have a clear route for raising concerns, especially where a release would introduce a serious barrier.
Acceptance criteria should be specific enough to verify. “Make this screen accessible” gives a team little information about the intended result. “Users can reach and operate the controls with a keyboard, and the error is associated with the relevant field” creates a clearer basis for implementation and review. Relevant criteria should still be checked against the selected standard and the actual interaction.
Test with tools and with people
Automated checks are useful because they can identify some recurring defects quickly and consistently. They can be integrated into development work and repeated after changes. However, a tool cannot determine every aspect of whether a person can understand and complete a task.
The W3C overview of accessibility evaluation makes this limitation explicit: no tool alone can determine whether a site meets accessibility standards, and knowledgeable human evaluation is required. It also recommends evaluating accessibility early and throughout development.
A sensible testing plan combines automated checks with manual review and research involving people with relevant access needs. These activities answer different questions. A scanner may detect a missing label; a manual review can assess keyboard operation; a participant can show that an interaction remains confusing despite technically correct labels.
Test reports should describe the environment and scope. A finding from one browser, one assistive technology and one participant is evidence about that combination. It should not be presented as proof that all users can complete the same journey. Conversely, a single severe problem may justify action even when the research sample is small.
Teams can make reports more useful by documenting the failed task, steps to reproduce the problem, user consequences and affected component. The report should also distinguish a confirmed standards failure from a broader usability concern. Both may merit attention, but the distinction helps teams select and verify a remedy.
Involve users before the design is fixed
Research late in a project can reveal barriers when there is little time to change the underlying approach. Early research creates more room to consider alternatives. It can challenge assumptions about how customers navigate, interpret instructions or recover from mistakes.
The W3C guidance on involving users in web projects recommends involving people with disabilities early and throughout development. It explains that this can help teams understand how people use assistive technologies and adaptive strategies.
Participants should be chosen for the questions the research needs to answer. One person's experience does not represent every disability, every level of technical confidence or every way of accessing a service. A team investigating an upload process may need to examine several interaction methods and different levels of familiarity with the task.
Research should be accessible too. Invitations, consent materials, session arrangements and prototype access can affect who is able to participate. Researchers need to explain what is being tested and allow participants to use suitable equipment where feasible. Otherwise, the research process itself may filter out the people whose experience would be most informative.
An important outcome is a change in product decisions. If repeated research findings never alter the backlog, the organisation is gathering evidence without acting on it. Teams should record which finding led to which change and return to the task after implementation to see whether the barrier was actually removed.
Treat external components as part of the service
Many digital journeys rely on suppliers for identity checks, payment processing, chat support or document signing. These components can affect accessibility even when the company's own pages have been reviewed. The user experiences the combined service.
Before selecting a supplier, a company can ask for accessibility documentation, known limitations and evidence about the specific product version under consideration. It can also test the component in the intended journey. A general statement about a supplier's commitment is less informative than evidence showing how the required interaction behaves.
Contracts and procurement discussions can establish how defects are reported, who investigates them and how updates are communicated. Product teams should know whether they can configure the component, provide an equivalent route or obtain a fix from the supplier. Those options have different costs and implications.
Consider a hypothetical booking service that introduces an external identity check. Its internal form passes the team's review, but the identity step cannot be completed through the interaction method used by a participant. The appropriate response is to investigate that step and the supplier relationship. Repeating checks on the internal form would leave the actual barrier unresolved.
Measure completed journeys and recurring defects
An accessibility dashboard should support decisions. Counts of issues found and closed can show activity, but they do not establish that the most important barriers have been removed. Ten small corrections may leave one task-blocking defect untouched.
Teams can track the accessibility of priority journeys, the age of unresolved serious defects, recurrence in shared components and the results of retesting. Customer reports can add useful evidence, especially when they describe a concrete task. They should feed into investigation rather than being treated only as support tickets.
Where companies measure completion rates or support demand, they should be careful about interpretation. A change in those measures may reflect several factors, including pricing, traffic quality or a separate product release. Accessibility work should not receive credit for every improvement without evidence connecting the two.
A review cadence can help prevent regressions. New content, interface changes and supplier updates may introduce barriers after an initial audit. Teams should define when checks are repeated and who reviews exceptions. An issue accepted temporarily should have an owner, a reason and a planned review date, rather than quietly becoming permanent.
Questions product leaders should ask
Does a successful automated scan mean the product is accessible
No. Automated checks cover only part of the assessment. Manual evaluation and research are needed to examine behaviours, meaning and task completion that tools cannot establish on their own.
Should companies wait for a complete redesign
A redesign can provide an opportunity to address underlying problems, but existing barriers still affect users. Teams can investigate urgent defects, improve shared components and build requirements into ongoing releases while a larger redesign is planned.
Who should own accessibility
A named owner should coordinate priorities and reporting, while the people responsible for product, content, design and engineering address accessibility within their work. Clear escalation is needed when a serious barrier remains unresolved.
Is an alternative support channel enough
It can help a person obtain assistance, but its existence does not demonstrate that the digital journey is accessible. Teams should assess the original barrier, the adequacy of the alternative and any applicable requirements rather than assuming a phone number solves every problem.
Make accessibility part of product quality
Digital accessibility becomes more durable when it is connected to how a company plans, builds, buys and maintains technology. Standards provide a useful reference, but the operating model determines whether findings lead to improvements.
The practical goal is a service that people can use to complete the activities it promises. That requires evidence from real journeys, responsibility for defects and continued review as the product changes. Companies that establish those habits can make better decisions about both their technology and the experience it delivers.
Reference links
1. World Wide Web Consortium — Web Content Accessibility Guidelines 2.2
2. World Wide Web Consortium — The Business Case for Digital Accessibility
https://www.w3.org/WAI/business-case/
3. World Wide Web Consortium — Evaluating Web Accessibility Overview
https://www.w3.org/WAI/test-evaluate/
4. World Wide Web Consortium — Involving Users in Web Projects for Better Easier Accessibility
https://www.w3.org/WAI/planning/involving-users/
5. UK Government — Making your service accessible an introduction