What WCAG compliance really means for the public sector
If you work in a municipality, school, library or cultural organisation, you have probably heard the phrase wcag compliance at least once. It often sounds like a technical requirement that somehow needs to be sorted out. In practice, it is much simpler and more important than that: your website must be understandable, manageable and accessible to people who browse differently from most.
One visitor reads the text with a screen reader. Another cannot use a mouse and moves only with a keyboard. A third struggles to see grey text on a white background. A fourth fills in a form on a phone, in the sun, hurrying between offices. Website accessibility is not just about one user group. It is about whether a person can find information and complete an action without extra barriers at all.
In the public sector, this is especially sensitive. When parents cannot open the canteen menu on a school website using a keyboard, it is inconvenient. When a social support form on a municipality page has no clear field labels, that becomes a real barrier for some residents to get a service. And when a museum events calendar cannot be read by a screen reader, a person is simply left outside, even if they could physically come to the museum.
WCAG 2.1 AA: not a mysterious code, but clear rules
WCAG stands for the Web Content Accessibility Guidelines. In the public sector, the most common reference is WCAG 2.1 AA. It sounds dry, but the point is fairly straightforward: a website must work in ways that allow different people to use it without unnecessary barriers.
WCAG is based on four principles. Content must be perceivable, operable, understandable and robust. In other words, information must be visible or audible, the website must be usable not only with a mouse, texts and actions must be clear, and the system itself must work with assistive technologies.
AA is the standard that public-sector websites are usually expected to meet. It covers not exotic cases, but basic things that matter every day:
- photos and icons must have meaningful alternative descriptions if they convey information;
- text and background contrast must be sufficient for the text to be readable;
- the whole website must be usable with a keyboard;
- form fields must have clear labels and understandable error messages;
- headings must be arranged in a logical order so the page is understandable not only to the eye;
- links must clearly say where they lead, rather than hiding behind “click here”;
- videos need subtitles if people speak in them;
- content must not break when text is enlarged or the page is opened on a phone.
If a school website has the timetable uploaded only as a blurry photo, that is already a problem. If a library publishes a PDF file that a screen reader cannot read, the problem does not disappear simply because the document is not on the website itself. Accessibility for people with disabilities also covers documents, forms and regularly updated content.
Who must meet the requirements
In the EU, these requirements are relevant for public bodies and organisations that provide information and services online. In practice, that means municipalities, the organisations under them, schools, preschools, libraries, museums, cultural centres, healthcare organisations and other public organisations whose website is not just a formal visiting card.
In short, if residents read news on your organisation’s website, look for contacts, fill in an application, register for a service, download documents or check a timetable, accessibility applies to you. This is not the kind of area where you can wave it away and say that “our audience is small”.
Another important layer is mobile apps, if the organisation has them. The requirements apply not only to a website opened in a browser. For example, if a municipality has a resident registration or notification app, its use must also be accessible.
What the deadlines are and where the EAA comes in
When it comes to public-sector websites, accessibility requirements in Europe are nothing new. For most organisations, this is no longer a future standard but an existing one. In other words, today the question is more often not “do we need this?”, but “how well does our website actually comply?”
Alongside this, EAA requirements are mentioned more and more often — the European Accessibility Act. It is more closely linked to certain products and services on the market, especially in the private sector, but its effect is broader: accessibility becomes a general rule, not an exception. That is why public-sector organisations should not only reach the minimum formally, but also look at the website as a long-term service that should be convenient for everyone.
The EAA matters for another reason too. It strengthens the overall direction in Europe: digital services should be accessible from the start of the design process, not fixed after a complaint. If you are creating a new school website today or updating a hospital registration form, it is better to include accessibility from the start. Fixing it later takes longer, costs more and is much more stressful.
The most common mistakes on public-sector websites
When reviewing EU public-sector pages, the same problems often repeat. Not because teams do not want things in order. Simply because websites grow gradually: one module was added five years ago, another section was created in a hurry before September, and a third was inherited from a previous supplier.
Here are a few common examples worth checking first:
- on municipality news cards, links are given the same name, so a screen reader reads “read more” five times and nothing else;
- on a school page, the list of documents is made up of scanned PDF files where the text is actually an image;
- a museum events calendar is controlled only with a mouse, and it is impossible to move between dates with a keyboard;
- a library registration form says only “error”, but does not explain which field needs to be corrected;
- on a healthcare organisation website, the contrast is so weak that an older person simply cannot read the doctors’ appointment times;
- in the mobile version, the menu opens, but focus “escapes”, so keyboard use becomes almost impossible.
Such small things seem technical only until you try to use the website yourself without a mouse, with enlarged text or with a screen reader. Then it quickly becomes clear where the visitor gets stuck.
How to check whether your website needs fixes
The good news is that you can get a first impression without a long project. You do not need to open dozens of standards tables straight away. Start with a few simple actions.
1. Move through the website using only the keyboard
Press the Tab key and move through the page. Can you clearly see where you are? Can you open the menu, fill in a form, reach buttons? If you get stuck anywhere, so will the visitor.
2. Increase the text size
In the browser, zoom to 200 per cent. If the text overlaps, buttons disappear or you need to scroll sideways where that should not be necessary, the website has problems.
3. Check the contrast
Light grey text on a white background may look neat in a design mock-up. In real life, it often means that some people will not be able to read the content. It is worth checking contrast with tools, not with the eye.
4. Turn on a screen reader
Even a short test tells you a lot. Is the page heading clear? Are the links understandable? Do the form fields have names? If, when reading, you hear only “button”, “link”, “graphic element”, the content needs work.
5. Review documents and forms
Often organisations sort out the main pages, but forget PDF documents, application forms and registration windows. Yet that is exactly where the visitor performs the most important action.
Still, a self-check shows only part of the picture. If you want to understand clearly where the mismatches are and what to fix first, you need an accessibility audit. It helps you avoid guessing and gives you a concrete list: what does not work, why it matters and how to fix it.
What an accessibility audit gives you
A proper audit is not just an automatic tool report with coloured markers. Automated checks are useful, but they do not tell the whole story. For example, a tool may see that an image has alt text, but it will not judge whether the text is meaningful. It may detect a form field, but it will not say whether the error message is understandable to a person.
In practice, an accessibility audit should cover several layers: automated tests, manual review, usage scenarios and priorities. In other words, not just “what is wrong”, but also “what should be fixed now, and what can be planned for later”.
For example, a school website may have 300 old news items and 40 PDF documents. There is no need to fix everything in one week. Usually the first step is to sort out the main templates, menu, contacts, news pages, document sections and the most important forms. That sequence allows a real change to happen faster, instead of drowning in details.
How to prepare if you are planning a new website
If the website is still to be built, you have the best possible starting position. It is worth putting accessibility not at the end of the project, but right at the beginning — together with the structure, design, content plan and testing.
A very concrete example: if a cultural centre decides in advance that event cards will always include a clear title, date, venue and an accessible registration link, there will be no need later to fix dozens of hand-made exceptions. If a library agrees on how link names and headings are written, the content becomes tidier straight away.
The technology is not the only thing that matters here. Staff who upload content also need to know the basics: how to name a link, when to add alternative text, why not to put all information into an image. Otherwise, even a well-prepared website can grow obstacles again within six months.
Accessibility is not just a formality
Sometimes this issue is treated as just another line in procurement documents. But in reality, website accessibility is directly linked to service quality. If a person cannot register, find a document or read a message, the service does not work for them, even if the website technically “works”.
For public-sector organisations, this is especially important because they serve everyone. Not only people who browse quickly, not only people who see well, not only people who are comfortable in the digital environment. That is exactly why wcag compliance is not an optional extra. It is a basic requirement if you want the website to do its job.
If you do not know where to start, begin with a simple question: can a person who uses the site differently from me complete the most important action on this website? If the answer is unclear, it is time to check concretely, not by intuition.
Want to know whether your website meets WCAG requirements? Get a free accessibility and contrast report — Tobalt will check your website and provide concrete suggestions to ensure compliance.