Web accessibility is now mandatory: Romanian Law 232/2022

On 28 June 2025 the digital accessibility obligations introduced by Directive (EU) 2019/882 — known as the European Accessibility Act — came into force across the European Union. In Romania, the directive was transposed by Law no. 232/2022, and from that date a range of digital products and services, among them eCommerce, must meet accessibility requirements.

For many companies, that passed completely unnoticed. This article explains, for someone without a legal department: what changed, who falls under it, what “accessible” means concretely, what you can check yourself today, and what to do if your site is not compliant.

A necessary note. We are a web design agency, not a law firm. This article describes what these requirements mean for building a site and how they are checked technically. For your own company’s legal position, consult a specialist and the official text of the law.

What changed on 28 June 2025
Does my company’s website have to be accessible
The legal framework, briefly
What accessible means: the four principles
The 12 frequent problems on Romanian websites
Contrast: the check you can do today
Keyboard navigation: the two-minute test
The accessibility statement
Who enforces it and what the penalties are
A 90-day compliance plan
Alternative text: how to write it properly
Forms, the most fragile point
What automated tools catch and what they do not
What we found on our own site

What changed on 28 June 2025

Until then, web accessibility was a legal obligation only for public institutions. For the private sector it was good practice — recommended, appreciated, but optional.

From 28 June 2025, a range of services offered to consumers by private economic operators has to meet accessibility requirements. eCommerce is explicitly among them.

What that means in practice

An online store has to be usable by someone who:

cannot see and navigates with a screen reader;
cannot use a mouse and navigates entirely from the keyboard;
has poor sight and enlarges the page two or three times;
does not distinguish colours well;
has difficulty concentrating or processing text.

It is not an exotic requirement. European statistics indicate a significant proportion of the adult population with some form of disability — a considerable part of the market, which until now was simply excluded from many online stores.

Does my company’s website have to be accessible

It depends what you do with it. If you sell online to consumers — that is, you have eCommerce — you fall under it, unless you are a microenterprise providing services. If you have only a business website, with no online sales, you are generally not directly caught by the obligation, but indirect requirements can still affect you: for instance, when you work as a supplier to public institutions, which have obligations of their own.

Who is caught, in brief

Situation	Caught?
B2C online store	yes
Consumer banking services	yes
Passenger transport, ticketing services	yes
Electronic communications	yes
E-books and content platforms	yes
A business website, with no online sales	generally, not directly
A microenterprise providing services	exempt, as a rule
A supplier to the public sector	indirectly, through the buyer’s requirements

The microenterprise category is defined by headcount and turnover thresholds; check your exact position with your accountant or legal adviser, because the exemption does not apply identically in every case.

The argument that counts even if you are not caught

An accessible site is better structured, easier to use on a phone, and easier for search engines to read. Correct headings, alternative text on images and good contrast are simultaneously accessibility requirements and optimisation good practice. You are not doing extra work; you are doing the same work better.

The legal framework, briefly

Directive (EU) 2019/882  →  Law no. 232/2022  →  EN 301 549  →  WCAG 2.1 AA
   European                  transposition        the European     the technical
   Accessibility Act         into Romanian law    standard         criteria

Directive (EU) 2019/882 sets the obligations at European level.
Law no. 232/2022 transposes it into Romanian legislation, applying from 28 June 2025.
EN 301 549 is the harmonised European standard; conformity with it creates a presumption of compliance.
WCAG 2.1, level AA is the set of verifiable technical criteria the standard adopts for web content.

In practice, “make the site compliant” means WCAG 2.1 level AA.

Sources: AmCham Romania(opens in a new tab), W3C — accessibility policies for Romania(opens in a new tab), Recite Me(opens in a new tab).

What accessible means: the four principles

WCAG is organised around four principles. Content has to be:

1. Perceivable

Information has to be perceivable, whichever sense is used.

Every image that conveys information has alternative text.
Purely decorative images are marked as such, so screen readers ignore them.
Video content has captions.
Information is not conveyed by colour alone — a field with an error cannot be marked only in red.
The contrast between text and background is sufficient.

2. Operable

The interface has to be usable, whatever the input device.

Everything that can be done with a mouse can be done from the keyboard.
Focus is visible: you can see which element you are on.
There are no “keyboard traps” — places you cannot Tab out of.
There is a way to skip the menu that repeats on every page.
Nothing flashes at a rate that could trigger seizures.
There are no arbitrary time limits.

3. Understandable

The page’s language is declared in the code, so readers pronounce it correctly.
Navigation is consistent between pages.
Error messages say what is wrong and how to fix it, not just that something is wrong.
Form fields have labels associated in the code, not just text beside them.

4. Robust

