A high accessibility score in PageSpeed Insights does not prove that a website is accessible. Automated tests are useful, but they cover only part of the standard and only the page they receive.
Web accessibility is often presented as a complex technical requirement or something that can be added after launch. A better starting point is much simpler: who can use the website, and who encounters barriers?
According to the European Commission, around 90 million people in the European Union live with a disability. Accessible design also helps people whose needs change temporarily or over time: someone with an injured hand, a person who cannot use a mouse, a user with low vision, or a customer who needs captions to follow a video.
Accessibility is not a separate feature added at the end of a project. It is part of how the content, interface, and code are designed.
First: could the legal requirements apply to you?
We have created a short test that provides preliminary guidance. It is not a legal determination and cannot cover every exception, transitional measure, or organisation-specific circumstance. Your answers remain in the browser and are not sent to us.
Could the legal accessibility requirements apply to you?
Three questions, for preliminary guidance. Your answers remain in the browser and are not sent to us.
Do you represent a public institution or authority (city hall, ministry, agency, public school or hospital…) or a body governed by public law — established for a general interest and financed, supervised, or controlled by the state?
This quiz provides general guidance only, based on the answers you enter. It is not legal advice and does not officially determine whether a specific legal obligation applies to an organisation.
If the result suggests that the legislation may apply, review the relevant law or ask a qualified lawyer. The rest of this article explains what accessibility standards cover and the two main legal frameworks relevant in Romania.
What the PageSpeed score actually tells you
This article started with an internal test. We checked a domain that we expected to contain a website, but the server displayed only a basic directory listing. The page received an accessibility score of 93 out of 100.
The score was not necessarily wrong. Lighthouse had assessed the minimal page it was given. It could not know what digital product was supposed to exist on the domain, and it could not evaluate pages, forms, or user journeys that were not loaded.
That distinction matters. PageSpeed Insights uses Lighthouse to run automated checks on a specific page in a specific state. It can identify issues such as:
- insufficient colour contrast;
- images without text alternatives;
- buttons without accessible names;
- invalid ARIA relationships;
- some heading-structure problems.
Other questions require human review:
- Does the reading order announced by a screen reader make sense?
- Can the complete journey be used with a keyboard?
- Is the focus indicator visible?
- Do text alternatives accurately describe important images?
- Do error messages explain what happened and how to fix it?
A low score shows that the automated test detected issues that need investigation. A high score is a positive signal, but it does not prove that the page, the full website, or the digital service is accessible.
What accessibility standards cover
WCAG — the Web Content Accessibility Guidelines — is the set of web-accessibility recommendations published by W3C. The current version is WCAG 2.2.
For the European public sector, EN 301 549 is the harmonised standard used to assess the accessibility of ICT products and services. It includes web requirements, but its scope is broader than websites. For obligations under Romanian Law 232/2022, organisations must consider the requirements of the legislation and the harmonised standards that apply at the time of assessment. Legal compliance cannot be reduced to a PageSpeed score or a small set of automated checks.
For web content, the four core principles can be explained in plain language:
- Perceivable — information must be available in forms that different users can perceive. Important images need text alternatives, videos need captions, and text needs sufficient contrast against its background.
- Operable — important functions must work without a mouse. Keyboard navigation should be supported, focus must remain visible, and users must not become trapped in menus, dialogs, or forms.
- Understandable — language, navigation, and forms should be clear. When something goes wrong, the error message should explain the problem and how to correct it, rather than showing only a red outline.
- Robust — the structure and code must be interpreted reliably by browsers and assistive technologies. Interactive elements need correct programmatic roles, names, and states.
These requirements are not separate from the overall quality of a website. In many cases, a more accessible product is also clearer, easier to test, and easier to use.
Who is covered by Romanian law?
Two main legal frameworks are relevant to the subject of this article. The summary below is general guidance and does not replace the legislation.
1. Public-sector bodies
Romanian Emergency Ordinance 112/2018 regulates the accessibility of websites and mobile applications operated by public-sector bodies. This includes central and local public authorities and institutions, bodies governed by public law, and certain associations formed by those bodies.
A body governed by public law is not defined by majority public funding alone. Its purpose, legal personality, and relationship to public funding, supervision, control, or board appointments must be assessed together.
Covered organisations must address accessibility and publish an accessibility statement. The Authority for the Digitalisation of Romania is responsible for monitoring. The legislation also includes specific provisions, including the assessment of a possible disproportionate burden.
2. Certain products and consumer services
Romanian Law 232/2022 transposes the European Accessibility Act. It does not automatically apply to every business that owns a website. It applies to the products and services included within the law's scope.
Covered services include: e-commerce, electronic communications, services providing access to audiovisual media, certain digital elements of passenger transport services, consumer banking services, and e-books with their dedicated software. The legislation also covers other situations, including the accessibility of responses to emergency communications to 112, and sets requirements for certain products — from e-readers to payment terminals.
The rules apply to services provided to consumers after 28 June 2025, but transitional measures exist for certain contracts and products used before that date. The date alone is therefore not enough to determine whether a specific situation is covered.
Microenterprises providing services are exempt: undertakings with fewer than ten people and an annual turnover or annual balance-sheet total not exceeding EUR 2 million. The same exemption does not apply to products in the same way.
When the position is unclear, do not rely on an online questionnaire alone. Read the legislation and seek legal advice for a formal conclusion.
Why an overlay does not establish compliance
The growth of accessibility obligations has also created a market for widgets that promise to make any website compliant by installing a single script. These products are commonly described as accessibility overlays.
This is different from preference controls that are deliberately built into a product, such as text-size or contrast settings. The concern is with third-party services that claim to identify and repair every accessibility issue automatically.
An overlay may correct some isolated problems. It cannot reliably decide whether alternative text accurately describes an image, whether the reading order makes sense, whether a complex journey works with a keyboard, or whether an error message is useful. It also cannot guarantee that its changes remain correct when a dynamic interface updates.
The Overlay Fact Sheet, supported by accessibility specialists and assistive-technology users, documents these limitations and recommends that overlays should not be treated as a compliance solution.
Any promise of legal compliance delivered solely through a widget should be examined carefully.
What you can check today
You do not need a paid tool to begin.
- Use the website with a keyboard only. Navigate with Tab, Shift+Tab, Enter, Space, and the arrow keys. Check whether focus is visible and whether every important component can be opened and closed.
- Run an automated test. Use PageSpeed Insights or our free tool. Treat the result as a list of automatically detectable issues, not as a certificate.
- Review images, contrast, and forms. Do important images have text alternatives? Is the text easy to read against its background? Do fields have labels, and are errors explained?
- Test complete user journeys. Contact, sign-in, search, purchase, and booking flows must be tested from beginning to end, not only on the homepage.
- Plan a manual audit when legal obligations or critical journeys are involved. A meaningful audit combines automated checks, manual testing and, where appropriate, assistive technologies.
In our own projects, accessibility is part of the acceptance criteria: we test automatically with axe-core, using WCAG 2.2 AA as the benchmark, and manually with the keyboard, before release.
You can start with our free tool. The report identifies automatically detectable issues and explains what still requires human review.
Conclusion
An accessible website is not a separate version built for a separate group of users. It is a website that removes avoidable barriers and can be used by more people in more situations.
The law makes accessibility a formal obligation for public-sector bodies and for certain products and services. Beyond compliance, the practical reason is straightforward: a service that more people can use is a better service.
If you need to understand the real issues on your website, write to us — we can begin with an assessment and separate urgent fixes from improvements that can be planned later.
