European Accessibility Act: How to prepare your online store

For us at Kiwee, creating accessible websites has always been a core mission, driven by the belief that the digital world should be open to everyone. Now, with the Directive (EU) 2019/882, commonly known as the European Accessibility Act (EAA) entering into force on 28 June 2025, this principle is gaining wider legal recognition. The EAA places accessibility front and center of website design, making it clear that this is no longer a topic just for public institutions. Every website owner should now place accessibility at the heart of their decision-making, aligning with what we believe is simply good, inclusive practice.

The digital world is full of barriers and most of them are invisible to those who don’t rely on assistive technology. Can your website be used without a mouse? Does it hide readable content from screen readers? Does it use color as the only way to signal an error? It’s potentially shutting out more than a quarter of potential users ¹ in the European Union alone. Accessibility isn’t just a checkbox or a legal obligation from the European Accessibility Act. It's a fundamental part of good design. Organizations must understand their users. They need to walk in their users' shoes. Use your website as your users do, don't just design for them. Here’s how to do that: by considering the core accessibility principles of WCAG
.2: being Perceivable, Operable, Understandable and Robust.

Building Accessible Online Stores: 10 Core Principles for the European Accessibility Act

Below, we’ll break down ten accessible web design principles for all developers. Are you starting from scratch or refining an existing site? These practical techniques and tools will help. They ensure your online shop is accessible and inclusive, helping you comply with the applicable requirements in the European Accessibility Act.

1. Semantic HTML is fundamental

Many website owners feel that it can be difficult to find developers with an awareness of accessibility principles. Yet, did you know that a large amount of the work involves simply complying with the fundamental rules of Semantic HTML? Here’s how:

Use appropriate tags: <button>, <a>, <label>, <fieldset>, etc.

These tags provide for built-in accessibility features, such as keyboard interaction and roles. By choosing an appropriate semantic tag, it is often the simplest and most robust way to make web content accessible. This method uses the browser's built-in capabilities. It reduces the need for complex, buggy ARIA workarounds. It also provides a predictable user experience.

Avoid generic containers like <div\> and <span> for interactive elements.

Generic containers don’t have semantic meaning or built-in accessibility behavior, and they require ARIA to replicate proper behavior. For example,

<div onclick="doSomething()">Click Here</div>
<span onclick="submitForm()">Submit</span>

By using this approach, assistive technologies like screen readers won't recognize these elements as interactive controls (e.g., a button or link). This makes it difficult or impossible for users relying on these technologies to understand the element's purpose. A better alternative is to use semantic HTML elements like <button> and <a>. These elements have built-in keyboard accessibility. They are focusable and activatable with Enter/Space. They also automatically communicate their role to assistive technologies.

Use headings and list elements correctly to create a logical document outline.

Imagine trying to find information in a long document with no chapter titles or subheadings? Incorrect or missing headings create this exact problem for screen reader users. Similarly, ensure that list elements <ul>, <ol> and <li> are used to structure lists. By using proper heading structures and list elements, screen readers and other assistive technologies can present content hierarchy clearly to their users.

2. Keyboard Accessibility

Why is keyboard accessibility important? It’s a fundamental aspect of the WCAG "Operable" principle, meaning users must be able to interact with all site functionality using a keyboard. It’s crucial for those with motor disabilities who cannot use a mouse, but it’s also very important for screen reader users. It’s also worth considering that it’s not only an accessibility topic; more advanced users may prefer keyboard commands for efficiency. Failing to provide keyboard access locks users out of your website. This is a fundamental failure to meet operability requirements. These are essential for European Accessibility Act compliance.

Ensure all functionality is operable via keyboard (e.g., Tab, Enter, Space).

Based on the available data from WebAIM’s 10th Screen Reader User Survey, it is observed that a majority (71.6%) of screen reader users navigate web pages mainly through headings. While precise data for keyboard navigation is not available, users navigating through sites by using headers are highly likely to be using keyboards.

Test the focus order

While automated tools help, it’s important to also manually test online sites for their focus order. To do this, check the order in which interactive elements (like buttons, links, form fields) are focused when a user navigates using the keyboard, usually by pressing the tab key. To do this, check the focus order of interactive elements. These include buttons, links, and form fields. Observe this as a user navigates with the keyboard, usually by pressing Tab. The focus order should be very intuitive; by following the visual reading order (top-to-bottom, left-to-right), users should be able to easily navigate the site.

