Accessibility

Scope note: The legal position depends on the organisation, service and users involved. Treat the article as an operational framework and verify current statutory duties separately.

For a business buyer, the useful question is not whether a supplier claims that a product is accessible. It is which user journeys have been tested, what standard or acceptance method was used, which limitations remain and who owns remediation after launch.

Accessible business software allows people with different physical, sensory and cognitive needs to complete the same essential tasks without avoidable barriers. It is not a decorative compliance layer added after development; it affects requirements, content, interaction design, testing and ongoing change.

Web Accessibility Standards for Business Applications

When a business commissions a CRM system, customer portal or internal admin tool, accessibility is frequently treated as a cosmetic add-on. In practice, it is a set of engineering constraints that determine whether people with disabilities can use the system at all. The standard most suppliers reference is the Web Content Accessibility Guidelines (WCAG), currently at version 2.2. WCAG organises requirements into four principles: content must be perceivable, operable, understandable and robust.

WCAG defines three conformance levels. Level A covers the most basic barriers — for example, every image must have a text alternative. Level AA introduces more demanding requirements, such as sufficient colour contrast and the ability to navigate entirely by keyboard. Level AAA is the strictest tier and is rarely a realistic target for complex business software, because some AAA criteria conflict with the density of information that operational tools need to display.

For most business applications, Level AA is the practical target. It is the level referenced in UK public-sector regulations and the one most procurement frameworks expect. However, quoting "WCAG 2.2 AA" in a contract means little unless the specification also states which parts of the application are in scope. A customer-facing portal should meet AA in full. An internal analytics dashboard with dense data tables still needs an explicit accessibility scope and test plan. Any genuine limitation should be documented, assessed against the applicable duty or contract, and assigned for remediation rather than treated as an informal exception.

A common mistake is assuming that using a modern front-end framework guarantees accessibility. Frameworks provide hooks — accessible component libraries, ARIA attributes, keyboard event handling — but developers still have to use them correctly. The standard is a measure of the finished product, not the technology stack.

How to Plan Accessibility in a Web Application

Accessibility planned after development is retrofitting, and retrofitting is consistently more expensive than building it in from the start. The practical point at which to introduce accessibility is during requirements definition and design, before any code is written.

Requirements and specification

When writing a specification or briefing a supplier, accessibility should appear as explicit acceptance criteria, not a vague line about "complying with WCAG." That means stating, for example, that every form field must have a visible label, that error messages must identify the field and describe the problem in text, and that data tables must use proper header markup. Vague requirements give a supplier room to interpret compliance loosely.

Design decisions

Designs create many accessibility problems before a single line of code exists. Colour contrast failures, tiny touch targets, information conveyed only through colour, and layouts that break on screen magnification all originate in design files. If your business uses an external designer, accessibility criteria should be part of the design review — not something left for developers to fix later.

Component selection

Most business applications are built from a combination of a UI component library and custom screens. If the chosen component library has known accessibility gaps — for example, a date picker that cannot be operated by keyboard — those gaps will propagate through every screen that uses the component. Evaluating a component library's accessibility track record should be a deliberate step in technology selection, not an afterthought.

Content and data

In business systems, much of the "content" is generated dynamically: status labels, error messages, notification text, column headings in exported reports. Planning accessibility means ensuring that these dynamic elements have accessible names, that status changes are announced to screen readers, and that any document or PDF generated by the system is structured with headings and alt text rather than being a flat image scan.

Practical questions to raise with a supplier

• Which WCAG level are you targeting, and for which parts of the application?
• How do you handle accessibility in your design review process?
• Which component library will you use, and what is its accessibility status?
• How will dynamic content — status updates, error messages, filtered tables — be made accessible?
• Will accessibility be tested iteratively during development or only at the end?

Accessibility Testing: What a Business Should Require

Accessibility testing is not a single activity. It is a combination of automated checks, manual inspection and assistive-technology testing, and each layer catches different problems.

Automated testing

Automated tools such as axe, Lighthouse or Pa11y can flag detectable issues, including missing text alternatives, contrast failures, empty links and invalid ARIA attributes. They are useful as a first pass but cannot determine whether labels are meaningful, the task order is logical or a screen-reader experience makes sense. Automated results must therefore be combined with manual and assistive-technology testing.

Manual keyboard testing

