Online stores will have to be rewritten. What will the EU Accessibility Directive bring?

In a year, on June 28, 2025, EU Directive 2019/882 on the accessibility of goods and services (“EU Directive 2019/882”) will come into force. This Directive is intended to make websites of goods sellers more convenient for people with disabilities. In his column for AIN, Axon Partners’ lawyer Oleksandr Patyukov explains what it means, who will be affected, and what will have to be done to comply with its requirements.

Have you ever thought about how, for example, people who are blind use computers? Ordinary computers cannot translate what is on the screen into Braille, but they can sound it, and therefore such people perceive information by ear. However, what if such a person comes across not text or audio content, but, for example, an image or a graph? How is the machine supposed to read out what is posted there?

Not only the visually impaired can face such problems. If a person has a hearing impairment, they won’t be able to follow an audio caption or watch a video without subtitles or transcripts. People with mental illnesses will find it difficult to understand what is happening on the screen if the content changes quickly. And if it changes too often, it can be dangerous to life and health for people with epilepsy.

The solution to all these problems has been known for a long time – accessibility. In every field, there is a set of recommendations, best practices, and sometimes mandatory requirements for making something accessible. For example, in the field of construction, this set is the DBN B.2.2-40:2018 Standard “Inclusivity of Buildings and Structures”, and for the Internet, this set is WCAG – “Web Content Accessibility Guidelines”. 

The first web accessibility standards appeared in 1999 and have been updated and supplemented many times since then. But all this time, these standards were not mandatory, so not everyone complied with them. In 2019, the European Parliament and the Council of the EU adopted EU Directive 2019/882, according to which, starting from June 28, 2025, manufacturers, importers and distributors of certain categories of goods and providers of certain types of services will be obliged to comply with these requirements.

The goods subject to the requirements of EU Directive 2019/882 are rather niche: general-purpose computers and certain special-purpose devices, such as ATMs, parking meters, self-service kiosks, and e-books.

The situation with services is different: the requirements of EU Directive 2019/882 apply to e-commerce services (in particular, online shopping sites), electronic communications services, audiovisual media, consumer banking, websites of passenger transport companies, and e-book readers.

So, if you have a website or mobile application and you provide any of these services, you have a little less than a year to adapt your website to European law. And you will have a lot of work to do.

The general requirement for websites and applications is that they must be accessible to the extent that they are readable, functional, understandable and reliable.

Behind each of these terms lies a huge number of requirements that are described in the WCAG standards.

Perceivability

Content is perceivable if all users can perceive it in a way that they can understand. To fulfill this criterion, it is necessary that:

• every non-textual material has a textual alternative.

When you add an image to a web page through program code, you have the option of giving it an alt attribute – alternative text. By default, it will not be displayed on the page, but the user will be able to hear it if they use speech synthesis programs. Users will also see the alternative text when they hover over an image or if the image fails to load for some reason.

Source: Soggy Cat Enjoyer

Obviously, this also applies to cases where text content is embedded in an image for some reason. Such images should have the text written on them in the alt attribute.

• an alternative to time-based content has been provided.

The WCAG developers called audio and video content “time-based”. You can read the text at the rhythm that suits you, but the situation with audio and video is somewhat different. The standard requires that such content be provided with a time-unbased alternative. For example, a transcript or subtitles.

• the content has been adaptive.

Every website you see on the Internet (including the one you are reading this article on), you see the way it is because someone (either a webmaster or a program) has described each of its elements in the hypertext markup language, or HTML.

It is used to describe where things should be on the website: where text is, where an image is, and where a button is. In the CSS language, each of these elements is given different properties. For example, colour, font, location, size. With the help of Javascript, you can describe the behaviour of each element: what will happen to it when it is clicked on or when some other event occurs.

The HTML markup language has a certain set of elements: buttons, input fields, checkboxes, text blocks, images… But these three technologies together also allow you to describe almost any element as any other. Buttons are described as links, input fields as paragraphs of text, and images are described as links. Developers often resort to such tricks. Visually, such elements are fully functional, but they are completely inaccessible to assistive technologies.

Programs that read out the content of web pages to blind people focus on the type of HTML element without delving into its styles or behaviour when interacting with it. Therefore, if your website uses such elements, you will need to set ARIA attributes for them.

