Accessibility of Ukrainian public-sector sites: DSTU EN 301 549 and Resolution No. 757
· 6 min read
Public-sector websites in Ukraine must meet accessibility requirements, and the technical basis of these requirements is the national standard DSTU EN 301 549:2022 (ДСТУ EN 301 549:2022), identical to the European EN 301 549 V3.2.1; for the web this means the WCAG 2.1 criteria at levels A and AA. The related legal act is Cabinet of Ministers of Ukraine Resolution No. 757 of 21 July 2023 "Certain issues of accessibility of information and communication systems and documents in electronic form" (Деякі питання доступності інформаційно-комунікаційних систем та документів в електронній формі). For a contractor this means something simple: accessibility requirements appear in the terms of reference of tenders, and at acceptance the client wants to see a check report.
DSTU EN 301 549 and Resolution No. 757: what they are
DSTU EN 301 549:2022
This is a Ukrainian national standard that reproduces the European EN 301 549 version V3.2.1. The standard covers not only websites but also mobile apps, documents, software and hardware. For web pages, its web section refers to the WCAG 2.1 success criteria at levels A and AA: contrast, text alternatives, field labels, keyboard operation, page structure, compatibility with assistive technologies and so on.
An important nuance: in the EU a new version, EN 301 549 V4.1.1, based on WCAG 2.2, has already been published (September 2026). As of October 2026 the Ukrainian version of the standard corresponds to V3.2.1. If a site already meets WCAG 2.2 AA, it also meets WCAG 2.1 AA, so checking against the newer version breaks nothing. For the differences, see the article what changed in WCAG 2.2.
Resolution No. 757
The resolution of 21 July 2023 concerns the accessibility of information and communication systems and documents in electronic form in the public sector. We do not retell its individual provisions here: before preparing a proposal or terms of reference, read the current version on the official Government website (the link is in the "Sources" section) and check exactly which systems and documents are covered, who is responsible for implementation and which deadlines are set.
Who it concerns in practice
- Contractors who build websites and services for government bodies, local communities (hromadas), hospitals, educational institutions and other managers of public funds.
- Studios taking part in tenders via Prozorro where the terms of reference specify WCAG 2.1 or DSTU EN 301 549.
- Support teams who, during the warranty period, are responsible for making sure new pages do not worsen accessibility.
For private businesses in Ukraine such requirements are not directly established for now. Draft law No. 14278 "On Digital Accessibility" (Про цифрову доступність), prepared on the basis of European directives 2016/2102 and 2019/882, was registered in the Verkhovna Rada on 5 December 2025. Whether it has been adopted and in what wording must be checked on the parliament's website: do not build sales on the assumption that the law is already in force. Separately: Ukrainian companies that sell to consumers in the EU may fall under the European EAA. See the EAA guide for more.
How requirements get into the terms of reference and acceptance
The typical path looks like this:
- The tender's terms of reference contain a requirement: "the website must meet the accessibility requirements of WCAG 2.1 level AA / DSTU EN 301 549:2022".
- During development the team follows these criteria: semantic markup, contrast, labels, keyboard.
- At acceptance the client asks for confirmation of conformance: a check report, a test record or a specialist's opinion.
- During the warranty the client's staff add content, and new pages often bring old errors back: images without alt, PDFs without structure, tables as images.
The weakest points are steps 3 and 4. The acceptance report is often made once, by hand, and after that nobody checks the site regularly.
What report a contractor needs
An acceptance report must be clear not only to the developer but also to the client's representative who signs it. What it should contain:
- A list of the checked pages and the date of the check.
- Problems found, mapped to the WCAG 2.1 criteria and the clauses of DSTU EN 301 549:2022.
- Severity and priority of each problem.
- Progress: what was fixed between the first and the repeat check.
- An honest limitation: that this is an automated check, which criteria were checked automatically and what needs a manual check.
Our service produces such a report in Ukrainian, mapped to DSTU EN 301 549:2022, and can check the site weekly throughout the warranty period. Important: this is an automated check, not a full audit, and not legal advice. Automation finds only some of the problems. If the terms of reference require an expert opinion, the automated report must be supplemented by a manual check: keyboard walkthrough, work with a screen reader, document checks. More on the limits of automation on the how it works page.
Typical errors on public-sector websites
- PDF documents without a text layer, scanned orders and decisions that a screen reader cannot read.
- News with photos without alt or with the alt "photo".
- Tables as images (timetables, citizen reception schedules).
- Contact forms without field labels and with a CAPTCHA that has no accessible alternative.
- Insufficient contrast in the header and footer with the coat of arms and the community colours.
- A "visually impaired version" that replaces fixing the main version but does not meet the criteria itself.
Most of these errors match what we see on commercial websites; a list with explanations is in the article 10 most common accessibility errors, and a self-check list is in the WCAG 2.2 checklist.
Why not a "special version" or a widget
A separate "version for the visually impaired" or a widget that enlarges the font and switches on contrast does not make the main site accessible. A screen reader still sees the code of the main version, and the markup errors do not go anywhere. Details in the article why overlays do not work.
A short plan for a contractor
- Check the templates (home page, news item, document, contact form) before handover, not after.
- Fix errors in the templates: that way they will not repeat across thousands of pages.
- Train the client's content managers to fill in alt text and publish accessible documents.
- Hand over the work with a report mapped to DSTU EN 301 549:2022.
- Check the site regularly during the warranty and show the client the progress.
Answers to frequent questions
What is DSTU EN 301 549:2022? A national standard identical to EN 301 549 V3.2.1; for the web, the WCAG 2.1 A and AA criteria.
What does Resolution No. 757 regulate? The accessibility of public information and communication systems and electronic documents; details are in the current version on the Government website.
Do the requirements apply to businesses? For now mainly to the public sector; the status of draft law No. 14278 needs to be checked.
Is an automated report enough? It is not a full audit: an expert opinion also requires a manual check.
Check one page of your site for free and see what the report looks like.