Porównaj dwie wersje panelu kontaktu. A ma cztery celowe defekty, B poprawia te konkretne elementy. Ćwiczenie uczy rozdzielenia wyglądu, obsługi klawiaturą, semantyki i odbioru przez czytnik. B nie jest deklaracją pełnej zgodności z WCAG.
Uruchomienie i bezpieczne dane
W katalogu projektu uruchom:
node tools/serwer-lekcji.cjsOtwórz http://127.0.0.1:8787/content/cwiczenia/interfejs-demo/lab.html. Plik laboratorium jest samowystarczalnym HTML bez zewnętrznych usług. Lokalny serwer zapewnia wspólny adres ćwiczeń; formularz nie wywołuje API wysyłki, nie zapisuje danych i nie wysyła poczty. Użyj qa@example.com i tekstu „Wiadomość testowa”.
Zapisz system, wersję przeglądarki, wariant, viewport w pikselach CSS i zoom. „Resetuj ćwiczenie” przywraca A, puste pola, zamknięte menu i pusty wynik. Zmiana wariantu również przebudowuje panel, więc przed porównawczą próbą wpisz dane ponownie. To jawny mechanizm demo.
Wymagania
- Przy viewport 360 px główna treść ma być dostępna bez przewijania całej strony w poziomie.
- Menu ma być osiągalne i obsługiwalne klawiaturą; programowo dostępny stan odpowiada rozwinięciu.
- E-mail ma mieć trwałą, powiązaną programowo etykietę, która pozostaje po wpisaniu danych.
- Po wysłaniu poprawnych danych komunikat lokalnej symulacji ma być przygotowany do ogłoszenia bez przenoszenia fokusu.
Pola e-mail i wiadomości są wymagane. Natywna walidacja przeglądarki blokuje puste lub niepoprawne dane; szczegóły jej komunikatów mogą zależeć od środowiska. Prawidłowe wysłanie pokazuje: „Wiadomość wysłana — symulacja. Dane nie opuściły przeglądarki.”.
Zadania bez podglądania rozwiązania
1. Układ
Po resecie ustaw 360×800 w Responsive w DevTools. Obejrzyj stronę i spróbuj wykonać całe zadanie formularza. W Console odczytaj document.documentElement.scrollWidth i document.documentElement.clientWidth. Zapisz element powodujący problem oraz skutek. Następnie wybierz B przy tych samych wymiarach i porównaj. Sprawdź także 1280×900 oraz zaplanuj sąsiedztwo progu zmiany układu.
2. Klawiatura i menu
Zacznij w szerokim widoku. Bez myszy przejdź Tabem i Shift+Tabem przez kontrolki. Spróbuj otworzyć oraz zamknąć menu. Zapisz rzeczywistą kolejność i osiągalność. W B użyj Enter oraz Spacji na przycisku menu. Sprawdź jego stan przed otwarciem, po otwarciu i po zamknięciu.
3. Etykieta i wynik
Sprawdź HTML oraz informacje dostępności pola e-mail w A/B. Odróżnij widoczny placeholder od etykiety. Wyślij syntetyczne dane i zbadaj semantykę elementu z komunikatem. Podaj osobno, co wykazała inspekcja, a co rzeczywisty odbiór czytnikiem. Jeśli nie używałeś czytnika, oznacz ten test jako niewykonany.
4. Dalsze sprawdzenia
Wykonaj pełne zadanie przy 200% zoom strony; nie myl tego ze skalą podglądu Device Mode. Sprawdź małą wysokość, orientację poziomą oraz długą wiadomość. Test telefonu i ręczny czytnik są osobnymi pracami; wynik emulacji ich nie zastępuje. Niewykonane próby pozostają niewykonane.
Wykorzystaj checklistę responsywności i PDF oraz checklistę dostępności i PDF. Zapisz wynik i dowód, nie sam znacznik przy oczekiwaniu.
Rozwiązanie i uzasadnienie
| Obszar | Wariant A — celowy defekt | Wariant B — poprawa |
|---|---|---|
| Układ | .surface.bad ma min-width: 760px, więc wychodzi poza 360 px. | Brak tego minimum; przy szerokości do 700 px panel pomocy przechodzi pod formularz. |
| Menu | #menu to klikany div, bez klawiatury i stanu rozwinięcia. | Natywny button, aria-controls, aktualizowane aria-expanded; działa Enter i Spacja. |
Placeholder bez trwałego label powiązanego z polem. | label for="email" wskazuje input id="email". | |
| Komunikat | Dynamiczny tekst w zwykłym akapicie. | Istniejący wcześniej region role="status" i aria-live="polite". |
W automatycznym pomiarze przy 360×800 uzyskano A: clientWidth=360, scrollWidth=778; B: obie wartości 360. Liczba 778 wynika z całego układu, nie zastępuje wymagania minimalnej szerokości 760 px. Test projektu potwierdził menu B Enterem i Spacją, aktualizację stanu, etykietę, rolę komunikatu, pokazanie lokalnej symulacji oraz reset.
Pole wiadomości ma etykietę w obu wariantach. Nie zgłaszaj więc ogólnie „wszystkie pola bez etykiet”. Nie twierdź „czytnik nie odczytał” wyłącznie na podstawie braku regionu live w DOM. Zapisz rodzaj dowodu i wykonaj rzeczywistą próbę, jeśli taki wniosek ma znaleźć się w raporcie.
Przykładowy raport dla układu: „Wariant A wymaga poziomego przewijania przy 360×800 i 100% zoom; oczekiwanie to dostęp do głównej treści w szerokości viewportu”. Dla menu: „Po resecie A kontrolka otwarcia menu jest pomijana w nawigacji Tabem i nie ma równoważnej obsługi klawiaturą”. Załącz własną próbę i warunki, a nie jedynie rozwiązanie lekcji.
Weryfikacja i ograniczenia
2 października 2026 r. wykonano automatyczną weryfikację w Node v24.16.0 i Chromium 151.0.7922.34. Wyniki testu projektu zapisano w tmp/qa-interfejs/wyniki.json. Osobny odczyt potwierdził wymiary, tag menu, liczbę powiązanych etykiet i rolę komunikatu dla A/B. Nie wykonano ręcznego czytnika ekranu, testu fizycznego telefonu ani ręcznego zoom 200%. Nie przeprowadzono pełnego audytu WCAG, bezpieczeństwa lub doręczenia wiadomości.
Lekcje: responsywność oraz podstawy dostępności. Autor serwisu: Marcin Kozłowski.
Lokalną demonstrację, instrukcję i materiały dydaktyczne przygotowano z pomocą AI.