With their help, you will be able to “explain” to these programs what role a particular element plays (if it differs from the default role of this element), how it relates to other elements (for example, whether several input fields belong to the same form or to different ones), and describe the behaviour of the element in different situations.

So, if your website is equally convenient to use with a visual interface and assistive technologies, it will be responsive.

• The content is distinguishable.

The requirements for distinguishability are quite simple and obvious. At first glance, there are many of them, because they cover a large number of aspects. For example, the minimum permissible line height, the contrast between content and background, and the ability to “zoom in” on content by 200% without losing its structure. But this point is most likely already being fulfilled, because if you write something in light grey on dark grey, then inaccessibility is probably not the biggest problem with your site.

Operability

Content operability means that the components of your site’s interface are manageable. This criterion is met if:

• the site can be operated using the keyboard.

You should ensure that the site can be used without a mouse, i.e., that the user can switch from one interface element to another using the keyboard.

• the site provides enough time to respond.

If some interface element appears only for a certain time, add an option for the user to pause this time, speed it up, or slow it down.

WCAG standards provide only three exceptions to this rule: (1) it can be disregarded if the control must change in real-time, (2) if there is no option to pause or slow it down, or (3) if the time for which the content appears exceeds 20 hours.

• the website does not provoke epileptic seizures.

Nothing on the site should flash more than 3 times per second.

• convenient website navigation is ensured.

You must ensure that users can quickly skip through blocks of the site that are present on many pages and that each page has a title that describes its topic or purpose.

In general, there are many requirements for this point. These include, for example, specifying titles for sections of pages, providing more than one way to get to a web page (for example, so that content can be found through a site search or a site map), and requirements for the content of links: their text should be immediately clear where they lead (i.e., no “here,” “click,” or “follow the link”).

And if you want your site to meet the AAA accessibility level (the highest level) according to this criterion, then please give your users breadcrumbs.

An interface element called “breadcrumbs”. It is based on the German fairy tale Hansel and Gretel: the main characters could not find their way home because the bread crumbs they left on their way were eaten by birds.

• input elements on the site can be used from different devices.

We mentioned above that your site should be usable even if the user has only the keyboard as an input device.

But there is also a reverse requirement: if the user has everything but the keyboard, they should also be able to use your site. For example, you shouldn’t have elements that require two fingers to touch at the same time (with some exceptions, of course) or input elements smaller than 24×24 pixels.

If you use drag-and-drop, make sure that the same action (usually uploading a file) can be performed in another way without dragging the file from one window to another: that is, an alternative to drag-and-drop should be provided. This can be, for example, a button to select a file.

In general, the purpose of this clause is to prevent a situation where a site is adapted for use, say, with touch devices, but it is impossible to use it if you connect a mouse and keyboard to such a device.

Understandability

• The content should be readable.

First, you have to set the language of the website programmatically. This is because automatic speech recognition does not always work correctly and is not available on all platforms. Note that the way the language of the page is recognized will determine how well it can be translated for a person who does not speak that language.

Add the language of the page here and the requirement is fulfilled.

If any element of the site is in a language other than the rest of the page, its language must also be determined programmatically.

To fulfil the requirements of this criterion for the highest level of accessibility “AAA”, you need to work on the comprehensibility of the text so that it can be understood by a 9th-grade graduate of a secondary school. To do this, you need to provide explanations for all unusual words (jargon) and abbreviations; and if possible, the text should be provided with an alternative written in simpler words.

• the interface should work predictably.

The main rule that makes the interface predictable is the requirement not to change the context unless the user requests it.

Context changes are “major changes to the content of a web page that, if made without the user’s awareness, can be disorienting to users who cannot view the entire page simultaneously”. For example, a person clicks on an input field, and the entire content of the page disappears.

The order of navigation elements should be consistent across all pages of your website.

An anti-example is the behaviour of Google search, as it changes the order of buttons depending on what the user is looking for: a place, a product, or something else.

The same elements on different pages should perform the same function. If the “Sign in” button on one page takes the user to the user account, then you can’t give it a different purpose on another page.

Every page of your website should contain support contacts in the same place: either a phone number, an email, or a link to help from the website or an automated support mechanism (for example, with AI).

