← Wszystkie tematy W 45% ogłoszeń · 21 z 47 ogłoszeń frontend React

Dostępność interfejsów

Plac zabaw dla każdego dziecka

Dostępność jest w 21 z 47 ogłoszeń, często wprost: WCAG, accessibility standards. Pytania są praktyczne: klawiatura, czytnik ekranu, formularze.

Przerobione Opanowane 0 z 5 pytań

Ucz się z Claude Wytłumacz od zera Próbna rozmowa Zadanie praktyczne Ściąga na 1 stronę

Co piszą w ogłoszeniach

„Ensure responsive design, performance optimization, and accessibility standards.”
emagine Polska · Frontend React Developer
„Znajomość standardów dostępności cyfrowej, w tym WCAG.”
Upvanta sp. z o.o. · Front-End Engineer (React / TypeScript / AWS)
„praktyczna znajomość WCAG – minimum 3 lata doświadczenia lub 5 projektów”
Randlab · React Developer – (K/M/N)

Scena · klawiatura i czytnik ekranu

Nie każde dziecko bawi się myszką. Jedno porusza się tylko klawiaturą, drugie nie widzi i słucha, co mówi czytnik ekranu. Ten sam sklepik zbudowano dwa razy: raz z samych div-ów z onClick, raz z prawdziwych przycisków. Użyj klawiszy pod spodem i posłuchaj czytnika.

div + onClick button + aria

Naciskaj Tab i spróbuj kupić lizaka.

Porównajmy

	div + onClick	Semantyczny HTML + ARIA
Klawiatura	Tab go omija.Brak fokusa i obsługi Enter/Spacji.	Działa od razu.`<button>` ma fokus, Enter i Spację za darmo.
Co słyszy niewidome dziecko?	„Menu” i nic więcej. Albo nic.Brak roli i stanu.	„Menu, przycisk, zwinięty”.Rola, nazwa, stan: `aria-expanded`, `aria-controls`.
Zamykanie	Esc nic nie robi, fokus ginie.Użytkownik klawiatury utyka.	Esc zamyka i wraca na przycisk.Zarządzanie fokusem: powrót do elementu, który otworzył menu lub modal.
Kiedy ARIA?	Dokleja się `role` do wszystkiego.Zła ARIA szkodzi bardziej niż żadna.	Gdy HTML nie ma gotowego elementu.Pierwsza zasada ARIA: jeśli jest natywny element, użyj go.
Jak sprawdzić?	Myszką „działa”.	Klawiaturą, czytnikiem i automatem.Odłóż mysz, VoiceOver/NVDA, axe / Lighthouse, kontrast, zoom 200%.

Furtka dla każdego

Wszystko, co da się kliknąć, musi też dać się osiągnąć klawiszem Tab.

Nazwa, rola, stan

Czytnik musi powiedzieć, co to jest, jak się nazywa i czy jest otwarte.

Wróć tam, skąd przyszedłeś

Zamykasz menu albo modal? Fokus wraca na przycisk, który go otworzył.

Sprawdź się

Pytania z rozmów

Najpierw odpowiedz na głos, dopiero potem rozwiń odpowiedź.

Jak sprawić, żeby własny dropdown lub modal był dostępny z klawiatury? (focus trap, Escape, role)

Moja odpowiedź

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż odpowiedź

Dla przedszkolaka: Gdy otwierasz okienko, klawiatura wchodzi do środka i nie może z niego uciec, dopóki nie zamkniesz go klawiszem Esc. Wtedy wraca dokładnie tam, skąd przyszła.

Na rozmowę: Modal: natywny <dialog> z showModal() albo role="dialog" + aria-modal="true" i aria-labelledby, fokus na pierwszy sensowny element po otwarciu, focus trap (Tab krąży w środku), Esc zamyka, po zamknięciu fokus wraca na przycisk, który otworzył, a tło jest inert. Dropdown/menu: przycisk z aria-expanded i aria-controls, strzałki między opcjami, Enter wybiera, Esc zamyka i wraca na przycisk. W praktyce biorę Radix lub React Aria, bo mają to dopracowane.

Umiem?