Provide visible focus indicators

For a user navigating with a keyboard, knowing "where they are" on the page is essential. This is addressed by WCAG's 'Focus Visible' criterion (Level AA), which requires a clear visual cue on any keyboard-operable element. Since WCAG 2.1.1 (Keyboard) requires all functionality within user interfaces to be keyboard operable, providing this visible focus is essential everywhere.

These visual cues, or focus indicators, are vital because they complement the focus order. If the navigation sequence is correct but the user can't see the currently selected element, they can easily get lost, making keyboard navigation nearly impossible.

Therefore, your focus indicators must be obvious and easy to see and ensure every interactive element clearly shows when it has keyboard focus. A critical point: never disable the browser's default focus outlines (for instance, using outline: none) unless you substitute them with an alternative that is just as clear and effective.

3. Color & Contrast

Text contrast must meet WCAG 2.2 guidelines.

Ensure readability for users with visual impairments or color blindness. All text on a website or digital interface must meet minimum contrast requirements. These contrast ratios are applicable to all texts, including buttons, links, and labels, with the exception of decorative text.

* Normal text (smaller than 18pt regular or 14pt bold) must have a contrast ratio of at least 4.5:1 against any background.
* Large scale text (at least 18pt regular or 14pt bold) can have a lower minimum contrast ratio of 3:1.

Sometimes, developers, graphics designers, UX designers and product owners overlook the contrast ratios in different conditions, such as on-hover or on-click scenarios. A typical example is not ensuring that the "Add to cart" button maintains contrast on-hover or when focused. It’s important that the contrast ratio is maintained throughout the entire user journey. The same contrast considerations apply to non-text elements that convey meaning to ensure they are perceivable, such as focus indicators or icons, meaning it’s a good practice to check the contrast of icons used for cart, payment, or wishlist.

Using color to convey information - what about sight disabilities?

While using color can be an effective method of conveying information, it can be very difficult for many users to understand this method of transmission. For example, if using color swatches to select different colors of the same product, make sure that they also have text labels (visible or via aria-label) identifying the color. Colorblind users may not distinguish between red and green, while those with low vision can also miss color cues. Screen readers also do not perceive visual styling. Consider that:

* Colorblind users make up around 4.42% of your total users2 (approximately 1 in 12 men and 1 in 200 women).

* Screen reader users don’t perceive visual styling at all.

* Users with low levels of vision or those using monochrome displays may also miss color signals. It’s worth considering that even those with perfect eyesight can struggle to read in specific conditions, such as using a device in bright sunlight. Without good contrast, the colours can be barely visible as a result.

The topic of contrast also appears when using color for error messages. While using color as the only visual means to convey information, actions or to distinguish an element doesn’t comply with accessibility standards, a simple and easy to implement improvement is to use an icon that can illustrate the error, such as a cross. By combining both icons and colour, users can quickly understand the error.

Following these contrast guidelines supports accessibility standards compliance. It also improves the overall user experience. This is especially true for those with low vision or color sensitivity.

4. Correctly label all forms and inputs

Building on semantic HTML, proper structure and clear communication are vital for forms. This is especially true for those used during checkout. Ensure your forms are accessible and compliant with the European Accessibility Act and pay attention to:

* Labelling form fields properly using <label>, such as those used in address and payment forms.
* Providing clear, accessible error messages linked to inputs. For example, indicate if a payment card number is invalid. Also, show if a field like postcode is missing. The error should be clearly indicated and linked with a given input field. Use the aria-describedby attribute for this.
* Using native form elements where possible for better support.

5. Using ARIA (Accessible Rich Internet Applications) thoughtfully

Semantic HTML is the web's foundation. However, modern web apps have complex UI components. These include dropdowns, sliders, and dynamic content updates. Standard HTML alone cannot describe these. To bridge that gap for accessibility, ARIA attributes can be added to HTML elements. These attributes provide crucial extra semantic context. They define an element's role (what it is) and current state (e.g., expanded, checked). They also define properties (e.g., name, required status). This enables assistive tech to understand and interact with these components effectively.

But before reaching for ARIA, take a step back and consider: can I do this using standard HTML? <button> or <label> already come with semantic instructions, and they are universally understood by assistive technologies. By doing this, you also reduce the risk of ARIA roles colliding with HTML semantics as well as conflicting with default browser behaviors. In fact, it’s best practice to only use ARIA when native HTML is not sufficient.

Common ARIA Attributes (Roles, States, & Properties):