• Assist users in entering data if they are required to do so.

If the input form automatically checks the content for errors, it should notify the user when they make a mistake. If it also guesses what the user might have meant, it should offer the correct options.

Each input element should be labelled so that the user understands what they are required to enter.

If the user is required to enter the same data several times (for example, a phone number for each order), you should default to the data you already have in the corresponding fields.

All input forms that have legal implications (e.g., concluding a contract, filling in details, online payment) must prevent the entry of false data. This should be done in one of the following ways:

• provide an opportunity to correct the data after it is submitted, or
• check the data automatically and allow the user to correct any errors found, or
• before submitting the form, show the user its entire content so that he or she can cancel the submission and correct errors.

If you want your site to meet the highest level of accessibility, AAA, then these safeguards should be in place in all forms of user input, not just those that have legal implications.

You shouldn’t have authorization forms that rely solely on a person’s cognitive abilities. It’s hard to explain in the abstract, but the guidelines provide clear examples: you should give users the option to recover their password if they forget it, and you shouldn’t allow them to paste copied text into the password field.

Robustness.

Finally, the robustness criterion includes only one sub-criterion called “Compatibility,” which, in turn, almost completely repeats the adaptability requirement: all elements must have their names, roles, states, properties, and values defined programmatically so that assistive technologies can process them correctly (we have already written about this a little bit above).

In the original text of the guidelines, you may have noticed that each of the criteria has a level: A, AA, AAA. Level “A” is the least accessible and contains the requirements that every website on the Internet must comply with, and level “AAA” is perfect accessibility. Although the text of the directive does not specify which level the sites subject to its requirements must meet, the European Commission insists that sites must meet the “AA” level.

What else will we have to do besides complying with WCAG standards?

The Directive requires service providers covered by it not only to comply with WCAG but also to

• provide their users with a description of the services they provide in general;
• inform users about how their service meets accessibility requirements;
• independently notify the authorized bodies of their country about violations of accessibility requirements and the measures taken to eliminate them;
• cooperate with the authorized bodies, provide them with all the information necessary to conduct inspections of compliance with accessibility requirements, and comply with their instructions to eliminate the identified violations.

Annex 1 to EU Directive 2019/882 also contains special requirements for certain types of services covered by the Directive. For example, e-commerce service providers are required to use only WCAG-compliant identification and payment methods; consumer banking service providers are required to present information about services in a way that can be understood by people with a B2 level of proficiency in the relevant language; and audiovisual media are required to accompany all audio content with subtitles that are synchronized with the video and can be customized by the user.

Is it mandatory to comply with these standards in Ukraine?

Ukraine is constantly implementing EU directives into its legislation. This means that they become part of our legislation even though the country itself is not yet an EU member.

Currently, compliance with WCAG standards is mandatory for government websites, but the Cabinet of Ministers of Ukraine is planning to draft a bill in the spring of 2023 that would introduce the provisions of the directive into Ukrainian law. Therefore, there is every reason to believe that sooner or later such a law will be submitted to the Parliament and adopted, and, in addition to government agencies, accessibility requirements will also apply to private individuals.

Even if you do not belong to the categories obliged to bring your websites into compliance with WCAG by June 28, 2025, we still recommend doing so. First, the trend is that over time, accessibility requirements are being extended to a wider and wider range of websites. Secondly, accessible websites will be easier to use for everyone, not just people with disabilities. Finally, compliance with WCAG can be a manifestation of a conscious stance: it is the best way to demonstrate that you are not indifferent to the problems of people with disabilities and adapt your products to their needs.

A building with a ramp is easier to enter not only for people in wheelchairs, but also for mothers with strollers, tourists with suitcases, or people with bicycles. The same principle applies to website accessibility: subtitles can be used not only by people with hearing impairments but also by those who have insufficient language skills or those who ride the subway without headphones. Alternative text for images will help not only those who use screen readers but also those who cannot load images due to slow internet. By making your sites accessible, you improve the experience for a large number of users at once, and we can’t think of a single reason why you shouldn’t do it

So, when you build websites, consider the accessibility requirements, as both users will have a better experience and you will save yourself from fines in the EU.