Accessibility is Not Optional

Accessibility Is Not Optional

Imagine that a bank launches a new online mortgage application. The project has been delivered on time, the calculations are correct, the security testing is complete and the business is delighted. Applicants can upload documents, confirm their details and submit the form without speaking to an adviser.

Then a customer who uses a screen reader tries to apply. The form contains several fields without meaningful labels. An error message appears visually but is not announced. The customer cannot tell which information needs correcting and eventually abandons the application.

From the project's perspective, the feature has been delivered. From the customer's perspective, the service is unavailable.

And from the organisation's perspective, the problem may be considerably more serious than an ordinary usability defect. It may raise questions about compliance with disability discrimination law.

This is why accessibility deserves more attention from Business Analysts. It is often introduced as a non-functional requirement, alongside performance, security, availability and maintainability. But accessibility is not merely a technical quality attribute to be considered after the functional requirements have been agreed. It influences who can use a service, how a business process operates and whether the organisation is meeting its obligations.

Which Disability Act Are We Talking About?

People sometimes refer to the 'Disability Act' when discussing accessibility requirements. In Great Britain, the principal legislation is the Equality Act 2010. It consolidated and replaced much of the earlier anti-discrimination legislation, including the Disability Discrimination Act 1995. Northern Ireland has a different legal framework, in which the Disability Discrimination Act 1995, as amended, remains important.

The Equality Act protects people against unlawful discrimination in employment, services and other areas of life. Disability is one of its protected characteristics. In broad terms, the Act defines disability by reference to a physical or mental impairment that has a substantial and long-term adverse effect on a person's ability to carry out normal day-to-day activities. There are additional statutory rules and specific provisions, so a Business Analyst should not attempt to make legal determinations about an individual's status.

For analysis work, the more useful question is this: what barriers could our proposed change create or perpetuate, and what must the organisation do about them?

Consider three ways that discrimination can become relevant to requirements. Direct discrimination involves less favourable treatment because of disability, subject to the Act's specific rules. Indirect discrimination may arise when an apparently neutral rule or practice places disabled people sharing a particular disability at a disadvantage and cannot be objectively justified. A failure to make reasonable adjustments can itself be unlawful.

That last concept is particularly important because it turns the conversation from avoiding deliberate discrimination to actively identifying and addressing barriers.

The Duty to Anticipate Barriers

For service providers and those exercising public functions, the duty to make reasonable adjustments is anticipatory. In other words, an organisation should not simply wait until a disabled customer encounters a problem and complains. It must consider in advance the barriers disabled people may face and take reasonable steps to address them.

The law recognises that what is reasonable depends on the circumstances, including the effectiveness and practicality of an adjustment and the resources available. It does not mean that every conceivable adjustment must be made in every situation. But neither does 'we haven't received any complaints' establish that the organisation has met its duty.

For a Business Analyst, this has a striking implication. Requirements discovery is precisely the stage at which future barriers should be investigated. If the team discovers accessibility problems only after deployment, the organisation may already have embedded those problems in its systems, business processes, contracts, training and customer communications.

Disability Is Not Just About Wheelchair Access

Ask a group to describe an accessible building and they may mention ramps, lifts and wider doorways. Those are important, but the picture is incomplete. The same is true of digital services.

A person with a visual impairment may use a screen reader or magnification software. Someone with limited dexterity may rely on a keyboard, switch device or voice control rather than a mouse. A deaf user may need captions or a text alternative to spoken instructions. A person with dyslexia may benefit from clear language and predictable presentation. Someone with a cognitive impairment may find complicated navigation, unexplained jargon or short time limits especially difficult.

Some disabilities fluctuate. Others are not immediately visible. Different people with the same diagnosis may have different needs. And a single person may face several interacting barriers.

Accessibility also helps people who would not necessarily meet the legal definition of disability: somebody with a temporary injury, a parent holding a baby while using a phone, or a customer trying to read a screen in bright sunlight. These broader benefits strengthen the business case, but they should not be confused with the specific legal protections afforded to disabled people.

Accessibility Begins with Stakeholder Analysis

Business Analysts routinely ask who the stakeholders are, what they need and how a proposed change will affect them. Yet stakeholder lists can be dominated by sponsors, managers, subject-matter experts and the employees who already use the existing system.

That creates a dangerous blind spot. People who cannot use the existing service may be absent from the very workshops intended to improve it. Their absence can then be mistaken for a lack of requirements.

Imagine a local authority replacing its appointment-booking process. The workshop includes the service manager, reception staff, the IT team and a representative sample of existing online users. Everybody agrees that moving all bookings online will save time and reduce costs.

But what about residents who cannot operate the proposed interface, cannot use a telephone, or need information in an alternative format? If those perspectives are missing, the analysis may produce a process that is efficient for the organisation but inaccessible to some of the people it serves.

Good stakeholder analysis therefore asks not only who currently uses this service? but also who needs to use it, who struggles to use it, and who has been excluded altogether?

That does not mean asking disabled participants to speak for everyone with a similar condition. It means involving people with varied lived experience, using accessible research methods, and supplementing their insights with appropriate accessibility expertise. Research sessions, workshops, prototypes and feedback channels must themselves be accessible.

