Web accessibility: what the law now requires from Belgian businesses

European Directive 2019/882, known as the European Accessibility Act, has applied across the Union since 28 June 2025. It extends to the private sector a requirement that until then only covered public websites: certain digital products and services must be usable by people with disabilities.

In practice, the directive covers e-commerce services, consumer banking services, e-books, electronic communications services and parts of passenger transport, among others. A Belgian online shop therefore falls within scope, whatever platform it runs on.

In Belgium, transposition sits at federal level and market surveillance rests with the economic authorities. The text does not prescribe a technology: it sets functional requirements, and the harmonised standard EN 301 549 is the reference used to demonstrate compliance.

The rule targets services provided to consumers. A purely informational site with no sales or online contracts is not directly covered by this text. As soon as a site lets people order, book and pay, take out a subscription or conclude a contract at a distance, it provides an e-commerce service within the meaning of the directive.

Micro-enterprises providing services are exempt: fewer than ten people and an annual turnover or balance sheet not exceeding two million euros. The exemption removes the obligation, not the point: those sites serve the same customers, and nothing prevents them from targeting the same level.

Service contracts concluded before 28 June 2025 may continue unchanged until 28 June 2030 at the latest. A shop launched or rebuilt after that date must comply from the day it goes live.

EN 301 549 refers to the W3C Web Content Accessibility Guidelines, version 2.1, level AA. That is the benchmark auditors ask for and providers understand. Level A alone is insufficient; level AAA is not required.

Level AA covers four principles: content must be perceivable (text alternatives, sufficient contrast, captions), operable (keyboard navigation, enough time, no traps), understandable (declared language, explicit forms, errors flagged) and robust (code that assistive technologies can interpret).

WCAG 2.2 has existed since 2023 and adds a few criteria, notably on focus visibility and authentication. Targeting 2.2 AA is the cautious choice: it includes everything 2.1 requires.

The same problems recur on most audited sites: contrast too low on buttons and secondary text, images without a text alternative, form fields without an associated label, links labelled “click here”, videos without captions and pop-ups that cannot be closed from the keyboard.

Less visible structural failures come on top: page titles missing or identical everywhere, an inconsistent heading hierarchy, no declared page language on a multilingual site, and mobile menus whose open or closed state is not announced to screen readers.

None of these calls for a rebuild. Most are fixed in code and content, provided they have been identified first.

Start with an audit that combines an automated tool with manual checking. Tools catch part of the failures, contrast and missing attributes above all, but they cannot judge whether a text alternative is meaningful or a keyboard journey makes sense.

Then prioritise by journey: finding a product, adding to basket, paying, creating an account and getting in touch. One blocking failure at checkout outweighs ten minor ones on an archive page.

Document what is compliant, what is in progress and what remains. An honest accessibility statement published on the site shows the approach and serves as a reference in the event of a check or a complaint.

A serious audit is more than a score. It walks through every template on the site — home, service page, product page, basket, checkout, contact form, article — and checks a stable list of criteria on each. Does the reading order still make sense with styles removed? Does every informative image carry a text alternative that says what it shows, and every decorative image an empty one? Do form fields have a visible label that is also associated in the code, rather than only a grey hint that vanishes on typing?

Contrast comes next. Level AA requires a ratio of 4.5 to 1 between body text and its background, and 3 to 1 for large headings and interface components such as field borders or button icons. Light grey on white, common on recent sites, almost always fails. A contrast checker gives the answer in seconds; the fix is usually darkening a colour by a few steps, without touching the layout.

Finally, the audit tests with the keyboard alone. Tab by tab, you must be able to reach every link, button and field, see where you are thanks to a visible focus indicator, open and close a menu or dialog, and never get trapped. This test exposes in minutes the carousels with no controls, the hover-only dropdown menus and the modals that capture focus without giving it back.

For a shop, the ordering journey is the core of the obligation. A customer who can browse the catalogue but not complete a purchase does not have access to the service. Each step therefore needs its own check: selecting a variant, adding to the basket, entering an address, choosing delivery, paying and confirming.

Errors must be announced in text, next to the field concerned, with a useful explanation: “The postcode must have four digits” rather than a red border alone. Required fields are marked by something other than colour. Success messages are also text, readable by a screen reader, not only an animated green tick.

• The payment module deserves particular attention because it usually comes from a third party.
• An inaccessible payment iframe makes the whole site non-compliant, however careful the rest is.
• Ask the provider for its conformance statement and test its form with a keyboard and a screen reader before committing.
• The major payment providers in Belgium publish this documentation; its absence is itself information.

The accessibility statement is a public document reachable from every page, usually in the footer next to the legal notice. It states the level targeted, the real conformance status — compliant, partially compliant or non-compliant — the list of content that is not yet accessible with a reason and a deadline for each item, and a contact route for reporting a problem.

Write it honestly. A statement that claims full compliance when a quick audit proves otherwise makes matters worse in the event of a complaint. A statement that admits three failures, explains them and sets a correction date shows a controlled approach, which surveillance authorities take into account.

Update it after every significant fix and date each version. It then becomes the logbook of the work: useful internally to track progress and externally to prove the business acted in good faith.

Part of the failures are fixed once and for all in the site’s code: heading structure, form attributes, menu behaviour, focus management, language declaration. These fixes apply to every template at once and need no further intervention from the editorial team.

The other part depends on the people who publish every day: writing a text alternative for each new image, avoiding “read more” links with no context, not pasting a table as a picture, captioning videos, keeping a coherent heading hierarchy. These habits are simple but must be known, and the editing tool must make them possible.

That is why a compliance project always has two deliverables: the technical fixes and a short, site-specific sheet of editorial good practice that fits on one page. Without the second, the site is non-compliant again after the first round of publishing.

On a recent site built with clean HTML, reaching AA often takes a few days of work spread across contrast corrections, form labelling, adjustments to interactive components and writing the statement. On a site assembled from a heavy theme and twenty extensions, every extension can bring its own failures, and the effort becomes hard to bound.

A pragmatic way to split the effort is to handle first the journeys that condition access to the service: search, basket, checkout, account, contact. They are few, well identified and carry most of the legal risk. Secondary pages and archive content come next, in a dated plan that the statement makes public.

When the site is being redesigned or built from scratch, putting these requirements in the brief changes almost nothing in the budget: an accessible component costs no more to build than an inaccessible one, it only costs more to rebuild. The price difference lies in when the decision is taken, not in the amount of work.

An accessible site is also a better-structured site: hierarchical headings, text alternatives, explicit links and semantic code are exactly what search engines read. Accessibility fixes therefore directly serve search visibility.

• They also serve conversion.
• Sufficient contrast, clear forms and predictable navigation reduce drop-off for every visitor, not just those using assistive technology.
• On a phone, in full sunlight, on a poor connection, everyone becomes a constrained user.

• Built in from the design stage, accessibility costs little.
• Retrofitted onto a complex site, it costs more.
• That is why it belongs in the brief for a new site or a redesign, not in a list of later patches.