The code is valid and semantically structured — a button is a button, not a div with a click handler attached.
It works with assistive technologies, not just in the browser you tested in.

The 12 frequent problems on Romanian websites

From the audits we carry out, in order of frequency:

Insufficient contrast — light grey text on a white ground, very fashionable and very hard to read.
Images with no alternative text, or with useless alternative text of the image1.jpg kind.
Invisible focus — the focus outline has been removed from the styles because “it looked ugly”.
Forms with no associated labels — text written above the field, but with no connection in the code.
Text inside an image — a banner with the offer written into the picture. Invisible to readers and to Google.
Buttons that are not buttons — elements that behave like buttons but have no declared role.
Headings used for size, not for hierarchy.
A mobile menu that cannot be closed from the keyboard.
Modal windows that do not trap focus — you press Tab and end up behind them.
Colour as the only indicator — invalid fields marked only in red.
Automatic carousels with no way to stop them.
The page language undeclared, or wrongly declared as English on a Romanian site.

The first four cover the overwhelming majority of problems on an ordinary site, and all four can be fixed without a rebuild.

Contrast: the check you can do today

It is the one criterion you can check yourself, with no technical knowledge, in five minutes.

The thresholds

Type of text	Minimum ratio
Normal text	4.5:1
Large text (over ~24 px, or ~19 px bold)	3:1
Interface elements and graphics	3:1

How to check

Take the text colour and the background colour from your design, in HEX notation.
Enter them into a public contrast checker — there are several free ones.
Read the ratio and check whether it passes level AA.

Where problems usually are

Secondary text, “discreet grey”, under headings.
Text on buttons, especially white text on coloured buttons.
Text placed over a photograph.
Text on disabled elements.
Footer text, where grey on grey is common.

Text over a photograph is the hardest case, because the photograph varies. The fix is a semi-transparent layer between image and text, or a block of solid colour behind the text.

The second test you can do yourself, right now.

The procedure:

Open your site’s home page.
Let go of the mouse. Do not touch it at all.
Press Tab repeatedly and work through the whole page.

What to watch for:

Check	What should happen
Can you always see where you are?	The focused element has a visible outline
Is the order logical?	Top to bottom, left to right
Do you reach every link and button?	Nothing is skipped
Can you open the mobile menu?	With `Enter` or `Space`
Can you close what you opened?	With `Esc`
Can you fill in and submit the form?	Without a mouse, start to finish
Can you skip the menu?	A “Skip to content” link appears on the first `Tab`

If the answer to any of these is “no”, you have an accessibility problem — and, very probably, a usability problem too, for many more people than you think.

The accessibility statement

A public page on the site describing the state of accessibility. What it contains:

The company’s commitment on accessibility.
The reference standard — usually WCAG 2.1 level AA.
The degree of conformity: full, partial or non-conformant.
What is not accessible and why, where applicable, with an estimated date for fixing it.
The date of the last evaluation and the method used.
A way to get in touch for anyone who meets a barrier.
What happens if they get no reply.

Honesty is the criterion

A statement saying “partial conformity” and listing concretely what is missing is better than one declaring full conformity and being contradicted by the first test. The statement is not a certificate, it is a description of the state of things.

It is linked from the footer, on every page.

Who enforces it and what the penalties are

Supervision falls to the authorities designated by law. In practice, the mechanism starts in two ways: through an inspection on the authority’s own initiative or, more frequently, on the basis of a complaint from a user who could not use the service.

The penalty regime provided for includes fines, and in cases of non-compliance the authorities can order measures going as far as withdrawing or suspending the service from the market.

The real risk, in order of likelihood

A complaint from a user. The most likely scenario, and the easiest to avoid: a visible way to get in touch and a prompt reply resolve most situations before they become formal.
A contractual requirement. Large companies and public institutions increasingly demand compliance from suppliers.
An inspection.

A 90-day compliance plan

Days 1–15 · Assessment

Run an automated check on the main pages. Automated tools catch roughly a third of the problems — useful as a starting point, insufficient as a verdict.
Do the keyboard test on the five most important journeys: the home page, a product or service page, the contact form, the basket and the checkout if you sell online.
Check every contrast combination in the design.
Note everything in one document, with the page and the problem.

Days 16–45 · The easy fixes

In order of result-to-effort ratio:

Restore the visible focus outline. The biggest improvement for the smallest effort.
Correct insufficient contrasts.
Add alternative text to every image that conveys information; mark the decorative ones.
Associate the labels with the form fields, in the code.
Declare the page language.
Add the “Skip to content” link.
Fix the heading hierarchy.

Days 46–75 · The structural fixes

Interactive components get correct roles and states.
Modal windows trap focus and close with Esc.
The mobile menu becomes fully operable from the keyboard.
Error messages become explicit and are announced.
Carousels get a pause control, or go.