A tester navigates the entire application using only the keyboard — Tab, Shift+Tab, Enter, Escape, arrow keys — without touching a mouse. This immediately reveals focus-trap bugs, skipped elements, illogical tab orders and interactive components that cannot be activated. Keyboard testing is cheap to perform and catches problems that affect a significant number of users, including those with motor impairments and power users who prefer keyboard shortcuts.

Screen reader testing

A tester uses a screen reader — commonly NVDA on Windows or VoiceOver on macOS — to navigate key workflows. This is the only reliable way to discover whether the application's accessible names, headings, landmarks and live regions actually produce a coherent experience. Screen reader testing should cover the most critical paths: login, completing a form, viewing a record, submitting data and reading error messages.

What to put in acceptance criteria

Rather than a single acceptance criterion that says "the application must be accessible," break it into verifiable statements. For example: "All form fields have visible, persistent labels." "The tab order follows the visual layout." "Error messages are announced by screen readers without requiring page refresh." "Data tables have proper column and row headers." These are testable, unambiguous and harder to dismiss.

Common mistakes in testing

• Testing only the homepage or a single happy path and assuming the rest is fine.
• Relying entirely on automated tools and accepting a clean report as proof of compliance.
• Testing on a single screen reader and browser combination and assuming coverage.
• Testing only after development is complete, when fixing structural issues is most expensive.

The Public Sector Bodies Accessibility Regulations and Business Apps

The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 place legal obligations on covered UK public-sector bodies. Current GOV.UK guidance uses WCAG 2.2 AA as the minimum technical standard for public-sector websites and mobile applications, alongside an accessibility statement. A software supplier is commonly bound through procurement and contract even where the statutory duty sits with the public body.

If a business is supplying a portal, case-management system or reporting tool to a covered public body, the specification and contract should state the required WCAG 2.2 AA scope, testing evidence, known non-conformities and remediation responsibility. Do not assume that a generic promise to build an “accessible” system is sufficient.

Covered public-sector bodies must also publish an accessibility statement explaining the service’s accessibility and known problems. The project should therefore retain test results, unresolved issues, reasons, owners and remediation plans so the public body can prepare and maintain an accurate statement.

For private-sector services, the public-sector regulations do not apply merely because the service is online. However, Equality Act duties, employment obligations, sector rules and contractual requirements may still require reasonable adjustments and accessible delivery. The Act does not itself name a WCAG version, so the applicable legal position and chosen technical baseline should be verified for the service rather than presented as an automatic formula.

This is an area where the regulatory landscape shifts. The specific requirements of PSBAR, the Equality Act and any sector-specific guidance should be reviewed with current legal or compliance advice rather than relied on from memory.

How Accessibility Improves Usability for All Users

Accessibility is often framed as a requirement that benefits a minority of users. In practice, many accessibility improvements make the system more usable for everyone. This is not a philosophical point — it is an observable effect in how people interact with business software day to day.

Keyboard navigation

Keyboard accessibility is essential for people who cannot use a mouse, but it also benefits power users who process high volumes of records. A CRM user working through a list of fifty leads will move faster with consistent tab order, logical focus management and keyboard shortcuts than by switching constantly between mouse and keyboard. If the tab order is broken, every user is slowed down, not just those who rely on keyboards exclusively.

Clear labels and error messages

Screen reader users need descriptive labels and error messages to understand what is happening. So does every user who is filling in a complex form under time pressure, or who returns to a form after an interruption, or who is not fluent in the language the system uses. A form that says "Error: required field" without identifying which field fails every user, not just those using assistive technology.

Colour contrast and text size

Sufficient contrast helps users with low vision, but it also helps anyone using a laptop in bright daylight, anyone viewing a dashboard on a projected screen in a meeting, and anyone whose eyes are simply tired at the end of a working day. Text that is too small or too low in contrast forces all users to slow down and squint.

Structured content

Proper heading hierarchy and landmark regions help screen reader users jump between sections of a page. They also help any user scanning a dense admin panel to find the section they need. A well-structured page is faster to navigate for everyone, not just those using assistive technology.

Temporary and situational impairments

Include disabled users in acceptance evidence

A user with a broken arm, a user navigating a portal on a phone while holding a bag, a user in a noisy open-plan office who cannot play audio content — these are not permanent disabilities, but they create the same functional barriers. Accessibility features designed for permanent disabilities solve these situational problems as well.