Od 28 czerwca 2025 wszystkie aplikacje internetowe i mobilne dostępne w Unii Europejskiej muszą spełniać określone wymagania dotyczące dostępności cyfrowej. Jest to wynik wdrożenia Europejskiego Aktu o Dostępności (EAA). Przepisy te mają szczególne znaczenie dla właścicieli aplikacji, a przez to również dla frontend developerów.
W poniższym artykule opiszę po krótce czego dotyczą nowe przepisy i czego może spodziewać się programista podczas implementacji rozwiązań w aplikacjach internetowych.
Natomiast o konkretniejszych przykładach użycia i rozwiązaniach wprowadzania dostępności możesz przeczytać -> tutaj.
Czym jest EAA?
European Accessibility Act (EAA) to dyrektywa UE, której celem jest zapewnienie równego dostępu do produktów i usług cyfrowych osobom z niepełnosprawnościami. Obowiązuje m.in. sklepy internetowe, aplikacje mobilne, e-booki, bankowość online, serwisy transportowe.
Od kiedy i z jakim skutkiem?
Nowe przepisy zaczynają obowiązywać od 28 czerwca 2025. Niedostosowanie aplikacji może skutkować karami – m.in. grzywną za brak deklaracji dostępności lub poważniejszymi sankcjami za brak zgodności z wymaganiami.
Co to oznacza dla frontendowca?
Wymagania biznesowe będą musiały uwzględniać dodatkowe wymagania techniczne, które programista będzie zobowiązany zaimplementować. Będą one zgodne z:
- WCAG 2.1 lub 2.2 na poziomie AA
- Normą EN 301 549
- Dostosowanie UI/UX
WCAG 2.1 / 2.2 – poziom AA
WCAG (Web Content Accessibility Guidelines) to globalny standard opracowany przez W3C, który opisuje, jak projektować strony i aplikacje internetowe, aby były dostępne dla jak najszerszego grona użytkowników – w tym osób z niepełnosprawnościami.
- WCAG 2.1 to wersja obowiązująca od czerwca 2018.
- WCAG 2.2 została opublikowana w 2023 i rozszerza 2.1 o nowe kryteria (m.in. przyciski dotykowe, nawigacja przez klawiaturę).
Poziom AA jest wymagany przez EAA – to środkowy poziom rygoru (są jeszcze A – minimalny, i AAA – maksymalny).
Norma EN 301 549
To europejska norma techniczna, która definiuje wymogi dostępności ICT (technologii informacyjno-komunikacyjnej) – w tym aplikacji webowych, desktopowych, mobilnych, terminali i dokumentów elektronicznych. EN 301 549 jest oficjalnym dokumentem, na podstawie którego państwa członkowskie UE wdrażają EAA.
Rozszerza wymagania m.in. na:
- Dokumenty elektroniczne (PDF, DOCX) – muszą być dostępne
- Multimedia – wymagane napisy, audiodeskrypcja lub transkrypcja
Opisuje także testowanie aplikacji i kryteria oceny dostępności.
Dostosowanie UI/UX
Dostępność to nie tylko kod, ale też sposób projektowania interfejsu w taki sposób, żeby w prosty sposób oraz intuicyjnie dało się korzystać z jego funkcji. Poniżej przedstawiam przykłady:
Okiem programisty:
- Unikaj pułapek: tabindex=”-1″ w złych miejscach, niestandardowe selecty bez klawiatury
- Używaj np. Angular CDK A11y do zarządzania fokusem, pułapkami, aria-live
- Dodawaj automatyczne testy dostępności do CI/CD
Pod względem UX/UI:
- Przyciski muszą być odpowiednio duże – ważne w WCAG 2.2
- Tekst i etykiety muszą być jednoznaczne
- W przypadku kolorów: nie polegaj tylko na barwie (uzwględnij, że nie wszyscy poprawnie rozróżniają kolory)
- Formularze: czytelne błędy, grupowanie pól (fieldset/legend), aria-describedby
Deklaracja dostępności
Deklaracja dostępności to publiczny dokument, który informuje użytkowników o tym, na ile dana strona internetowa lub aplikacja spełnia wymagania dostępności cyfrowej. To coś w rodzaju „metki jakości” przyszytych do ubrań – pokazuje, co działa, co jeszcze nie, i jak zgłosić problem.
Taka deklaracja jest najczęściej dostępna pod dedykowanym adresem:
np. https://your-app.com/accessibility
Dodaj link np. w stopce lub menu głównym Twojej aplikacji.
W przypadku aplikacji mobilnych – link do deklaracji powinien znajdować się w opisie w sklepie Google Play / App Store lub w menu aplikacji.
9 przykładowych aspektów, o które warto zadbać
Jest to podstawowa lista rozwiązań, które powinny znaleźć się w kodzie aplikacji:
- Semantyka HTML i aria
- Stosuj poprawne tagi (<header>, <nav>, <button>, <section>)
- Uzupełniaj aria-label, aria-describedby, role
- Dostępność z klawiatury
- Wszystkie akcje muszą być dostępne przez Tab i Enter/Space
- Użyj cdkTrapFocus, cdkMonitorFocus z Angular CDK
- Kontrast i kolory
- Kontrast tekstu: co najmniej 4.5:1 (dla dużego tekstu 3:1)
- Sprawdź z narzędziami: WebAIM Contrast Checker
- Widoczny focus
- Styl focusa (:focus-visible) powinien być wyraźny – nie usuwaj go!
- Angular Material domyślnie wspiera ten aspekt
- Teksty alternatywne
- Wszystkie obrazy muszą mieć alt, ikony SVG z aria-hidden=”true” lub opis alternatywny
- Responsywność i dostępność gestów
- Nie polegaj wyłącznie na drag & drop
- Dodaj zamienniki dla dotykowych interakcji (np. przyciski „lewo/prawo”)
- Obsługa zmian w aplikacji
- Po zmianie treści zadbaj o:
- Fokus w nowym miejscu
- Powiadomienie użytkownika (aria-live, cdkAriaLive)
- Walidacja formularzy
- Komunikaty o błędach muszą być zrozumiałe, związane z konkretnym polem (aria-describedby)
- Formularze muszą działać z klawiatury i z czytnikami ekranu
- Automatyczne testy dostępności
- Dodaj do CI: jest-axe, axe-core, pa11y, lighthouse-ci
Przykładowe narzędzia
- Angular CDK A11y: zarządzanie fokusem, aria-live, interakcje
- Lighthouse: analiza dostępności w przeglądarce
- axe-core / jest-axe: testy w CI/CD
- Angular Material: gotowe komponenty zgodne z WCAG
Podsumowanie
Nowe regulacje to nie tylko wymóg prawny, ale również realna okazja do poprawy jakości produktu. Lepsza dostępność to lepsze doświadczenia użytkownika (UX), większy zasięg, lepsze SEO i mniej problemów dla odbiorców. Zważywszy na okoliczności, warto podjąć ten temat wcześniej, co wyjdzie na dobre obu stronom.