When designing for accessibility, it’s a good idea for developers to be familiar with common attributes used to convey meaning. These include roles that define the element type such as role="dialog" or role="alert" and HTML attributes that describe its condition or characteristics such as: aria-expanded="true/false", aria-checked="true/false", aria-label="Description".

Content can change on the page without a full reload. Examples include status messages, form errors, or chat updates. Screen readers won't automatically detect or announce these changes unless instructed. To notify readers, developers can use aria-live regions to do so. In an online shop, this is vital when declaring things like items added to the cart, updates to the total, or when stock availability dynamically changes. aria-live also comes with some additional configuration options:

aria-live="polite": This announces a change on the page when the user is idle.
aria-live="assertive": Interrupts the user immediately to announce the change.

When considering accessibility, it’s important to consider what function is served by the notification. Is it something that the user must pay attention to right away? Or can it wait until the screen reader is idle?

To understand how ARIA affects screen reader output, let us consider a button with a simple X icon. The button may be described in ARIA as <button aria-label="Close">X</button>, which allows the screen reader to announce “Close, button” rather than “X, button”. A more advanced use case enabled by aria-describedby allows developers to provide additional context by linking it to the ID of another element containing the description.

6. Responsive & Mobile Accessibility

Ensure your site is responsive and mobile-friendly. This isn't just good practice. It's integral to meeting the European Accessibility Act's broad accessibility goals.

Ensure interfaces work across devices and screen sizes.

Use tools like Google Chrome’s DevTools. They help you quickly check how a design works on different devices and screen sizes.

Allow zooming and respect the user’s text size settings.

A cardinal error in web design is to force users to only use a certain level of zoom or text sizes.

Avoid hover-only interactions or ensure alternatives are present.

Many websites use hover effects such as :hover in CSS or mouseenter/mouseleave events in JavaScript to reveal information or trigger a specific action, such as showing tooltips, expanding submenus, or displaying hidden buttons such as add to wishlist. These are visually attractive and engaging for mouse users. However, relying solely on hover creates significant accessibility barriers. Keyboard users are excluded from all on-hover effects, while it also presents a serious difficulty for users of assistive technologies who cannot consistently (if at all) trigger hover states.

Font sizes should be specified in relative units, so the text scales with the content.

Avoid fixed pixel (px) font sizes. They don't scale well when users change their default browser font size for readability. Each browser handles the change of fixed pixel sizes differently when zoomed, which can cause considerable problems for a subset of users.

Relative units, such as rem or em base their size on something else, allowing them to grow or shrink proportionally.

Many developers test sites by increasing font sizes. It’s also important to test by decreasing the size. See how it performs for users who prefer smaller fonts than the designer intended.

7. Accessible Multimedia

Add captions to videos and transcripts to audio content

Multimedia content is really helpful when it comes to enhancing the user experience, but it also presents significant accessibility barriers if not implemented carefully. Addressing these barriers is not just about good practice, as specific requirements for captions, audio descriptions, and accessible controls are detailed in standards like EN 301 549 which can be used to demonstrate compliance with the European Accessibility Act obligations for relevant products and services.

Captions are often thought useful only for those who can't hear. However, other users commonly use captions too. For instance, people in noisy environments use them. So do those who prefer reading content over listening. Accessibility considers all of these users, and captions should also be detailed enough to identify individual speakers and other sounds.

That’s not all: full accessibility requires transcripts to be provided as well as captions. Transcripts offer a complete representation of the content. They also provide a non-linear way to access it. Content can be searched and used with Braille devices. This makes them invaluable for Braille users. For video content, it’s a must-have to provide both detailed captions and transcripts.

Another area that is often overlooked relates to Audio Description (AD) tracks. AD is a separate audio track. It provides crucial information for those with limited or no vision. This includes scene descriptions or other visual clues. These are vital for product demonstration videos. AD is a key component for accessible multimedia.

Accessible Media Controls

While autoplaying content might seem appealing, it is difficult to process for many users. Give them the option of starting the content manually, or if your content relies on autoplaying, ensure that there is a quick and easy way to stop or pause the content.

Also consider that autoplay can distract users. Autoplay usually interferes with screen reader audio. This makes it very hard for blind or low-vision users to navigate. Additionally, unexpected sound or motion is very disruptive. This particularly affects users with cognitive disabilities or attention deficits. It hinders their ability to focus on their primary task.