Requirements Elicitation Must Be Accessible Too

There is little point inviting a disabled stakeholder to a workshop if the workshop materials cannot be used with their assistive technology. A poorly captioned video call, an inaccessible PDF, a visual-only whiteboard or a meeting held in an inaccessible room can prevent someone from contributing.

The Business Analyst should consider the format of invitations, documents, meeting facilities, communication channels and research activities. Participants may need reasonable adjustments, and those arrangements should be handled respectfully, without unnecessary requests for sensitive personal information.

Accessible elicitation is not an administrative courtesy. It affects the quality of the evidence on which the requirements are based.

From Vague Aspirations to Testable Requirements

Consider the following requirement:

'The new application must be accessible to all users.'

It sounds admirable. Unfortunately, it gives designers, developers and testers very little to work with. What does accessible mean? Which interactions are in scope? How will success be assessed? What happens when a user makes a mistake?

A more useful set of requirements might specify that every essential task can be completed without a mouse; that form fields have programmatically associated labels; that validation errors identify the affected fields and explain how to correct them; that instructions are not conveyed by colour alone; and that users can enlarge text without losing essential content or functionality.

Each requirement should be supported by appropriate acceptance criteria and linked to the relevant user journey. For example, an acceptance criterion might state that a keyboard-only user can complete, review and submit an application, with a visible focus indicator and a logical sequence of controls. Another might verify that a screen reader announces a validation error and its relationship to the relevant input.

These examples do not constitute a complete accessibility specification. They illustrate how a broad quality objective can be translated into observable behaviour.

Where WCAG Fits into the Picture

For websites and web applications, the most widely recognised technical reference is the Web Content Accessibility Guidelines, or WCAG, published by the World Wide Web Consortium. WCAG 2.2 organises accessibility around four principles: content should be perceivable, operable, understandable and robust.

Perceivable means information must be presented in ways people can perceive. For example, an image conveying essential information needs an appropriate text alternative. Operable means users must be able to navigate and interact with the interface, including through supported keyboard interaction. Understandable means information and operation should be clear and predictable. Robust means content should be compatible with a range of user agents and assistive technologies.

WCAG defines testable success criteria at different conformance levels. A Business Analyst does not need to memorise every criterion, but should understand what the chosen standard means for scope, acceptance criteria, procurement and verification. Accessibility specialists, designers, developers and testers can help translate the standard into implementation and test evidence.

In the UK, the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 impose specific obligations on public-sector websites and mobile applications, subject to defined exceptions and qualifications. Current GOV.UK guidance uses WCAG 2.2 Level AA as the standard to meet and requires an accessibility statement explaining the service's accessibility.

There is an important distinction here. WCAG is a technical standard, not the Equality Act itself. A private-sector service may have Equality Act obligations even when the public-sector accessibility regulations do not apply to it. Equally, passing a WCAG audit does not automatically settle every legal question about reasonable adjustments or discrimination.

Accessibility Is a Journey, Not a Checkbox

Consider the mortgage application again. The landing page may meet the team's accessibility criteria, but what happens when the applicant opens a document-upload widget supplied by another company? What if a CAPTCHA cannot be completed using assistive technology? What if the final agreement is available only as an inaccessible PDF?

The user does not experience these as separate systems with separate owners. They experience one application journey. If an essential step is inaccessible, the journey may fail.

This is why accessibility analysis must follow the end-to-end business process. It should cover notifications, identity checks, document handling, payments, error recovery, support arrangements and communications after submission. It may also need to cover face-to-face or telephone alternatives, depending on the service and the organisation's obligations.

Requirements traceability is useful here. A high-level accessibility objective can be traced to user journeys, individual requirements, acceptance criteria, test evidence and unresolved risks. Without that connection, accessibility can become a statement in a policy document that nobody can demonstrate has been implemented.

When Accessibility Competes with Cost and Deadlines

Business Analysts often facilitate prioritisation. In an Agile project, that might involve MoSCoW, value-versus-effort analysis or backlog ordering. Accessibility creates an important challenge: not every requirement is a discretionary feature.

Imagine a Product Owner arguing that keyboard accessibility should be a 'Could Have' because the team has a deadline to meet. The BA should not simply accept that classification. The team needs to establish the applicable legal and contractual obligations, the impact on affected users, the risks and any genuinely available alternatives.

That does not mean every proposed enhancement has identical urgency or that cost is legally irrelevant. The law's reasonable-adjustment duty is contextual, and public-sector regulations have their own provisions and exceptions. But a delivery deadline or a backlog label cannot, by itself, remove a legal obligation.

There is also a commercial argument for considering accessibility early. Retrofitting an inaccessible design may require changes to shared components, navigation, content, third-party products, testing practices and staff training. Addressing barriers during analysis and design can avoid expensive rework.

Procurement Can Import Accessibility Problems

Not every solution is built from scratch. Organisations buy customer portals, HR systems, learning platforms, payment services and specialist applications. It is tempting to assume that accessibility is the supplier's responsibility.

