The European Accessibility Act has put web accessibility high on the agenda for Belgian and Dutch entrepreneurs. Where accessibility under the WCAG guidelines (Web Content Accessibility Guidelines) used to often be seen as an optional extra for government bodies, the legislation now also requires commercial platforms and online stores to be usable for everyone. For SMEs, this means that blindly relying on a nice design is no longer enough.

Many businesses try to quickly check the legislative box by bolting a separate plugin or an accessibility widget onto their existing site. Such tools promise instant compliance with a simple script, but in practice they often cause more problems than they solve. They slow the platform down with heavy JavaScript files and don't fix the errors in the actual source code.

Real accessibility starts at the foundation of your platform. By building with clean code, logical HTML structures, and thoughtful design, you don't just meet the legal requirements, you also build a faster, more usable, and more discoverable website. In this article, we look at what the legislation requires and what a before-and-after transformation looks like in practice.

What the legislation concretely requires from businesses

Legislation around digital accessibility is based on the international WCAG standards. In Europe, the European Accessibility Act sets clear requirements for e-commerce, digital services, and publicly accessible applications. The core of this legislation is that digital information must be accessible to everyone, regardless of visual, auditory, motor, or cognitive impairments.

The WCAG guidelines are built around four fixed principles:

  • Perceivable: Information and interface elements must be presentable in ways users can perceive. Think of sufficient color contrast and text alternatives for images.
  • Operable: The user interface and navigation must be operable with different input devices, such as a keyboard or a screen reader.
  • Understandable: The information and the operation of the interface must be logical and predictable.
  • Robust: The content must be reliably interpretable by a wide range of browsers and assistive technologies.

For most commercial platforms, WCAG level AA is the legal standard. This means that not just the main pages, but the entire journey from navigation to checkout or contact must meet the standards.

Why quick overlays and heavy plugins don't work

When an entrepreneur is confronted with new legislation, the temptation to look for a quick software fix is strong. Many so-called accessibility widgets have appeared on the market. These are external scripts that add a button to the side of the screen, allowing the visitor to adjust text size or contrast.

The problem with these overlays is that they leave the platform's underlying code untouched. A screen reader used by a blind visitor looks directly at the HTML structure of the page. If a button is built as a generic `<div>` without the right functionality, an overlay won't fix that. On top of that, an external widget often adds hundreds of kilobytes of complex scripts, which negatively affects the site's load time.

Just as adding heavy libraries for small visual elements clutters the code, an overlay plugin creates technical overhead. An accessible site doesn't need an extra layer on top of the interface, it needs tight, lightweight source code in which every building block is set up correctly from the ground up.

A before-and-after scenario: from quick fix to real accessibility

To understand how accessibility works in practice, let's look at the transformation of a digital platform. In this scenario, we compare the old situation with the approach taken and the final result.

The situation before the overhaul

The original platform showed the typical traits of a site that had been patched over the years with separate modules and off-the-shelf theme components:

  • Navigation: Menus could only be operated with a mouse. Visitors navigating with the Tab key lost track of focus because there was no visual indicator showing which element was selected.
  • Forms: Input fields in the checkout and on the contact page lacked linked `<label>` elements. A screen reader couldn't read out what needed to be entered in a specific field.
  • Visual choices: The brand colors were used without regard for contrast ratios. Light gray text on a white background resulted in poor readability.
  • Stopgap measure: To comply with the rules, an external overlay plugin had been installed. This significantly slowed down load time and led to errors when processing forms.

The approach

Instead of keeping the overlay, the choice was made to thoroughly clean up the source code. The external plugin was removed entirely, and the interface components were rebuilt based on semantic HTML and custom components with React and Tailwind CSS.

First, the HTML structure was restored. Clickable elements that had been coded as `<div>` or `<span>` were replaced with real `<button>` and `<a>` tags. This immediately gives the browser the right instructions for keyboard operation and screen readers.

Next, the color palette was adjusted. Within the Tailwind configuration, color variables were set that are guaranteed to meet the minimum contrast ratio of 4.5:1 for normal text. Finally, all interactive elements were given clear, customizable focus states via CSS, so it's always obvious which element is active while navigating with the keyboard.

The situation after the overhaul

The result after this approach shows a clear difference:

  • Full keyboard operability: The entire platform, including complex forms and pop-ups, can be navigated smoothly without a mouse.
  • Clean source code: By removing the external widget and cleaning up unnecessary scripts, the page loads considerably faster.
  • Automatic compliance: The platform meets WCAG AA requirements at the source-code level, without depending on external vendors or monthly software subscriptions for widgets.
  • Better for search engines: The semantic structure required for accessibility also allows Google's search engines to better understand and index the page's content.

The practical checklist for your own platform

If you want to check whether your website or application is ready for the legal requirements, there are a few important points you can look at right away.

Semantic HTML

Use HTML elements for what they're meant for. A heading is an `<h1>`, `<h2>`, or `<h3>`, a navigation menu belongs in a `<nav>`, and an action button is always a `<button>`. Avoid using generic elements with JavaScript events for interactive components.

Contrast and readability

Make sure the text color contrasts sufficiently with the background. Test not just the default text, but also the state of buttons on hover or focus. Use a sans-serif, sufficiently large font for body text.

Keyboard navigation and focus

Press the Tab key on your own website a few times. Can you tell where you are? Can you open the menu and navigate through the forms? If the blue or black outline around active elements has been disabled in the CSS without an alternative being built, the site isn't accessible to keyboard users.

Forms and error messages

Every input field has a corresponding label linked to the field's `id` via the `for` attribute. When a user makes a mistake filling out a form, the error message should be indicated not only with color, but also with clear text.

Building accessibility in from the very first design

Making an existing, outdated website accessible after the fact is often more expensive and time-consuming than setting up a new platform correctly from the start. When you build custom with modern technologies such as React, TypeScript, and Tailwind CSS, you can factor accessibility directly into the architecture.

By building components modularly and giving them the right ARIA attributes where needed, the platform keeps meeting WCAG standards even with future expansions. Clean code and accessibility go hand in hand: they ensure better performance, less technical maintenance, and an optimal experience for every visitor.

Want to know how your current website or platform scores on accessibility and structure? Get in touch for a free thirty-minute conversation in which we discuss the technical state of your platform.