The controls must meet broader requirements. Media player controls (captions toggle, full screen, play/pause, seek bar, volume) need to be keyboard accessible. They also must be properly labeled and have visible focus states.

8. Always use descriptive alt texts for products, empty alt for decoration.

For an online shop, most product images are critical content and must have descriptive alt texts. The alt attribute should describe the purpose and meaning of the image in a concise way. A good checklist should contain:

• Describe what can be seen: including vital visual details like color, style, material, or features shown.
• Be concise but informative: Avoid stuffing with keywords, as alt texts are for the user. Focus on describing the image visually.
• Don't use Image of... or Photo of..., as screen readers announce that it is an image to the user.

Good practice: alt="Men's blue crew-neck merino wool sweater"
Bad practice: alt="product image" or alt="blue jumper wool photo SKU12345"

Good alt texts help users understand products. This enables informed purchasing decisions and reduces returns. It aligns with the European Accessibility Act's inclusive principles. On the other hand, failing to provide useful alt text on product images creates a major and unwarranted barrier. Reduce cognitive load by correctly marking decorative images. Also, provide essential information for content images. This is an important part of accessibility.

Not all images are meant to be visible for screen readers, especially those which are more decorative in nature. Avoid clutter for assistive technology users. Carefully consider which images need explanation. Background images and decorative ones usually don't need description. Reducing cognitive load for these users is key to increasing accessibility.

Marking a decorative image isn’t difficult, just provide an empty alt attribute: alt="", which tells the screen reader to ignore the image.

9. Time limits

Users shouldn't be restricted by artificial time constraints - for instance, a time limit to enter a code. While this is unavoidable in certain circumstances such as online banking session timeouts or real-time events like auctions, they should otherwise be avoided. Time limits cause considerable stress for all users, but they pose significant barriers for some users.

In fact, WCAG addresses this directly in Guideline 2.2.1: if a time limit is set by the content, users must have a way to turn it off, adjust it or extend it easily, unless the time limit is essential or longer than 20 hours. Importantly, WCAG also requires a warning. This warning must appear at least 20 seconds before expiry if an extension mechanism exists.

10. Testing with Assistive Technologies - Open source accessibility toolkit

The final step is testing with various Assistive Technologies. This is vital for a positive user experience. It also helps verify and show compliance with European Accessibility Act technical standards.

Tools like Axe and Lighthouse offer automated audits. However, the best way to test websites is to use them like a user would. All of the principles above can be underpinned with a solid developer toolkit centered around accessibility. At Kiwee, we routinely make use of these open source tools:

* Screen readers:
NVDA
JAWS

* Accessibility testing tools: Axe DevTools, Lighthouse, pa11y

We also use pa11y in our pipeline as it has a CLI - every time we make an update, we receive information if something needs to be fixed in terms of accessibility.

* Color contrast checkers: Color Contrast Analyzer(CCA), WhoCanUse

* Linting/CI tools: ESLint plugins for a11y, jest-axe.

But software tools can only take you part of the way. An important part of checking for accessibility is to inspect the source code manually, rather than simply relying on automated linting or other CI-based tools. Manual navigation with the keyboard must also be checked in great detail: can users complete all the forms, can they reach all the elements of the site? Can you also deal with all the popups?

For an online shop, test the entire user journey. Check if users can find products and view details. Ensure they can select options, add to cart, and complete checkout successfully. Most of all, don’t forget about non-visible disabilities. A site that is fully accessible through assistive technologies may still have considerable barriers for neurodivergent individuals through excessive cognitive load and information overload, poor font selection and heavy use of jargon, all considerations under the wider umbrella of the European Accessibility Act.

Web accessibility is non-negotiable: Final Thoughts for developers and online shop owners

Making a website accessible isn't simply a checkbox exercise; it's a dedicated process requiring careful planning and meticulous execution. For true effectiveness, accessibility must be embraced as a core organizational value. Isolated changes will fall short without systematic, bottom-up support to implement and consistently reinforce these crucial accessibility activities.

Remember, accessibility isn't just about visible disabilities. True, there are many simple wins, and designing with WCAG standards from the start helps meet user needs. It also addresses common legal requirements, like those in the European Accessibility Act. Also consider this: an accessible website makes it easier for all users, as they can more easily access the information they need.

References

1. Eurostat - Population with disability
2. Deane B. Judd, "Facts of Color-Blindness\," J. Opt. Soc. Am. 33, 294-307 (1943)