Days 76–90 · Verification and publication

Retest everything, manually.
Test with a screen reader, even briefly — the one built into your operating system is enough for a basic test.
Publish the accessibility statement, with what is compliant and what is not.
Set up a recurring check: every new page passes the keyboard test before publication.

Alternative text: how to write it properly

It is the best-known requirement and the worst applied. Wrong alternative text is sometimes worse than none.

The basic rule

Alternative text answers the question: what information does this image convey? Not “what can be seen in it”.

The same photograph gets different text according to its role:

Context	Suitable alternative text
On a portfolio project page	`The Hotel Apollonia home page, with the room gallery`
As a generic illustration in an article	`""` — decorative, adds no information
As the sole source of a piece of information	all the relevant content, in text

The cases that go wrong

The image is a link. The alternative text describes the destination, not the image. A logo that leads home: Home, not The company logo.

The image contains text. The text in the image is reproduced in full in the alternative. Better: do not put text in an image. It cannot be read by screen readers, it cannot be translated, it cannot be found by Google, and it goes blurry when enlarged.

The image is a chart or a graph. The short alternative says what it is; the data goes in text or in a table alongside. A chart with no textual equivalent is inaccessible information.

The image is purely decorative. It is marked with an empty alternative, so it gets skipped. A background described as abstract background image merely interrupts the reading.

What not to write

image, photo1, IMG_2847.jpg
“Image of…” or “Photograph showing…” — the screen reader has already announced that it is an image
Keywords stuffed in. It is useless for ranking and a poor experience for whoever is listening.

Length

Under 125 characters, as a rule. If you need more, the information does not belong in an attribute — it belongs in the page.

Forms, the most fragile point

The form is where a conversion is actually lost, not merely where a requirement is broken.

The label

Every field has to have a label associated in the code, not just text written above it. That association is what lets the screen reader announce “Phone, edit field” instead of “edit field”.

It also has a visible effect for everyone: a correctly associated label focuses the field when it is tapped — a larger target for fingers on a phone.

Text inside the field is not a label

A field showing “Name” inside it and clearing it as you type leaves the user with no reference. Anyone interrupted halfway no longer knows what they were filling in. The label stays visible; the text inside the field is, at most, an example of the format.

Errors

A correct error does three things:

It says what is wrong and how to fix it. “Enter an email address containing @”, not “Invalid field”.
It is connected to its field, so it gets announced on focus.
It does not rely on colour alone. Red plus text plus an icon.

Required fields

Marked both visually and in the code. An asterisk on its own, with a legend at the foot of the page, is not enough.

The complete test

Fill in your own contact form entirely from the keyboard, without a mouse, from the first field to the confirmation message. Then get a field wrong on purpose and see whether you understand what happened without looking at the colours.

What automated tools catch and what they do not

An important nuance before you rely on a green report.

What they catch

Insufficient contrast.
Missing alternative text.
Missing labels on forms.
An undeclared page language.
A wrong heading hierarchy.
Invalid code, incorrect roles.

What they cannot catch

Whether the alternative text is correct. A tool sees that the attribute exists; it cannot know whether photo1 describes the image.
Whether the tab order makes sense. It only checks that the elements are reachable, not that the order is logical.
Whether an error message is useful.
Whether a complete journey is achievable from the keyboard.
Whether a heading actually describes its section.

The proportion

Automated tools generally identify around a third of the real accessibility problems. A report with no errors does not mean an accessible site — it means you have no problems of the automatically detectable kind.

Manual testing remains mandatory, and the most effective part of it takes two minutes: working through the page from the keyboard.

What we found on our own site

We applied the same process to digital-art.ro when we rebuilt it. What we changed, concretely:

The mobile menu — rebuilt as a panel that traps focus, closes with Esc, and returns focus to the button that opened it. The old implementation was a keyboard trap.
The “dead” links in the menu — the parent categories were links to #, focusable and announced as links that led nowhere. They became group labels, which is the correct semantics.
The FAQ — built as native accordion elements, keyboard-operable from the start, in place of a script-based implementation.
The page language — the old site declared English. Romanian is now declared, which also changes the pronunciation in screen readers.
Motion — every animation respects the system preference for reduced motion.
The “Skip to content” link — added, visible on the first press of Tab.
Contrast — the palette was rebuilt as a system of values with defined roles, checked, instead of shades chosen ad hoc.

We published the result in our accessibility statement, including what is not yet perfect.

If you sell online and have not yet checked where you stand, start with the keyboard test in this article — it takes two minutes and tells you immediately whether you have a problem.

For a full audit or for remediation, write to us. We check the site, give you the list of problems in order of priority, and a realistic timescale for each.

Contents