Zapytaj Claude Rozwiń Przepytaj mnie Pytania pogłębiające

Kiedy używać ARIA, a kiedy wystarczy semantyczny HTML?

Moja odpowiedź

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż odpowiedź

Dla przedszkolaka: ARIA to naklejka z napisem dla czytnika. Lepiej mieć prawdziwy przycisk niż pudełko z naklejką „jestem przyciskiem”.

Na rozmowę: Pierwsza zasada ARIA: jeśli istnieje natywny element z potrzebną semantyką i zachowaniem (button, a, input, select, dialog, details), użyj go. ARIA dodaje tylko informacje dla technologii asystujących, nie dodaje zachowania (fokus, klawiatura). Używam jej, gdy HTML nie ma gotowca (tabs, combobox, tree), do stanów (aria-expanded, aria-selected, aria-invalid), relacji (aria-describedby, aria-controls) i komunikatów (aria-live). Zła ARIA jest gorsza niż jej brak.

Umiem?

Zapytaj Claude Rozwiń Przepytaj mnie Pytania pogłębiające
Jak czytnik ekranu ma się dowiedzieć o zmianie treści? (aria-live)

Moja odpowiedź

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż odpowiedź

Dla przedszkolaka: Gdy coś zmieni się w kącie pokoju, ktoś musi to powiedzieć na głos, bo niewidome dziecko patrzy tam, gdzie jest jego ręka.

Na rozmowę: Region aria-live="polite" (lub role="status") ogłasza zmiany po skończeniu bieżącej wypowiedzi, np. „Dodano do koszyka”, liczba wyników. aria-live="assertive" (role="alert") przerywa i służy tylko do pilnych błędów. Region musi istnieć w DOM przed zmianą treści, a zmieniam tylko jego zawartość. Alternatywnie przenoszę fokus, np. na nagłówek nowej strony po nawigacji w SPA albo na podsumowanie błędów formularza.

Umiem?

Zapytaj Claude Rozwiń Przepytaj mnie Pytania pogłębiające
Jak dostępnie pokazywać błędy walidacji w formularzu?

Moja odpowiedź

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż odpowiedź

Dla przedszkolaka: Gdy dziecko pomyli się w okienku, mówisz mu przy tym okienku, co jest nie tak, i nie tylko kolorem, bo nie każdy widzi kolory.

Na rozmowę: Każde pole ma widoczny <label>. Błąd jest tekstem obok pola, powiązanym przez aria-describedby, a pole dostaje aria-invalid="true". Nie sygnalizuję błędu samym kolorem (ikona plus tekst). Komunikat mówi, jak naprawić („Wpisz kod w formacie 00-000”). Po wysłaniu z błędami przenoszę fokus na pierwsze błędne pole albo podsumowanie z linkami do pól. Wymagane pola: required / aria-required. Nie blokuję przycisku wyślij bez wyjaśnienia, dlaczego.

Umiem?

Zapytaj Claude Rozwiń Przepytaj mnie Pytania pogłębiające
Jak testujesz dostępność? (axe, Lighthouse, ręcznie z klawiaturą i czytnikiem)

Moja odpowiedź

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż odpowiedź

Dla przedszkolaka: Odkładasz myszkę, zamykasz oczy, włączasz czytnik i próbujesz kupić lizaka.

Na rozmowę: Automat łapie około 30–40% problemów: axe DevTools, Lighthouse, eslint-plugin-jsx-a11y, jest-axe lub @axe-core/playwright w CI. Resztę sprawdzam ręcznie: tylko klawiatura (kolejność Tab, widoczny fokus, brak pułapek), czytnik ekranu (VoiceOver, NVDA) na kluczowych ścieżkach, zoom 200% i reflow na 320 px, kontrast, prefers-reduced-motion. Do tego testy RTL po rolach i nazwach, które przy okazji pilnują semantyki.

Umiem?

Zapytaj Claude Rozwiń Przepytaj mnie Pytania pogłębiające

Poziom wyżej

Wersja dla seniora

Tak wyglądają pytania na seniora i leada: nie ma jednej dobrej odpowiedzi, liczy się to, jak ważysz kompromisy i czy mówisz o skali, ryzyku i ludziach.

