React, Angular i Vue nie są z natury ani dostępne, ani niedostępne. Każdy z tych frameworków może posłużyć do stworzenia produktu zgodnego z WCAG — i w każdym można zbudować interfejs, którego nie da się obsłużyć klawiaturą.
Różnica tkwi przede wszystkim w narzędziach, sposobie budowania komponentów i odpowiedzialności zespołu. React oferuje największy wybór rozwiązań. Angular zapewnia mocne oficjalne wsparcie. Vue stawia na prosty HTML w szablonach i coraz dojrzalsze biblioteki headless.
Poniżej znajdziesz krótkie porównanie accessibility dla React, Angular i Vue, praktyczne wskazówki oraz biblioteki, które warto brać pod uwagę.
Najpierw ważna zasada: framework nie zastępuje WCAG
Framework odpowiada za renderowanie i aktualizowanie interfejsu. Nie podejmie za zespół decyzji, czy:
- przycisk ma właściwą nazwę,
- formularz zawiera zrozumiałe instrukcje,
- kolejność nagłówków jest logiczna,
- kontrast po zastosowaniu motywu jest wystarczający,
- fokus trafia we właściwe miejsce po zmianie widoku,
- pełny proces da się ukończyć czytnikiem ekranu.
Niezależnie od technologii zaczynaj od natywnego HTML. button, a, input, select, dialog, header, nav i main mają semantykę oraz zachowania, których nie trzeba odtwarzać od zera.
ARIA uzupełnia HTML, ale go nie naprawia. div z role="button" nadal wymaga między innymi obsługi klawiatury, fokusu i stanów. Jeżeli można użyć prawdziwego button, zwykle jest to lepszy wybór.
React accessibility — duża swoboda i duża odpowiedzialność
React pozwala przekazywać atrybuty aria-* tak samo jak w HTML. Oficjalna dokumentacja wspólnych komponentów DOM w React opisuje również atrybuty wpływające na drzewo dostępności.
Sam React nie dostarcza jednak kompletnego zestawu dostępnych widgetów. To zespół wybiera:
- strukturę DOM,
- sposób zarządzania fokusem,
- bibliotekę komponentów,
- zachowanie modali, comboboxów i menu,
- komunikowanie dynamicznych zmian.
Na co uważać w React?
Najczęstsze problemy to:
- klikalne
divzamiast przycisków i linków, - komponenty zwracające inną semantykę niż sugeruje ich nazwa,
- utrata fokusu po warunkowym renderowaniu,
- modal bez przywracania fokusu do elementu otwierającego,
- zmiana trasy bez ustawienia tytułu strony i zarządzania fokusem,
- błędy formularza widoczne na ekranie, ale nieogłaszane czytnikowi.
Hook useEffect i refy pozwalają sterować fokusem, ale należy robić to celowo. Nie przenoś fokusu po każdej aktualizacji. Użytkownik powinien zachować kontrolę i rozumieć zmianę kontekstu.
Polecane biblioteki accessibility dla React
React Aria Components
React Aria to rozwijany przez Adobe zestaw nieostylowanych komponentów i hooków. Zapewnia zachowania, obsługę klawiatury, focus, interakcje dotykowe i internacjonalizację.
Warto wybrać React Aria, gdy:
- budujesz własny design system,
- potrzebujesz zaawansowanych pól daty, wyboru lub comboboxów,
- produkt działa w wielu językach,
- zespół chce kontrolować wygląd bez pisania całej logiki interakcji.
Zacznij od React Aria Components. Do hooków niższego poziomu schodź dopiero wtedy, gdy potrzebujesz większej kontroli.
Radix Primitives
Radix Primitives dostarcza nieostylowane prymitywy React. Biblioteka implementuje wzorce WAI-ARIA, obsługę klawiatury i zarządzanie fokusem dla komponentów takich jak dialog, menu, zakładki czy tooltip.
Radix jest dobrym wyborem, gdy:
- potrzebujesz elastycznej bazy pod własny wygląd,
- chcesz wdrażać komponenty stopniowo,
- zależy Ci na łatwym składaniu małych prymitywów,
- zespół rozumie, że nadal odpowiada za etykiety, treść i kontrast.
React Spectrum
Jeśli nie potrzebujesz całkowicie własnego stylu, React Spectrum oferuje gotowy system komponentów Adobe z obsługą klawiatury, czytników ekranu, trybu wysokiego kontrastu, różnych metod wejścia i internacjonalizacji.
To rozwiązanie bardziej opiniotwórcze wizualnie niż React Aria lub Radix, ale pozwala szybciej zbudować spójny interfejs.
Angular accessibility — najmocniejsze narzędzia oficjalne
Angular wyróżnia się tym, że jego oficjalny ekosystem zawiera narzędzia zarówno do budowania własnych komponentów, jak i gotowy system UI.
W szablonach Angular trzeba pamiętać o property bindingu dla dynamicznych atrybutów ARIA, na przykład [attr.aria-expanded]. Oficjalny przewodnik Accessibility in Angular omawia również ponowne wykorzystywanie natywnych elementów i narzędzia CDK.
Na co uważać w Angular?
Typowe problemy obejmują:
- używanie komponentu hosta zamiast natywnej kontrolki wewnątrz,
- nieaktualne dynamiczne wartości
aria-*, - błędne zarządzanie fokusem po otwarciu overlay,
- komunikaty zmieniane w szablonie, ale nieogłaszane technologii asystującej,
- rozbudowane formularze reaktywne bez właściwego powiązania błędów z polami,
- route transition bez tytułu i logicznego miejsca rozpoczęcia widoku.
Polecane biblioteki accessibility dla Angular
Angular Aria
Angular Aria to oficjalny zestaw nieostylowanych dyrektyw implementujących popularne wzorce WAI-ARIA. Obsługuje między innymi klawiaturę, role i stany ARIA, fokus oraz wsparcie czytników ekranu.
To najlepszy kandydat, gdy:
- tworzysz własny design system,
- wygląd musi dokładnie odpowiadać marce,
- potrzebujesz dostępnych menu, tabs, accordion, listbox lub combobox,
- nie chcesz wiązać zachowania komponentu z konkretnym motywem.
Angular Aria zapewnia zachowanie, ale HTML, CSS i logika biznesowa pozostają po stronie zespołu.
Angular CDK a11y
Pakiet @angular/cdk/a11y zawiera narzędzia niższego poziomu, między innymi:
LiveAnnouncerdo ogłaszania zmian,cdkTrapFocusdo kontrolowania fokusu w modalach,- mechanizmy monitorowania pochodzenia fokusu,
- narzędzia do obsługi klawiatury w złożonych kontrolkach.
Angular CDK a11y sprawdza się, gdy budujesz komponenty samodzielnie albo uzupełniasz zachowanie istniejącego systemu.
Angular Material
Angular Material jest utrzymywany przez zespół Angular i dostarcza gotowe, ostylowane komponenty projektowane z uwzględnieniem dostępności.
Wybierz go, jeśli:
- ważna jest szybkość wdrożenia,
- akceptujesz Material Design lub jego modyfikację,
- potrzebujesz spójnego, szerokiego zestawu komponentów,
- nie chcesz samodzielnie projektować całego systemu interakcji.
Vue accessibility — czytelne szablony i kontrola nad DOM
Vue sprzyja pracy blisko HTML. Szablony są czytelne, a wiązanie dynamicznych atrybutów, na przykład :aria-expanded, jest proste. Nie oznacza to jednak, że dostępność powstaje automatycznie.
Oficjalny przewodnik Accessibility in Vue omawia skip link, strukturę nagłówków, landmarki, formularze i ustawianie fokusu po zmianie trasy.
Na co uważać w Vue?
Najczęstsze ryzyka to:
- komponent opakowujący kontrolkę i ukrywający jej prawdziwą semantykę,
@clickna elemencie, którego nie można aktywować klawiaturą,- brak zarządzania fokusem po zmianie route,
- używanie
v-if, które usuwa aktualnie sfokusowany element, - teleportowane modale bez poprawnej kolejności fokusu,
- komponenty formularzy, które nie przekazują
id, błędów i opisów do natywnego pola.
Po zmianie trasy użytkownik czytnika ekranu powinien otrzymać informację o nowym widoku. Najczęściej wymaga to aktualizacji tytułu dokumentu oraz przemyślanego przeniesienia fokusu do początku nowej treści.
Polecane biblioteki accessibility dla Vue
Reka UI
Reka UI, wcześniej znane jako Radix Vue, to zestaw nieostylowanych prymitywów dla Vue. Biblioteka deklaruje zgodność ze wzorcami WAI-ARIA i obsługuje role, stany, nawigację klawiaturą oraz zarządzanie fokusem.
Reka UI warto rozważyć, gdy:
- tworzysz własny design system,
- potrzebujesz elastycznych komponentów headless,
- chcesz zachować kontrolę nad CSS,
- budujesz złożone menu, dialogi, zakładki lub pola wyboru.
Tak jak w przypadku Radix, gotowy komponent nadal wymaga dostępnej nazwy, prawidłowej treści i testów po ostylowaniu.
Gotowe biblioteki komponentów Vue
Biblioteki oferujące gotowy wygląd mogą przyspieszyć pracę, ale ich poziom dostępności bywa różny między komponentami i wersjami. Przed wyborem:
- znajdź osobną dokumentację accessibility,
- sprawdź tabelę obsługi klawiatury,
- przetestuj dialog, select, menu i formularz,
- sprawdź otwarte błędy dotyczące a11y,
- wykonaj test z NVDA lub VoiceOver.
Nie wybieraj biblioteki tylko na podstawie zdania „WCAG ready” na stronie głównej.
React vs Angular vs Vue — najważniejsze różnice
| Obszar | React | Angular | Vue |
|---|---|---|---|
| Podejście | Elastyczna biblioteka UI | Kompletny framework | Progresywny framework |
| Oficjalne komponenty a11y | Brak jednego oficjalnego zestawu | Angular Aria, CDK i Material | Głównie dokumentacja dobrych praktyk |
| Ekosystem headless | Bardzo szeroki | Oficjalny Angular Aria | Reka UI i rozwiązania społeczności |
| Kontrola nad DOM | Duża, zależna od komponentów | Duża, ale z warstwą dyrektyw i komponentów | Bezpośrednia i czytelna w szablonach |
| Typowe ryzyko | Niespójność między bibliotekami | Złożoność własnych komponentów i overlay | Mniejszy wybór dojrzałych prymitywów |
| Dobry start | React Aria lub Radix | Angular Aria albo Material | Reka UI lub natywny HTML |
Który framework wybrać pod accessibility?
- React — gdy potrzebujesz dużego ekosystemu, elastyczności i masz kompetencje do oceny bibliotek.
- Angular — gdy cenisz spójny, oficjalny zestaw narzędzi i budujesz większy system aplikacyjny.
- Vue — gdy zależy Ci na czytelnych szablonach, stopniowym wdrożeniu i prostocie pracy blisko HTML.
Żaden z nich nie daje automatycznej przewagi w zgodności z WCAG. Najlepszy będzie framework, który zespół zna na tyle dobrze, aby kontrolować wynikowy DOM, fokus i zachowanie aplikacji.
Biblioteki do testowania dostępności niezależnie od frameworka
Komponenty to tylko część pracy. Do procesu warto włączyć:
- axe-core — silnik automatycznych testów reguł dostępności,
- eslint-plugin-jsx-a11y — statyczne reguły dla JSX w React,
- eslint-plugin-vuejs-accessibility — reguły dostępności dla szablonów Vue,
- Accessibility Insights — automatyczna kontrola i prowadzona ocena ręczna,
- Playwright z
@axe-core/playwright— testy dostępności w rzeczywistych ścieżkach aplikacji.
Dla Angular warto również utrzymywać włączone kontrole szablonów i testować wynikowy interfejs przez axe-core. Linter wykryje część błędów w kodzie, ale nie sprawdzi logicznej kolejności fokusu ani jakości etykiety.
Minimalny proces dla każdego zespołu
Niezależnie od frameworka:
- Zacznij od semantycznego HTML.
- Dla złożonych widgetów wybierz bibliotekę opartą na wzorcach WAI-ARIA.
- Dodaj reguły accessibility do lintera.
- Uruchamiaj axe w testach komponentowych i end-to-end.
- Przetestuj klawiaturą wszystkie krytyczne procesy.
- Sprawdź aplikację z NVDA, VoiceOver lub TalkBack.
- Testuj po każdej zmianie motywu, routingu i biblioteki UI.
Biblioteka zmniejsza ryzyko, ale nie przenosi odpowiedzialności. Jeżeli zmienisz element renderowany przez prymityw, usuniesz etykietę albo nadpiszesz focus style, dostępny komponent może przestać być dostępny.
Podsumowanie
Accessibility w React, Angular i Vue opiera się na tych samych fundamentach: semantycznym HTML, poprawnej obsłudze klawiatury, zarządzaniu fokusem, zrozumiałych formularzach i testach z technologiami asystującymi.
Różne są drogi dojścia:
- React daje największy wybór — szczególnie React Aria i Radix Primitives,
- Angular zapewnia najmocniejszy oficjalny zestaw przez Angular Aria, CDK i Material,
- Vue oferuje czytelne szablony, a Reka UI jest mocną bazą dla własnych komponentów.
Wybieraj bibliotekę na podstawie dokumentacji wzorców, obsługi klawiatury, aktywnego utrzymania i możliwości testowania. Nigdy wyłącznie na podstawie deklaracji marketingowej.