But buying a product does not remove the organisation's need to understand how people will use the resulting service. Accessibility should be addressed in procurement requirements, supplier demonstrations, contractual acceptance criteria and ongoing support arrangements.

A vendor may provide an accessibility conformance report or claim compliance with a standard. That is useful evidence, but it should not be accepted uncritically. Which product version was assessed? Which features were excluded? Were the actual workflows being purchased tested? What defects remain? How will accessibility be maintained after upgrades?

The Business Analyst can help ensure these questions are asked before the contract is signed, rather than after users discover that a critical feature cannot be operated.

Testing with Real People Matters

Automated accessibility tools are valuable. They can detect certain missing labels, contrast problems and structural errors. But they cannot reliably establish whether an entire service is understandable, whether a task is practical using assistive technology or whether the experience creates unnecessary barriers.

That requires a combination of automated checks, expert assessment, manual testing and research with disabled users. The precise mix depends on the service, its risks and the standards it must meet.

Business Analysts can contribute by ensuring the right scenarios are tested. Can a user recover from a mistake? Can they understand why a document was rejected? Can they obtain assistance without being forced through the same inaccessible channel? Does an alternative route genuinely provide access, or does it introduce unreasonable delay, loss of privacy or dependence on another person?

And when a defect is found, it should be assessed in terms of the user's ability to complete the business task, not merely the number of screens affected. A small visual change may be cosmetic for one user but prevent another from completing an essential transaction.

Accessibility Goes Beyond the Screen

Although WCAG receives considerable attention, accessibility is not exclusively a web-design issue. A new business process may require customers to attend an appointment, speak on the telephone, read a letter, sign a document or use a self-service terminal. Each step can introduce barriers.

Internal systems matter too. An inaccessible staff application may disadvantage disabled employees, even if customers never see it. Employment-related duties and the treatment of employees require their own consideration; the anticipatory service-provider duty should not simply be assumed to operate identically in every employment situation.

A useful BA technique is to walk through the entire process from the perspective of people with different access needs. At each step, ask what the person must perceive, understand, decide and do. Then ask what happens if the assumed method of interaction is unavailable to them.

That approach can reveal requirements for alternative communication formats, accessible correspondence, appointment arrangements, staff procedures, support channels and training. Some of these will be functional requirements, some non-functional, and some changes to the business process itself.

What the Business Analyst Should Actually Do

None of this means that a Business Analyst must become a solicitor, an accessibility auditor or an expert in every assistive technology. It means recognising accessibility as a business concern that needs explicit ownership, informed investigation and evidence-based decisions.

At the beginning of an initiative, identify the applicable regulatory, contractual and organisational obligations with the people qualified to interpret them. During stakeholder analysis, consider whose experience may be missing. During elicitation, make participation accessible and investigate complete user journeys. During requirements analysis, replace vague statements with specific, testable expectations. During procurement and delivery, challenge unsupported assumptions about compliance. During evaluation, examine whether disabled people can actually achieve the intended outcomes.

And when requirements change, assess their accessibility impact. A seemingly small alteration to a form, authentication process or workflow can reintroduce a barrier that had previously been removed.

Return to the Customer Who Could Not Apply

Let's return to the bank's mortgage application. The original project team treated accessibility as a late technical check. The interface looked polished, the calculations worked and the security controls passed. Yet a customer using a screen reader could not complete the process.

Now imagine a different project. During discovery, the Business Analyst identifies applicants who use assistive technology as stakeholders whose needs must be explored. Research reveals that form labels, error handling, document uploads and confirmation messages are critical points in the journey. The team agrees an appropriate accessibility standard, develops acceptance criteria for essential interactions and tests the full process before launch.

The result is not simply a better website. It is a service designed with a wider and more realistic understanding of its customers. It reduces the likelihood of exclusion, costly rework and avoidable legal risk. Most importantly, it allows people to carry out the task the service was created to support.

That is what good business analysis is supposed to achieve: understanding the real need, recognising constraints and ensuring that the proposed change delivers worthwhile outcomes.

Where to Find Authoritative Guidance

For UK projects, useful starting points include the Equality Act 2010, GOV.UK guidance on public-sector website and app accessibility, and the W3C Web Content Accessibility Guidelines 2.2. The Equality and Human Rights Commission provides guidance relevant to equality law in Great Britain. Projects in Northern Ireland should consult the Equality Commission for Northern Ireland and the applicable legislation.

These sources help teams identify what to investigate, but they do not replace legal advice about a particular service or situation.

What Should the Business Analyst Take Away?

Accessibility is sometimes treated as a specialist concern that belongs to designers and testers. Their expertise is essential, but waiting until design or testing to consider accessibility is too late.

The BA has an opportunity to influence the problem definition, stakeholder representation, scope, requirements and acceptance criteria before inaccessible assumptions become embedded in the solution. That opportunity comes with a professional responsibility to ask questions that others may have overlooked.

Because a requirement is not truly successful merely because the system performs the specified function. It must also be considered in the context of the people who need to use it, the business outcome it supports and the obligations the organisation must meet.