Mandatory web accessibility for businesses

Table of contents

• Introduction
• When is web accessibility mandatory?
• The reference level: WCAG and AA conformance
• Where business websites fail most often
• How to address mandatory web accessibility without improvising
• Don’t confuse compliance with a widget
• A business decision, not just a compliance issue

Introduction

A person arrives at your contact page but cannot activate the button using the keyboard. Another cannot understand a video because it has no captions. A third abandons the checkout process because the form error message only appears in red. These are not minor design issues: they are barriers that cost sales, service and trust. Mandatory web accessibility places these problems within a compliance framework, but for many businesses the real cost is also commercial and operational.

The useful question is not whether a website “looks good”. It is whether a person can find information, register, make a purchase, request a quote or manage a service without depending on specific abilities, devices or ways of navigating. This is the difference between a decorative digital presence and infrastructure that actually works.

When is web accessibility mandatory?

Not all businesses have exactly the same obligations. The applicable framework depends on the country where you operate, the type of service, the markets where you sell, and whether your organisation provides a public or essential service. For this reason, treating accessibility as a universal legal checkbox is a mistake.

In the European Union, public-sector accessibility legislation already requires many public websites and applications to be accessible. In addition, the European Accessibility Act expands requirements to certain consumer products and services from June 2025. Depending on the case, affected areas include e-commerce, banking services, transport platforms, electronic communications and certain associated digital services.

For businesses in Andorra or outside the EU, the key factor is not only where the company is incorporated. It also matters whether it markets services to European consumers, works with public authorities, or forms part of a supply chain that imposes accessibility requirements. Microenterprises may have exemptions in specific contexts, but it is not advisable to assume that they apply without reviewing the specific case with legal advice.

The operational conclusion is clear: identify your market, your digital channels and the services that users can purchase or manage through them. Then determine what level of compliance applies to you. Doing it the other way around — redesigning without knowing the legal scope or business priorities — creates unnecessary expense and leaves critical areas unresolved.

The reference level: WCAG and AA conformance

When discussing technical requirements, the Web Content Accessibility Guidelines, known as WCAG, are the usual reference. AA conformance is often required in tenders, regulated environments and projects with high public exposure. It is not an aesthetic badge or a test that can be passed in a single QA session.

WCAG groups its criteria around four conditions: content must be perceivable, operable, understandable and compatible with assistive technologies. In terms of product decisions, this means that a relevant image needs a useful text alternative; navigation must work with a keyboard; form fields must have clear labels; and code must correctly communicate the structure and state of components.

Colour contrast is probably the best-known issue, but it is only one part of the work. A website with correct contrast can still be inaccessible if keyboard focus is not visible, a dropdown menu becomes trapped, a pop-up does not announce its opening, or a screen reader encounters buttons without accessible names.

Where business websites fail most often

Barriers tend to appear in repeated components rather than on a single page. This is good news: fixing a design system, template or development component can improve dozens of screens at once. It also explains why isolated patches tend to fail over time.

Forms are a particularly sensitive area because they coincide with conversion moments. A placeholder does not replace a field label. Errors should explain what happened and how to fix it, rather than simply changing colour. If a specific phone number format is required, the instruction should be provided before submitting the form, not after blocking the user.

Navigation is the second critical area. Mobile menus, internal search, catalogue filters, cookies and modal windows must be navigable and predictable. An interface can look modern while being impossible to use without a mouse. This affects people with motor disabilities, but also users with a temporary injury, a laptop without a mouse or a slow connection that changes how the page behaves.

Multimedia content also requires editorial judgement. Videos need captions when sound provides information; transcripts may be necessary for informational content; and images should not have generic alternative text. “Image 1” does not inform anyone. However, a purely decorative photograph does not need an extensive description. Accessibility is not about adding text to everything, but about preserving meaning.

How to address mandatory web accessibility without improvising

The first step is an audit using a dual approach: automated and manual. Automated tools detect recurring issues with markup, contrast or missing attributes. They are efficient at finding problems at scale, but they cannot determine whether alternative text is appropriate, whether the navigation order makes sense or whether a checkout process is understandable. Relying on them as the only test creates a false sense of security.

Next, prioritise according to risk and impact. Start with the flows that generate revenue or provide access to a service: purchasing, booking, registration, payment, contact, private areas and support. Then move on to global navigation and shared components. This sequence avoids spending weeks on adjustments to secondary pages while a user cannot complete the main action.

Fixes need to reach both design and code. Design defines hierarchy, contrast, focus states, messages and responsive behaviours. Development implements semantic HTML, correct heading structures, form labels, focus management and compatibility with assistive technologies. If either team gets involved too late, expensive and fragile solutions appear.

It is also worth establishing a definition of done for future changes. Every new component should undergo keyboard, focus, semantics, contrast and mobile adaptation reviews before being published. Every piece of editorial content should follow basic rules for headings, descriptive links, images and video. Without this discipline, a website that has been corrected will begin to degrade again with every campaign or update.

Don’t confuse compliance with a widget

Widgets that promise to solve accessibility through a floating overlay are attractive because they seem quick and inexpensive. But they do not fix the code structure, incorrect labels or poorly designed user flows. In some cases, they can even add friction for people who already use their own assistive technologies.

A reliable solution works on the actual product. This may require changes to a CMS template, a redesign of components, a checkout review or integration with third-party systems. If the payment or booking provider is not accessible, commercial responsibility does not disappear simply because the component is external. Alternatives should be assessed, the component configured correctly, or the risk and mitigation plan documented.

A business decision, not just a compliance issue

Accessibility has an initial cost, especially for older websites, highly customised platforms or checkout processes with many dependencies. But postponing it often increases that cost. Fixing a component before deployment is more efficient than addressing it later across dozens of pages, campaigns and device variations.

It also improves elements that every business needs: clearer forms, more consistent navigation, better-structured content and less abandonment caused by friction. It does not guarantee sales on its own, but it removes obstacles that prevent existing demand from converting.

The right time to act is not when a complaint or contractual requirement arrives. It is while your website can still be organised thoughtfully: prioritising critical services, fixing the system and ensuring that every future improvement maintains the same standard. This is the practical way to turn a potential obligation into a digital asset that can support growth.