L’accessibilité web, c’est qu’un site ou une app puisse aussi être utilisé par des personnes en situation de handicap (vue, ouïe, moteur, cognitif) — et, en pratique, par quiconque sur mobile au soleil, une main occupée ou mauvaise connexion. WCAG est le référentiel technique du W3C. En Europe et en Roumanie, ce n’est pas seulement une « bonne pratique » : c’est derrière des obligations légales. Chez UNICORE, cela entre dans UI/UX et les sites / apps web — exigence dès le début.
La carte juridique, en bref (UE → RO). Deux « voies » européennes : (1) Directive (UE) 2016/2102 — sites et apps mobiles du secteur public (WAD). (2) Directive (UE) 2019/882 — European Accessibility Act (EAA), pour certains produits et services du marché intérieur (dont beaucoup de services numériques grand public). La Roumanie a transposé : OUG n° 112/2018 (approuvée par la loi n° 90/2019) pour le public ; loi n° 232/2022 pour l’EAA (application effective au 28 juin 2025).
La norme technique commune : EN 301 549 (et le lien WCAG). Pour les marchés publics et la conformité, la référence harmonisée européenne pour les TIC accessibles est EN 301 549. En pratique, pour le web, elle intègre WCAG 2.1 niveau AA. Quand on dit « il faut WCAG AA », en langage juridique RO/UE cela signifie en général : s’aligner sur EN 301 549 pour les composantes web/mobile couvertes.
Secteur public : OUG 112/2018 + loi 90/2019. L’ordonnance fixe les exigences pour sites et apps mobiles des organismes du secteur public — administration centrale et locale et autres entités couvertes. Objectif : que les citoyens (y compris en situation de handicap) puissent percevoir, naviguer et utiliser les services numériques publics. L’ADR assure le suivi / contrôle (HG n° 89/2020 ; décision ADR n° 815/2022).
Ce qu’une institution publique doit typiquement faire. (1) Rendre site / app accessibles (en pratique : EN 301 549 / WCAG 2.1 AA). (2) Publier une déclaration d’accessibilité — statut, ce qui ne l’est pas encore, pourquoi, alternatives. (3) Mécanisme de feedback. (4) Si « charge disproportionnée », évaluation motivée publiée avec la déclaration — pas une excuse générique. Ignorance, « ce n’était pas prioritaire » ou CMS inaccessible ne sont pas des motifs légitimes typiques.
Charge disproportionnée — sens (et limites). L’OUG permet, cas justifiés, de ne pas rendre certains contenus pleinement accessibles si les mesures imposeraient une charge excessive ou mettraient en péril la mission — en pesant aussi le préjudice pour les citoyens. Ce n’est pas « on abandonne ». C’est une exception documentée, avec alternatives si possible. En achats : un CMS inaccessible n’efface pas l’obligation — le choix du fournisseur compte dès le départ.
Secteur privé : directive 2019/882 (EAA) + loi 232/2022. Depuis le 28 juin 2025, la loi 232/2022 applique des exigences à une gamme de produits et services — dont, dans l’esprit de l’EAA, e-commerce, banque grand public, communications électroniques, éléments de transport de passagers, e-books / logiciels de lecture, et interfaces numériques associées. Toute entreprise n’est pas « automatiquement » couverte pour tout son web — ce qui compte, c’est le champ d’application. Quand c’est le cas, les interfaces doivent permettre perception, opération et compréhension à égalité, compatibles aides techniques.
Exceptions et transitions (EAA / loi 232 — simplement). La loi prévoit seuils et périodes de transition (microentreprises selon critères ; contrats antérieurs au 28.06.2025 pouvant courir jusqu’à échéance dans une limite ; terminaux en libre-service avec horizons longs ; médias / documents antérieurs parfois exceptés). Ne traitez pas cela comme « ça ne nous concerne pas » : vérifiez le champ avec un conseil juridique — puis alignez le produit. Sanctions administratives prévues ; autorités selon le domaine.
WCAG en bref (pour comprendre un audit). Quatre principes POUR : Perceivable, Operable, Understandable, Robust. Niveaux : A, AA (cible pratique légale/norme pour le web), AAA. « J’ai lancé un checker » ≠ conformité légale : outils + clavier + lecteur d’écran +, idéalement, utilisateurs réels.
Exemples concrets d’audits (et plaintes). Formulaires sans libellés. Contraste insuffisant. Navigation clavier impossible. PDF scannés sans texte. CAPTCHA uniquement visuel. Vidéo institutionnelle sans sous-titres si l’info est essentielle. Pour mairies : pétitions, rendez-vous, paiements, registres en ligne.
Aspects techniques du point de vue logiciel
La loi fixe le « quoi » ; le logiciel décide le « comment ». EN 301 549 / WCAG 2.1 AA se traduisent en choix concrets HTML, CSS, JavaScript, composants UI et pipeline de tests. Le sous-chapitre ci-dessous est la checklist UNICORE en développement web et UI/UX quand la cible est la conformité.
1) HTML sémantique et structure. Utilisez de vrais éléments : `header`, `nav`, `main`, `footer`, `button` (pas un `div` avec onClick), `a` pour la navigation, titres `h1`–`h6` en hiérarchie logique. Listes (`ul`/`ol`) ; tableaux seulement pour données tabulaires, avec `<th>` et `scope`. Un DOM propre réduit fortement le besoin d’ARIA. Skip link (« Aller au contenu ») en tête de page.
2) Formulaires et validation. Chaque champ a un `<label for="...">` ; les erreurs sont liées au champ (`aria-describedby` / `aria-invalid`), pas seulement une couleur. Messages explicites. `autocomplete` quand c’est pertinent. Pas de blocage sur validation uniquement visuelle. Flux longs : sauvegarde partielle, étapes claires, récap avant envoi.
3) Clavier, focus et modales. Tout ce qui est actionnable doit l’être au Tab/Shift+Tab ; ordre visuel = ordre DOM. Focus visible (`:focus-visible`) — pas d’`outline: none` sans remplacement. Modales : focus trap, Escape ferme, retour du focus sur le déclencheur. Évitez `tabindex` positif. Raccourcis custom sans conflit avec les lecteurs d’écran.
4) ARIA — quand ça aide et quand ça nuit. Règle : HTML sémantique d’abord ; ARIA seulement si le natif ne suffit pas. `aria-label` sur boutons icône ; `aria-expanded` / `aria-controls` sur menus. Pas de rôles dupliqués. Live regions (`aria-live="polite"`) pour toasts et résultats — sans spam. Un mauvais ARIA est pire que rien.
5) Visuel, média et mouvement. Contraste texte/UI WCAG AA (en général 4.5:1 texte, 3:1 UI large). Pas d’info par la seule couleur. Images informatives : `alt` utile ; décoratives : `alt=""`. Vidéo/audio essentiels : sous-titres / transcript. Respecter `prefers-reduced-motion`. Zoom 200 % et reflow sans perte. Dark mode : recalculer les contrastes.
6) SPA, frameworks et composants. React/Next/Vue : au changement de route, déplacer le focus vers `main` / un titre. Annoncer les updates async. Listes virtualisées et infinite scroll utilisables au clavier. Le design system est l’unité de conformité : un `Button` / `Modal` / `Select` accessible sauve des dizaines d’écrans. Évitez canvas/WebGL pour l’UI critique sans alternative HTML.
7) Documents, CAPTCHA, authentification. PDF générés : texte sélectionnable et structure/tags si possible — pas seulement une image scannée. CAPTCHA : méthodes accessibles (vérif. invisible / SMS / question alternative). Login : erreurs claires, gestionnaires de mots de passe, MFA compatible aides techniques. Timeout de session : avertissement + prolongation.
8) Tests et « Definition of Done ». Auto : axe-core / Lighthouse a11y en CI, `eslint-plugin-jsx-a11y`, Playwright/Cypress sur flux critiques au clavier. Manuel : checklist WCAG, VoiceOver / NVDA / TalkBack, zoom 200 %. Pas de ticket UI « Done » sans critères a11y. Les régressions arrivent aux redesigns et plugins — retester après upgrade du UI kit.
Marchés publics et fournisseurs. Si l’institution achète un portail, un CMS ou une app, les exigences doivent être au cahier des charges / contrat — avec EN 301 549 et acceptation vérifiable. Le fournisseur privé doit tenir compte de l’OUG 112/2018 côté institution. Pour les opérateurs sous la loi 232/2022, l’accessibilité est une exigence de marché. Le conseil IT aide à cartographier la loi applicable et le contrat.
Comment démarrer un plan de conformité. (1) Clarifier le champ légal : OUG 112, loi 232, les deux, ou bonne pratique seule. (2) Inventorier les actifs numériques. (3) Auditer EN 301 549 / WCAG 2.1 AA — flux critiques d’abord. (4) Corriger par priorité. (5) Déclaration + feedback. (6) Retester après changement de template/CMS. L’accessibilité est un processus.
Note importante. Cet article explique le cadre en langage simple et ne remplace pas un conseil juridique ni un audit formel. Les textes officiels (OUG 112/2018, lois 90/2019 et 232/2022, directives 2016/2102 et 2019/882, EN 301 549, décision ADR 815/2022) font autorité. Pour un audit, une déclaration ou un plan de correction aligné EN 301 549, contactez-nous.