Przypadek 1

Audyt WCAG przed European Accessibility Act

Sklep internetowy z 6-letnim kodem musi spełniać wymagania European Accessibility Act. Zewnętrzny audyt znalazł 340 problemów, od braków alt po niedostępny checkout. Zespół ma 4 frontendowców i nie może zatrzymać prac nad funkcjami. Masz przygotować plan.

Zanim rozwiniesz: powiedz na głos, jak byś to rozwiązał, i nazwij co najmniej jeden kompromis.

Moje rozwiązanie

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż, czego szuka rekruter, i modelową odpowiedź

Co sprawdza rekruter

Czy priorytetyzujesz według wpływu na użytkownika i ryzyka prawnego
Czy szukasz przyczyn systemowych zamiast łatać 340 miejsc osobno
Czy planujesz, żeby nowe problemy nie powstawały
Czy angażujesz projektantów i produkt

Odpowiedź seniora

Grupuję zgłoszenia według przyczyny, a nie miejsca. Zwykle 340 problemów to kilkanaście przyczyn: komponent Select bez obsługi klawiatury, ikonowe przyciski bez nazw, zły kontrast w tokenach kolorów, modal bez zarządzania fokusem. Naprawa jednego komponentu w bibliotece zamyka dziesiątki zgłoszeń.

Priorytet mają ścieżki krytyczne: wyszukiwanie, karta produktu, koszyk, checkout, logowanie, formularz kontaktu. Te testuję ręcznie klawiaturą i czytnikiem (NVDA, VoiceOver) i naprawiam najpierw. Potem komponenty współdzielone, na końcu treści i rzadkie ekrany.

Żeby nie wracało: axe w testach komponentów i Playwright na krytycznych ścieżkach w CI, eslint-plugin-jsx-a11y, kontrast sprawdzany na poziomie tokenów, checklista dostępności w definicji ukończenia i w projektach w Figmie. Przygotowujemy też deklarację dostępności i kanał zgłaszania problemów. Postęp raportuję jako liczbę zamkniętych przyczyn i stan ścieżek krytycznych, a nie procent z Lighthouse.

Typowe wpadki

Naprawianie zgłoszeń po kolei z listy audytu
Uznanie wyniku 100 w Lighthouse za zgodność z WCAG
Dodanie nakładki typu „accessibility widget” zamiast naprawy kodu
Pominięcie projektantów, przez co nowe ekrany mają te same błędy

Dopytają o

Jak przekonasz produkt, żeby oddał na to 30% czasu zespołu?
Jak sprawdzisz dostępność treści dodawanych przez redakcję w CMS?
Co jest minimalnym poziomem na koniec pierwszego kwartału?

Zapytaj Claude Rozwiń case Zagraj interviewera

Przypadek 2

Dostępny combobox i data grid w design systemie

Design system ma dostać komponent wyszukiwania z podpowiedziami (combobox) oraz tabelę danych z sortowaniem, zaznaczaniem wierszy i edycją komórek. Używa ich 6 zespołów. Projektant pokazał makiety, a termin jest za 6 tygodni.

Zanim rozwiniesz: powiedz na głos, jak byś to rozwiązał, i nazwij co najmniej jeden kompromis.

Moje rozwiązanie

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż, czego szuka rekruter, i modelową odpowiedź

Co sprawdza rekruter

Czy znasz wzorce ARIA APG dla comboboxa i grida
Czy wiesz, kiedy budować samemu, a kiedy użyć gotowego rozwiązania
Czy myślisz o testowaniu z prawdziwymi czytnikami

Odpowiedź seniora

Oba komponenty należą do najtrudniejszych pod względem dostępności, więc nie zaczynam od zera. Combobox opieram na sprawdzonej bazie (React Aria useComboBox, Radix lub Downshift), która daje role combobox i listbox, aria-activedescendant, obsługę strzałek, Escape i ogłaszanie liczby wyników. Na nas zostaje wygląd, async ładowanie z debounce i stan pusty z komunikatem.

