Web accessibility means a site or app can also be used by people with disabilities (vision, hearing, motor, cognitive) — and, in practice, by anyone on a phone in the sun, with one hand busy, or on a bad connection. WCAG (Web Content Accessibility Guidelines) is the W3C’s international set of technical criteria for what “accessible” means on the web. In Europe and Romania, though, WCAG is not only “good practice”: it sits behind legal duties. At UNICORE it belongs in UI/UX and websites / web apps — a requirement from day one, not a final ornament.
The legal map, briefly (EU → RO). There are two European “tracks”: (1) Directive (EU) 2016/2102 — accessibility of public-sector websites and mobile apps (Web Accessibility Directive / WAD). (2) Directive (EU) 2019/882 — the European Accessibility Act (EAA), for certain products and services on the internal market (including many consumer digital services). Romania transposed them: GEO no. 112/2018 (approved by Law no. 90/2019) for the public sector; Law no. 232/2022 for EAA product/service requirements (effective application from 28 June 2025).
The common technical standard: EN 301 549 (and the WCAG link). In procurement and conformity assessment, the harmonised European reference for accessible ICT is EN 301 549 (“Accessibility requirements for ICT products and services”). In practice, for web content, EN 301 549 incorporates WCAG 2.1 Level AA. So when you hear “we need WCAG AA,” in RO/EU legal language it usually means: align with EN 301 549 for the covered web/mobile components. You do not invent your own standard — you follow the European criterion.
Public sector: GEO 112/2018 + Law 90/2019. The ordinance sets accessibility requirements for websites and mobile apps of public-sector bodies — from central and local administration to other entities covered by the “public-sector body” definition. The goal: citizens (including persons with disabilities) can perceive, navigate, and use public digital services. ADR (the Authority for Romania’s Digitalization) monitors / oversees compliance under HG no. 89/2020 and the monitoring norms (ADR Decision no. 815/2022).
What a public institution must typically do. (1) Make the site / app accessible to the requirements (in practice: EN 301 549 / WCAG 2.1 AA on covered content). (2) Publish an accessibility statement — conformity status, what is still inaccessible, why, and alternatives. (3) Provide a feedback mechanism so users can report barriers. (4) If invoking a “disproportionate burden” for some content, assess it with reasons and publish the assessment with the statement — not a generic excuse. Lack of knowledge, “it was not a priority,” or an inaccessible CMS are not typical legitimate reasons under the GEO’s spirit.
Disproportionate burden — what it means (and does not). The GEO allows, in justified cases, not making certain content fully accessible if measures would impose an excessive organisational / financial burden or endanger the institution’s ability to fulfil its mission — also weighing harm to citizens, especially persons with disabilities. It is not “we drop accessibility.” It is a documented exception, temporary in logic, with alternatives where possible. For procurement: buying inaccessible software/CMS does not erase the duty — vendor choice matters from the start.
Private sector: Directive 2019/882 (EAA) + Law 232/2022. From 28 June 2025, Law 232/2022 applies accessibility requirements to a range of products and services placed on the market / offered to consumers — including, in the EAA’s spirit, services such as e-commerce, consumer banking, electronic communications, passenger-transport elements, e-books / reading software, and related digital interfaces (websites, apps, self-service terminals, where applicable). Not every Romanian company is “automatically” covered for everything it does online — what matters is whether the product/service falls in scope. When it does, digital interfaces must allow perception, operation, and understanding on an equal basis, compatible with assistive technologies.
Exceptions and transitions (EAA / Law 232 — plainly). The law provides thresholds and transition periods (e.g. certain microenterprises may be exempt under criteria; service contracts concluded before 28.06.2025 may continue until expiry but not beyond a multi-year cap; some self-service terminals have long replacement horizons; media / documents published before the date may have exemptions). Do not treat this as “it does not concern us”: check scope, service type, and timeline with legal counsel — then align the digital product. Administrative sanctions (fines, product/service measures) are part of the architecture; supervisory authorities differ by domain (e.g. consumer, communications, audiovisual).
WCAG briefly (so you understand an audit). Four POUR principles: Perceivable, Operable, Understandable, Robust. Levels: A (minimum), AA (the practical legal/standard target for web), AAA (stricter, rarely mandatory everywhere). “I ran an automated checker” ≠ legal conformity: tools catch part; keyboard, screen-reader, and ideally real-user testing catch the rest — including what an honest accessibility statement needs.
Concrete examples that show up in audits (and complaints). Forms without labels (screen readers cannot tell what a field asks). Insufficient contrast on “aesthetic” buttons. Impossible keyboard-only navigation. Scanned PDFs without text. Visual-only CAPTCHAs. Institutional video without captions when information is essential. For city halls and institutions: petitions, appointments, payments, online registries — exactly where the law matters.
Technical aspects from a software perspective
The law sets “what is required”; software decides “how it is delivered.” EN 301 549 / WCAG 2.1 AA translate into concrete HTML, CSS, JavaScript, UI-component, and testing-pipeline choices. The subsection below is the checklist we use at UNICORE in web development and UI/UX when the goal is conformity — not a one-day audit.
1) Semantic HTML and structure. Use real elements: `header`, `nav`, `main`, `footer`, `button` (not `div` with onClick), `a` for navigation, `h1`–`h6` in a logical hierarchy (do not skip levels for looks). Lists (`ul`/`ol`) for enumerations; tables only for tabular data, with `<th>` and `scope`. A clean DOM drastically reduces the need for ARIA. A skip link (“Skip to content”) at the top of the page helps keyboard navigation.
2) Forms and validation. Every input has `<label for="...">` (or correct wrapping); errors are tied to the field (`aria-describedby` / `aria-invalid`), not colour alone. Messages say what is wrong and how to fix it. Use `autocomplete` where relevant (login, address). Do not block submit on visual-only validation. For long flows (petitions, requests): partial save, clear steps, summary before send — also accessible for users with cognitive difficulties.
3) Keyboard, focus, and modals. Everything actionable must be reachable with Tab/Shift+Tab; visual order = DOM order (or correctly managed). Visible focus (`:focus-visible`) — do not remove it with `outline: none` without a replacement. In modals/drawers: focus trap, Escape closes, focus returns to the trigger on close. Avoid positive `tabindex` (anti-pattern). Custom shortcuts must not clash with screen-reader keys.
4) ARIA — when it helps and when it hurts. Rule: semantic HTML first; ARIA only when native falls short (tablist, complex combobox, live region for async alerts). `aria-label` / `aria-labelledby` on icon-only buttons; `aria-expanded` / `aria-controls` on menus. Do not duplicate roles (`<button role="button">`). Live regions (`aria-live="polite"`) for toasts and search results — without spam. Wrong ARIA is worse than none.
5) Visual, media, and motion. Text/UI contrast per WCAG AA (generally 4.5:1 text, 3:1 large UI). Do not convey information by colour alone. Informative images: useful `alt`; decorative: `alt=""`. Essential video/audio: captions / transcript. Honour `prefers-reduced-motion`. 200% zoom and small-width reflow without content loss (no `overflow: hidden` on critical text). Dark mode / themes: recalculate contrasts — do not blindly copy tokens.
6) SPAs, frameworks, and components. In React/Next/Vue etc.: on route change, move focus to `main` / a heading (otherwise the screen reader “stays” in the old context). Announce async updates. Virtualised lists and infinite scroll must stay keyboard-operable. The design system is the unit of conformity: one accessible `Button` / `Modal` / `Select` saves dozens of screens; one broken one breaks them all. Avoid canvas/WebGL for critical UI without an HTML alternative.
7) Documents, CAPTCHA, authentication. PDFs generated by the system (certificates, decisions, confirmations) need selectable text and tags/structure where possible — not only a scanned image. CAPTCHA: prefer accessible methods (e.g. invisible checks / SMS / alternative question), not visual-only puzzles. Login: clear errors, password-manager friendly, MFA that does not block assistive tech. Session timeout: warning and a way to extend.
8) Testing and “Definition of Done.” Automated: axe-core / Lighthouse a11y in CI, `eslint-plugin-jsx-a11y` (or equivalent), Playwright/Cypress tests on critical flows with keyboard navigation. Manual: WCAG checklist on templates, VoiceOver / NVDA / TalkBack on 1–2 key flows, 200% zoom. Do not mark a UI ticket “Done” without accessibility criteria. Regressions appear on redesigns and third-party plugins — retest after UI-kit upgrades.
Public procurement and vendors. If an institution buys a portal, CMS, or app, accessibility requirements must be in the specifications / contract — with reference to EN 301 549 and verifiable acceptance (not only a “modern site”). A private vendor delivering to the public sector must account for the institution remaining under GEO 112/2018. For operators under Law 232/2022, accessibility is a market requirement, not a marketing option. IT consulting helps map which law applies and what to put in the contract.
How to start a conformity plan (public or private). (1) Clarify legal scope: GEO 112, Law 232, both, or voluntary good practice only. (2) Inventory digital properties (site, app, essential PDFs, terminals). (3) Audit against EN 301 549 / WCAG 2.1 AA — critical pages and flows first. (4) Remediate by priority + acceptance criteria in sprints. (5) Accessibility statement (mandatory in public; useful in private) + feedback channel. (6) Retest and update when you change the template or CMS. Accessibility is a process, not a one-day PDF.
Important note. This article explains the framework in plain language and does not replace legal advice or a formal conformity audit. Official texts (GEO 112/2018, Law 90/2019, Law 232/2022, Directive 2016/2102, Directive 2019/882, EN 301 549, ADR Decision 815/2022) and ADR guidance remain authoritative. If you want an audit of critical pages, an accessibility statement, or a remediation plan aligned with EN 301 549, contact us.