An accessible website allows people with different visual, auditory, physical, speech and cognitive needs to find information and complete important tasks. It should support keyboard navigation, screen readers, voice control, magnification and other assistive technologies without creating unnecessary barriers.
Why accessibility matters in 2026
Accessibility affects a significant and diverse proportion of every organisation’s audience. Some people have permanent disabilities, while others experience temporary or situational limitations caused by injury, illness, environment, ageing or the device they are using.
Improving accessibility can also benefit users more broadly. Clear navigation, readable content, descriptive labels, usable forms and consistent interfaces make digital experiences easier for everyone to understand and operate.
Organisations that overlook accessibility may exclude customers, employees and service users. They may also create legal, financial and reputational risks that become more expensive to address once inaccessible patterns are embedded throughout a platform.
Understand the current standards
The Web Content Accessibility Guidelines provide the most widely recognised technical framework for digital accessibility. In 2026, WCAG 2.2 remains the current W3C Recommendation, and the W3C encourages organisations to use the latest version when developing or updating accessibility policies.
WCAG is organised around four principles: digital content should be perceivable, operable, understandable and robust. These principles consider the different ways people access and interact with websites rather than focusing on a particular device or technology.
WCAG 2.2 adds criteria addressing areas such as visible keyboard focus, dragging alternatives, minimum target sizes, consistent help, avoiding repeated data entry and accessible authentication. These additions reflect common barriers found in modern websites and digital applications.
Accessibility requirements in the United Kingdom
UK public sector websites and mobile applications are generally required to meet WCAG 2.2 at level AA and publish an accessibility statement under the UK public sector accessibility requirements. These requirements apply to public-facing services and can also cover public sector intranets and extranets, subject to the scope and exemptions within the regulations.
Public sector organisations must regularly review their accessibility statement, explain known accessibility problems and provide a way for users to request information in an accessible format. Accessibility should cover the complete service, including website content, mobile applications, forms, downloadable documents and third-party tools used to complete important tasks.
Private-sector organisations are not generally covered by the Public Sector Bodies Accessibility Regulations. However, UK service providers have duties to make reasonable adjustments for disabled people under the Equality Act 2010, or the Disability Discrimination Act 1995 in Northern Ireland. These duties can be relevant when websites, customer portals, mobile applications or other software are used to provide a service.
Accessibility requirements in the EU
The EU has separate accessibility rules for public sector digital services and specified commercial products and services.
The EU Web Accessibility Directive requires websites and mobile applications operated by EU public sector bodies to be accessible. Its technical requirements are supported by the European standard EN 301 549, which covers websites, mobile applications and wider information and communications technology.
The European Accessibility Act has applied since 28 June 2025. It covers particular consumer products and services, including e-commerce, consumer banking, electronic communications, e-books and parts of passenger transport. It also applies to products such as computers, operating systems, smartphones, payment terminals and self-service terminals.
For covered services, accessibility can extend beyond the public website. E-commerce journeys, authentication, payments, customer support, digital documents and mobile applications may all form part of the service. Software interfaces must be capable of working with relevant assistive technologies and should provide understandable navigation, accessible input methods and appropriate alternatives to visual or audio information.
The Act includes exemptions and transitional provisions, including an exemption for certain microenterprises providing services. Requirements are implemented and enforced through the national law of each EU member state, so organisations operating across Europe should review the rules that apply in every market they serve.
Accessibility requirements in the United States
Digital accessibility in the United States is governed by a combination of federal laws, regulations, procurement requirements and state-level rules. The requirements depend on the organisation, type of service and technology involved.
Under the Title II web and mobile application rule of the Americans with Disabilities Act, state and local governments must ensure that covered web content and mobile applications meet WCAG 2.1 at level AA. Following a federal extension announced in 2026, public entities serving populations of 50,000 or more must comply by 26 April 2027. Public entities serving fewer than 50,000 people and special district governments must comply by 26 April 2028.
These requirements can include websites and mobile applications supplied or maintained by external contractors. Procuring a third-party platform does not automatically remove the public entity’s responsibility to provide accessible digital services.
Section 508 of the Rehabilitation Act applies to information and communications technology developed, procured, maintained or used by United States federal agencies. Its scope includes websites, intranets, electronic documents, multimedia and software. Covered web and non-web content and software are generally required to conform to the applicable WCAG 2.0 level A and AA criteria incorporated into the Section 508 standards.
Title III of the Americans with Disabilities Act applies to many private businesses providing goods and services to the public. Unlike the Title II rule for state and local government, there is not one equivalent federal regulation that sets a universal WCAG version and compliance deadline for every private-sector website or software product. However, inaccessible websites and digital services continue to create legal risk, and state laws or contractual requirements may impose additional obligations.
Consider websites and software together
Accessibility should not stop at the public website. Organisations increasingly provide services through software-as-a-service platforms, customer portals, mobile applications, desktop software, internal systems, kiosks and electronic documents. If users need these technologies to access information, perform their jobs, purchase a product or complete a service, accessibility should form part of their design and operation.
Software accessibility includes keyboard operation, clear focus behaviour, meaningful labels, accessible authentication and compatibility with screen readers, magnification, voice input and other assistive technologies. Status messages, errors, charts and complex controls must communicate information in ways that do not rely exclusively on colour, sound, movement or visual layout.
Third-party software should be assessed during procurement. Suppliers should be asked for evidence such as an Accessibility Conformance Report or Voluntary Product Accessibility Template, recent audit findings, documented limitations and a remediation roadmap. These documents are useful evidence, but they should not replace practical testing of the workflows users will actually complete.
Build accessibility into design
Many accessibility problems begin before development. Low colour contrast, unclear navigation, small interactive controls and designs that rely entirely on colour can all create barriers.
Design systems should define accessible colours, typography, spacing, focus states, form controls and interactive components. Designers should also consider how layouts respond when users enlarge text, zoom the page or view content on a smaller screen.
Consistent design is particularly important. Familiar patterns and predictable placement can reduce cognitive effort and help people understand how to move through a service.
Create accessible content
Accessibility is an editorial responsibility as well as a technical one. Content should use clear language, descriptive headings and meaningful link text. Editors should avoid vague links such as “click here” when the link destination can be described directly.
Images that convey information need appropriate alternative text. Decorative images should be handled so assistive technologies can ignore them. Video and audio content may require captions, transcripts or audio description, depending on the material and context.
Documents also require attention. Publishing an inaccessible PDF alongside an accessible website can prevent users from completing the same task. Wherever practical, important information and services should be provided as accessible web content.
Make forms and journeys easier to complete
Forms are often among the most important and least accessible parts of a website. Every field should have a clear label, instructions should be understandable and errors should explain both what went wrong and how to correct it.
Users should not be required to remember or re-enter information unnecessarily. Authentication should not depend exclusively on puzzles, memory tests or interactions that some people cannot complete.
Time limits, validation and session behaviour also need consideration. Where a time limit is necessary, users should normally receive a warning and an opportunity to extend it.
Support keyboard and assistive technology users
Every interactive function should be usable without a mouse. Keyboard users need a logical focus order, a visible focus indicator and a way to move through navigation, forms, dialogs and other controls without becoming trapped.
Semantic HTML gives browsers and assistive technologies useful information about headings, buttons, links, lists and form fields. Custom components may require additional accessibility information, but native elements should be preferred when they already provide the required behaviour.
Responsive behaviour should also be tested with magnification, text resizing, screen readers and different input methods. A layout that appears correct visually may still be confusing when its content is announced or navigated sequentially.
Do not rely only on automated testing
Automated tools can identify issues such as missing alternative text, insufficient contrast and some structural errors. They are valuable for regular monitoring and can help prevent familiar problems from being reintroduced.
However, automated checks cannot determine whether alternative text is meaningful, whether content is understandable or whether a complete journey works effectively with assistive technology. Passing an automated scan is not the same as having an accessible website.
A robust testing process should combine automated checks with manual keyboard testing, screen-reader testing and expert review. Involving disabled users can reveal practical barriers that standards-based testing alone may not identify.
Make accessibility part of procurement
Third-party platforms, plugins and embedded services can introduce accessibility problems that an organisation cannot easily correct. Procurement teams should therefore include accessibility requirements when selecting content management systems, booking tools, payment services and other technology.
Suppliers should be asked for evidence rather than general assurances. This might include an Accessibility Conformance Report, recent audit findings, known limitations and a roadmap for resolving outstanding issues.
Contracts should establish responsibility for testing, remediation and future updates. Without clear ownership, accessibility issues can remain unresolved between the organisation and its suppliers.
Publish a meaningful accessibility statement
Public sector organisations within scope are required to publish and maintain an accessibility statement. For other organisations, a clear statement can still help users understand the current accessibility of a service and how to request support.
A useful statement should be specific and honest. It should identify known limitations, explain any alternative routes available and provide an accessible way for users to report a problem. It should also be reviewed when the website or its accessibility status changes.
Establish ownership and governance
Accessibility deteriorates when it depends on a single audit or one member of the team. New content, campaigns, features and third-party integrations can introduce barriers after an initial review has been completed.
Organisations should assign clear responsibilities across product, design, development, content and procurement teams. Accessibility requirements should be included in briefs, acceptance criteria, quality assurance and release processes.
Training is equally important. Editors need to understand headings, links, images and documents; designers need to understand inclusive interaction patterns; and developers need to know how to implement and test accessible components.
Create a practical improvement roadmap
Organisations with an existing website or software product may uncover more issues than they can resolve immediately. A prioritised roadmap can make improvement manageable without allowing serious barriers to remain indefinitely.
Priority should usually be given to barriers that prevent users from completing essential tasks, issues affecting shared templates and components, and problems encountered across large sections of the service. Fixing a reusable component can resolve the same issue across many pages or software journeys at once.
The roadmap should identify owners, deadlines and methods for confirming that each issue has been resolved. Progress should be reviewed regularly and supported by feedback from users.
Accessibility is an ongoing commitment
Accessibility is not a certificate that can be achieved once and considered complete. Websites and software change continuously, as do technologies, content and user expectations.
Organisations that treat accessibility as part of normal digital delivery are better placed to prevent barriers, manage risk and create services that work for more people. The strongest approach combines recognised standards with inclusive design, human testing and continuous improvement.
Legal requirements vary between jurisdictions and can depend on the organisation, product and service involved. This article provides general information rather than legal advice, and organisations should seek specialist advice when determining their specific obligations.
Looking to improve your digital accessibility?
Improving accessibility requires more than running an automated scan. Design, content, code, software, third-party technology and internal processes all need to work together to create an inclusive digital experience.
Whether you are planning a new website or software product, reviewing an existing platform or creating an accessibility improvement roadmap, our consultancy, design and development services can help you identify barriers and make practical, sustainable improvements.
Explore our website and digital consultancy services
Talk to us about digital accessibility
