A member of staff cannot submit an expenses claim using a keyboard. A parent cannot read a school notice through a screen reader. A customer abandons an online form because an error message only appears in red. These are operational failures, not edge cases. This software accessibility compliance guide explains how UK organisations can identify risks, improve digital services and make accessibility part of everyday software delivery.
What software accessibility compliance means
Accessible software allows people with different access needs to complete the same essential tasks independently. That includes people who use screen readers, magnification, voice control, keyboard-only navigation or alternative input devices. It also includes people with dyslexia, low vision, hearing loss, reduced dexterity, cognitive impairments and temporary limitations such as a broken arm.
Compliance is not achieved by adding an accessibility statement or running an automated scan once. It means designing, building, buying and maintaining software so that barriers are found and addressed before they prevent someone from working, learning or accessing a service.
For many organisations, the practical benchmark is the Web Content Accessibility Guidelines, usually referred to as WCAG. WCAG 2.2 at AA level is widely used for websites, web applications and digital portals. It covers areas such as keyboard access, colour contrast, clear labels, visible focus indicators, meaningful page structure and understandable error messages.
The legal position depends on the organisation and the service in question. UK public sector bodies must meet specific accessibility requirements for websites and mobile applications under the Public Sector Bodies Accessibility Regulations 2018, subject to limited exemptions. The Equality Act 2010 also places duties on service providers and employers not to discriminate, including through reasonable adjustments. Private businesses are not automatically subject to every public sector rule, but inaccessible systems can still create legal, commercial and reputational risk.
Where accessibility problems usually appear
Accessibility issues are often introduced in ordinary business systems rather than public-facing websites. A bespoke customer portal, SharePoint intranet, Microsoft Teams app, booking platform, learning system or Power BI dashboard can all become a barrier if accessibility is not considered from the start.
Internal software deserves the same attention as public services. If a staff member cannot complete a timesheet, access a policy, take part in a meeting or use an essential workflow, productivity and inclusion are affected. This is particularly relevant when organisations introduce digital transformation projects, consolidate systems or build new processes around Microsoft 365.
Third-party software adds another layer of complexity. A supplier may claim that its product is accessible, but the claim may be based on an old assessment, a limited part of the platform or a configuration that does not match your own implementation. Bespoke integrations, custom forms and uploaded documents can also undermine an otherwise capable product.
A software accessibility compliance guide for action
Start with the tasks that matter most
Do not begin by trying to audit every page and feature equally. Identify the journeys that people must be able to complete: applying for a service, reporting an issue, approving an order, booking an appointment, accessing learning materials or completing core work tasks.
Map each journey from start to finish, including sign-in, form completion, document downloads, confirmation messages and any hand-off to another platform. This gives decision-makers a clear view of where an accessibility problem could stop a person from achieving a real outcome.
Prioritisation should reflect impact, frequency and risk. A minor issue on an infrequently used information page may wait. A keyboard trap in a payroll system, an inaccessible emergency contact form or a screen-reader barrier in a public application process should not.
Establish the standards and ownership
Set a clear accessibility standard for each project. For most web-based software, WCAG 2.2 AA is a sensible baseline. If you work in the public sector or procure technology for public-facing services, BS EN 301 549 may also be relevant because it provides a broader accessibility standard for ICT products and services.
Standards alone do not deliver change. Assign ownership across the delivery lifecycle. Product owners should define accessibility requirements, designers should create usable interfaces, developers should build semantic and keyboard-friendly components, and testers should verify that the finished system works with real assistive technology.
Senior ownership matters too. Accessibility can be lost when deadlines tighten unless it is treated as a quality and service-continuity requirement, rather than an optional design enhancement. Make it visible in project governance, acceptance criteria and supplier reviews.
Build accessibility into requirements and procurement
The least expensive accessibility issue is the one prevented before development begins. User stories and specifications should describe what people need to do, not merely what the interface should look like. For example, a requirement for an online form should cover keyboard completion, clear field labels, readable instructions and errors that can be understood without relying on colour alone.
When buying software, ask suppliers for evidence rather than general assurances. Useful evidence includes a current accessibility conformance report, details of the standard used, known limitations, a remediation roadmap and confirmation of how accessibility is tested after product updates.
Be precise about the version being assessed. A supplier’s report for a core platform may not cover optional modules, mobile apps, embedded forms or the custom configuration your organisation plans to use. Include accessibility obligations in contracts where the software is business-critical, along with a route for reporting and resolving defects.
Test with more than automated tools
Automated checks are valuable because they can quickly spot missing form labels, poor contrast, empty links and some structural problems. They are not sufficient on their own. Automated tools cannot reliably judge whether instructions make sense, whether focus moves logically through a complex workflow or whether a screen reader user can understand a dynamic notification.
A proportionate testing approach combines automated checking, manual review and user testing. Manual testing should include keyboard-only navigation, zooming text, checking visible focus, reviewing heading structure and using at least one screen reader on the highest-priority journeys.
Where possible, involve people with lived experience of disability. Their feedback reveals whether a service works in practice, not just whether it passes a technical test. For a smaller organisation, this does not always require a large formal research programme. Even targeted testing of a few critical processes can uncover issues that would otherwise remain hidden.
Fix root causes, not isolated screens
Repeated defects usually point to a problem in a shared component, design pattern or development process. If every modal window traps keyboard focus, fixing one modal is not enough. Correct the underlying component, document the expected behaviour and update the team’s reusable patterns.
Keep an accessibility issue log that records the barrier, affected users, severity, owner, target date and evidence of the fix. This makes progress visible and prevents known issues being forgotten after a release.
Not every issue can be resolved immediately, particularly where a legacy platform has technical constraints. In those cases, provide an accessible alternative route where possible, communicate honestly about the limitation and set a realistic plan for remediation. An alternative should deliver the same outcome in a reasonable timeframe, not simply redirect the burden to a phone call or manual workaround.
Keep compliance current after launch
Accessibility can deteriorate quietly. A software update changes a component, a new PDF is uploaded, a content editor adds an image without alternative text, or an integration introduces an inaccessible login step. Ongoing governance is therefore more useful than a one-off compliance exercise.
Build accessibility checks into release processes, content publishing, change control and supplier management. Train the people who make everyday changes, including content owners and administrators, not only technical teams. For public sector websites and apps, maintain an accurate accessibility statement that explains the service’s status, known issues and how users can request information in an accessible format.
A managed technology partner can help bring structure to this work, particularly where software, security, Microsoft 365 and operational processes overlap. The aim is not to create unnecessary administration. It is to make sure systems remain usable as the organisation changes.
Accessibility is a practical measure of whether technology is doing its job. When people can use a service without avoidable barriers, organisations reduce disruption, protect their reputation and get more value from the systems they already rely on.