Dla tabeli najpierw pytam, czy naprawdę potrzebny jest grid z nawigacją strzałkami po komórkach. Jeśli tabela tylko wyświetla dane z sortowaniem, zostaje semantyczna table z aria-sort i przyciskami w nagłówkach, co jest prostsze i lepiej działa z czytnikami. Edycja komórek i nawigacja jak w arkuszu uzasadniają role grid z roving tabindex, trybem edycji wchodzonym przez Enter i wychodzonym przez Escape. Tu też biorę bazę (React Aria useTable lub AG Grid z dostępnością) zamiast pisać od zera.

Testuję klawiaturą i w NVDA z Firefoxem oraz VoiceOver z Safari, bo czytniki różnie interpretują te same atrybuty. Dokumentacja w Storybooku zawiera sekcję klawiszy i ogłoszeń, a testy RTL sprawdzają role i nazwy.

Typowe wpadki

Pisanie comboboxa od zera na div-ach w 6 tygodni
Robienie z każdej tabeli grida ze strzałkami
Testowanie tylko axe, bez czytnika ekranu

Dopytają o

Jak ogłosisz czytnikowi, że załadowało się 12 wyników?
Co zrobisz z wirtualizacją tabeli 10 000 wierszy a dostępnością?
Jak udokumentujesz zachowanie klawiatury dla zespołów?

Zapytaj Claude Rozwiń case Zagraj interviewera

Przypadek 3

Regresje dostępności wracają po każdym wydaniu

Pół roku temu firma zapłaciła za naprawę dostępności. Kolejny audyt pokazuje, że połowa problemów wróciła: nowe ikonowe przyciski bez nazw, modale bez fokusu, formularze z błędami tylko na czerwono. Zespoły mówią, że nie wiedziały.

Zanim rozwiniesz: powiedz na głos, jak byś to rozwiązał, i nazwij co najmniej jeden kompromis.

Moje rozwiązanie

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż, czego szuka rekruter, i modelową odpowiedź

Co sprawdza rekruter

Czy szukasz przyczyny procesowej, a nie winnych
Czy wiesz, co da się zautomatyzować, a co nie
Czy umiesz wbudować dostępność w codzienną pracę zespołów

Odpowiedź seniora

Problem nie jest techniczny, tylko w procesie: dostępność była jednorazowym projektem. Wbudowuję ją w miejsca, przez które przechodzi każda zmiana.

Automatyka: eslint-plugin-jsx-a11y jako błędy, axe w testach komponentów (vitest-axe) i w Playwright na kluczowych ścieżkach, blokujące merge. Komponenty z design systemu wymuszają dostępność typami, np. IconButton wymaga propa label, a Modal sam zarządza fokusem, więc łatwiej zrobić dobrze niż źle.

Ludzie: checklista w szablonie PR-a (klawiatura, nazwy, błędy formularzy), krótki warsztat z czytnikiem ekranu dla każdego zespołu, osoba odpowiedzialna za dostępność w każdym zespole, projektanci z adnotacjami dostępności w Figmie. Co kwartał krótki ręczny test ścieżek krytycznych. Mierzę liczbę naruszeń axe w czasie i liczbę zgłoszeń od użytkowników.

Typowe wpadki

Kolejny zewnętrzny audyt bez zmiany procesu
Wiara, że automatyczne testy złapią wszystko
Obarczenie jednej osoby odpowiedzialnością za całą firmę

Dopytają o

Jak przekonasz zespół, że błąd axe ma blokować merge?
Które problemy automat przepuści na pewno?
Jak włączysz w to projektantów?

Zapytaj Claude Rozwiń case Zagraj interviewera

Co piszą w ogłoszeniach

Plac zabaw z zamkniętą furtką

Div czy button?

Furtka dla każdego

Nazwa, rola, stan

Wróć tam, skąd przyszedłeś

Pytania z rozmów

Wersja dla seniora

Co sprawdza rekruter

Odpowiedź seniora

Typowe wpadki

Dopytają o

Co sprawdza rekruter

Odpowiedź seniora

Typowe wpadki

Dopytają o

Co sprawdza rekruter

Odpowiedź seniora

Typowe wpadki

Dopytają o