Przycisk reaguje na mysz, pole ma napis „E-mail”, a sukces pojawia się na ekranie. To jeszcze nie rozstrzyga, czy formularz jest użyteczny dla osoby korzystającej z klawiatury lub czytnika ekranu. Trzeba sprawdzić, czy działanie można wykonać, czy kontrolka ma zrozumiałą nazwę i czy zmiana wyniku jest dostępna także poza samym widokiem strony.
W tej lekcji wykonasz pierwszą kontrolę interfejsu demonstracyjnego. Wariant A ma celowe braki, B poprawia konkretne elementy. Pracujemy na lokalnej symulacji wysłania wiadomości, bez prawdziwych kont i usług. Celem jest rozpoznanie problemu oraz zapis dowodów. Nie wystawiamy na podstawie kilku prób deklaracji pełnej zgodności z WCAG.
1. Zdefiniuj zadanie i zakres kontroli
Zadanie użytkownika jest proste: otworzyć menu, przejść do formularza, wpisać syntetyczny e-mail i wiadomość, wysłać je oraz rozpoznać wynik. Takie podejście pozwala sprawdzić ciąg działań zamiast przypadkowej listy atrybutów. Wariant B nie staje się w pełni dostępny tylko dlatego, że ma więcej poprawnego HTML.
Wstępna kontrola skupia się na klawiaturze, widocznym fokusie, nazwach pól, stanie menu i dynamicznym komunikacie. W3C WAI Easy Checks przedstawia proste sprawdzenia jako początek oceny, nie pełny audyt. Kontrast, teksty alternatywne innych treści, rozbudowane dialogi czy wszystkie technologie asystujące wymagają dalszego planu.
Zapisz rodzaj każdej próby: zachowanie klawiatury, inspekcja semantyki albo rzeczywisty test czytnikiem. Te wyniki są powiązane, ale nie zamienne. Widoczny atrybut role="status" potwierdza mechanizm w kodzie. Nie potwierdza samodzielnie, że wybrane połączenie czytnika i przeglądarki odczytało komunikat w użyteczny sposób.
2. Przygotuj demo i warunki
Uruchom node tools/serwer-lekcji.cjs i otwórz http://127.0.0.1:8787/content/cwiczenia/interfejs-demo/lab.html. Kliknij reset. Powinien zostać wybrany A, menu zamknięte i pola puste. Zanotuj wersję labu 1.0, system oraz przeglądarkę. Jeśli używasz czytnika, dodaj jego nazwę, wersję i ustawienia istotne dla obserwacji.
Najpierw pracuj w szerokim widoku, aby oddzielić problem klawiatury od celowego poziomego przepełnienia w A. Później wrócisz do 360 px, omawianych w lekcji responsywności. Zmiana A/B przebudowuje panel i czyści jego stan. Jeśli chcesz powtórzyć wysłanie, wpisz dane ponownie.
Nie uruchamiaj automatycznego skanera jako jedynej oceny. Potrafi on wskazać część braków, lecz nie rozstrzyga całej użyteczności zadania. W tym ćwiczeniu wystarczą przeglądarka, klawiatura i inspekcja elementów; ręczny czytnik pozostaje odrębnym etapem, którego nie zastępuje wynik automatycznych testów projektu.
Najpierw ustal działanie i semantykę. Następnie osobno potwierdź odbiór komunikatu czytnikiem ekranu.
3. Odłóż mysz i przejdź cały interfejs
Kliknij „Resetuj ćwiczenie”, aby ustalić punkt startowy na tym przycisku. W zweryfikowanej próbie Chromium po kliknięciu fokus pozostał na #reset; Tab przeszedł do e-maila, pomijając wadliwe menu A, a Shift+Tab wrócił do resetu. Kolejny Shift+Tab prowadzi do wyboru wariantu. Od tego punktu używaj Tab i Shift+Tab oraz zapisz kolejność osiąganych elementów. Czy możesz dotrzeć do menu, pól oraz wysłania? Czy wiesz, który element jest aktywny? Nie wystarczy zobaczyć zmianę kursora: fokus powinien dawać widoczną informację o miejscu działania.
W A element „Otwórz menu” jest zwykłym div z obsługą kliknięcia. Nie znajduje się w typowej kolejności Tab i nie ma obsługi klawiatury. Możesz kliknąć go myszą, ale badane działanie nie jest dostępne tym samym sposobem użytkownikowi klawiatury. To celowy problem demonstracji.
W B menu jest przyciskiem. Przejdź do niego Tabem, aktywuj Enterem, a następnie Spacją. Sprawdź rozwinięcie i zwinięcie, tekst kontrolki oraz odnośniki w otwartym obszarze. Dla natywnego przycisku takie zachowanie jest oczekiwane. Kryterium WCAG 2.1.1 Keyboard dotyczy możliwości obsługi funkcji przez interfejs klawiatury; nie sprowadza się do obecności konkretnego atrybutu.
W projekcie automatycznie potwierdzono działanie menu B Enterem i Spacją. Ręcznie nadal oceń całą drogę przez interfejs i czytelność wskaźnika. element.focus() w skrypcie nie dowodzi, że zwykła nawigacja Tabem pozwala osiągnąć każdy cel użytkownika.
4. Sprawdź fokus i możliwość wyjścia
Fokus nie powinien znikać w tle ani pozostawać w miejscu, którego użytkownik nie widzi. W demo zastosowano obrys dla :focus-visible. Obejrzyj go na kontrolkach, przejdź w obie strony i sprawdź, czy menu nie tworzy pułapki. Wymaganie rozpoznawalnego wskaźnika opisuje W3C: Focus Visible.
Po otwarciu menu sprawdź odnośniki, a po zamknięciu upewnij się, że nie przechodzisz do ukrytej zawartości. Dla prostego rozwijanego obszaru nie oczekuj automatycznie zachowania aplikacyjnego menu z klawiszami strzałek. Ten lab używa przycisku pokazującego sekcję odnośników, czyli wzorca disclosure. Nie ma złożonego komponentu role="menu".
Przy zmianie wariantu zawartość jest przebudowywana. To moment resetu ćwiczenia, a nie kontynuacja tej samej ścieżki formularza. W rzeczywistym produkcie dynamiczna wymiana elementów może wymagać dodatkowego zarządzania fokusem. Nie wyciągaj pełnej oceny takich zmian z naszego ograniczonego porównania.
5. Odczytaj nazwę, rolę i stan menu
Semantyka przekazuje, czym jest element i jaką ma funkcję. Przycisk B ma tekst „Otwórz menu”, aria-expanded="false" i aria-controls wskazujące rozwijany obszar. Po otwarciu stan zmienia się na true, a tekst na „Zamknij menu”. Zamknięcie przywraca false i ukrywa odnośniki.
Sprawdź te wartości w DevTools, wybierając element w Elements. Porównaj atrybut z faktycznym widokiem. Samo występowanie aria-expanded niczego nie naprawia, jeśli wartość pozostaje nieaktualna. W3C APG Disclosure opisuje przycisk i stan rozwinięcia dla takiego wzorca.
Jeśli programista doda role="button" do div, nie pojawi się automatycznie komplet zachowania natywnego przycisku. Trzeba nadal zapewnić osiągalność, aktywację i stan. W demo B używa rzeczywistego button, co pozwala skorzystać z zachowania przeglądarki. Jako tester sprawdzaj funkcję i nazwę, a nie samą liczbę atrybutów ARIA.
6. Nie traktuj placeholdera jako trwałej etykiety
W A e-mail ma tylko placeholder. Po wpisaniu adresu podpowiedź znika, a kod nie zawiera powiązanego label. W B widoczny napis „E-mail” pozostaje i jest połączony przez for="email" z id="email". Kliknięcie etykiety powinno kierować fokus do właściwego pola; to użyteczna kontrola powiązania, ale nie cała ocena nazwy dostępnej.
Otwórz inspekcję pola. Sprawdź etykietę oraz nazwę pokazywaną w informacjach dostępności przeglądarki. Technologie mogą wykorzystać placeholder jako źródło nazwy w pewnych warunkach; dlatego brak labela nie uzasadnia ogólnego zdania „każdy czytnik nic nie przeczyta”. Problem demo polega na braku trwałej, programowo powiązanej etykiety wymaganej dla tego pola.
Mechanizm etykiet opisuje W3C WAI: Labeling Controls. Etykieta mówi, jakie dane wpisać; przykład formatu może być dodatkową instrukcją. qa@example.com nie zastępuje nazwy „E-mail”. Sprawdź również wiadomość: jej etykieta jest powiązana w obu wariantach, więc nie zgłaszaj braku wszystkich etykiet na podstawie jednego pola.
7. Wywołaj błąd i popraw dane
Wyślij pusty formularz, potem e-mail o błędnym formacie przy wypełnionej wiadomości. Natywna walidacja przeglądarki powinna zablokować wysłanie. Oceń, czy można rozpoznać problem, przejść do pola i go poprawić. Konkretne brzmienie oraz wygląd komunikatu mogą różnić się między przeglądarkami; zapisuj zaobserwowany wynik i środowisko.
Wymaganie labeli oraz instrukcji wejściowych objaśnia W3C: Labels or Instructions. Nie twórz jednak wniosku o spełnieniu całego kryterium na podstawie obecności dwóch napisów. Sprawdź, czy instrukcja odpowiada zadaniu i pozostaje zrozumiała podczas poprawy danych.
Wpisz qa@example.com oraz „Test dostępności” i wyślij klawiaturą. Dane mają być syntetyczne. Przeglądarka wykonuje lokalną obsługę formularza; nie powstaje żądanie wysłania poczty. Jeśli widzisz tekst sukcesu, oceniasz dostępność informacji o symulacji, a nie niezawodność doręczenia wiadomości.
8. Oddziel region statusu od potwierdzonego odczytu
W A dynamiczny wynik trafia do zwykłego akapitu. W B akapit istnieje przed wysłaniem i ma role="status" oraz aria-live="polite". Zmienia się jego treść, bez przenoszenia fokusu do komunikatu. To mechanizm przygotowujący zmianę do ogłoszenia przez technologie asystujące.
Statusy opisuje W3C: Understanding Status Messages. Nie każdy nowy tekst wymaga regionu live i nie każdy komunikat wymaga agresywnego alert. Dla spokojnego potwierdzenia działania użyteczny jest status. Nadmiar ogłoszeń może utrudniać pracę, dlatego oceniaj także zrozumiałość wyniku.
Rzeczywisty test wykonaj wybranym czytnikiem: wczytaj B, przejdź pola, wpisz dane, wyślij i posłuchaj wyniku bez ręcznego wyszukiwania akapitu. Zapisz, co zostało odczytane, czy informacja przyszła we właściwym momencie oraz czy dało się kontynuować. Powtórz w A przy tych samych warunkach. Nie wpisuj hipotetycznego tekstu do wyników rzeczywistych.
W weryfikacji materiału nie używano ręcznego czytnika ekranu. Automatycznie potwierdzono role i powiązania, aktywację menu oraz pojawienie się tekstu symulacji. Odczyt pozostaje niewykonany. Takie ograniczenie nie unieważnia wykrytych braków w kodzie, ale wyznacza granicę dowodu.
9. Zadanie, rozwiązanie i raport
Wykonaj dwie karty prób A/B. W każdej zapisz: dostęp do menu klawiaturą, widoczny fokus, etykietę e-maila, stan rozwinięcia i mechanizm komunikatu. Przy teście czytnikiem użyj osobnego pola „wynik rzeczywisty” lub „niewykonany”. Pomogą checklista i PDF.
Rozwiązanie porównania: A ma nieobsługiwany klawiaturą div menu, brak powiązanego labela e-maila i brak regionu statusu. B ma przycisk, aktualizowany stan rozwinięcia, label/for i region statusu. Czwarty defekt A dotyczy poziomego przepełnienia przy 360 px i jest szerzej opisany w lekcji responsywności. Nie zakładaj, że wszystkie kontrole A są błędne albo że B spełnia wszystkie kryteria WCAG.
Przykładowy tytuł raportu brzmi „Menu wariantu A nie daje się otworzyć klawiaturą”. Podaj reset, wariant i rzeczywistą drogę Tabem, oczekiwane działanie oraz wynik. Dla statusu nazwij rodzaj dowodu: „w DOM brak regionu statusu”, jeśli badano kod; „czytnik nie ogłosił wyniku”, wyłącznie jeśli wykonano taką próbę i zapisano środowisko.
Po poprawce powtórz zadanie, nie tylko inspekcję atrybutu. Etykieta może wskazywać niewłaściwe pole, aria-expanded może się nie zmieniać, a przycisk może nie otwierać zawartości. Zaliczenie wymaga spójności zachowania oraz semantyki w zdefiniowanym zakresie.
Jeżeli brak dostępu do czytnika blokuje ten etap, zachowaj raport o potwierdzonych brakach i osobno zapisz potrzebę testu odbioru. Nie usuwaj całej obserwacji tylko dlatego, że nie wykonano pełnej oceny. Takie rozdzielenie daje zespołowi konkretną pracę: poprawić mechanizm, ponowić sprawdzenie i uzupełnić brakujący dowód.
Źródła odczytano 2 października 2026 r. W Chromium 151.0.7922.34 potwierdzono automatycznie różnice elementów i etykiet; projektowy test labu sprawdził Enter, Spację, status oraz reset. Nie wykonano ręcznego czytnika ekranu, pełnego audytu WCAG ani testu fizycznego telefonu. Autor serwisu: Marcin Kozłowski. Tekst przygotowany z pomocą AI.
Research i tekst: GPT-6.1 Sol, reasoning medium.