Mobilna karta produktu: sprawdź pięć stanów przed publikacją

Testuj zadanie na małym ekranie

Otwórz stronę tak, jak zrobi to klient: od linku do konkretnego produktu. Sprawdź, czy nazwa, wariant, cena i przycisk są zrozumiałe bez szukania w kilku sekcjach. Generator AI może ułożyć atrakcyjny widok, ale nie sprawdza automatycznie wszystkich stanów sklepu.

Próba przy 390 pikselach jest użytecznym scenariuszem, nie gwarancją obsługi wszystkich urządzeń. Dodaj własny telefon i ustawienia powiększonego tekstu. Nie oceniaj wyłącznie obrazu z makiety.

Zmieniaj warianty

Wybierz każdy oferowany wariant i porównaj zdjęcie, cenę oraz dostępność. Sprawdź zachowanie opcji niedostępnej i powrót do poprzedniego wyboru. Jeżeli opis pozostał z innego wariantu, popraw dane przed publikacją.

Zapisz źródło wartości. Nie dopuszczaj, aby AI dopisało dostępność lub termin, których nie potwierdza system. Widoczny stan powinien odpowiadać rzeczywistej konfiguracji.

Karta prób

Poniższe przypadki wykonaj na danych testowych. Nie udawaj złożonego zamówienia ani nie obciążaj prawdziwej karty.

Sprawdź komunikat w miejscu problemu

Błąd powinien mówić, które pole wymaga poprawy i jak ją wykonać. Czerwony kolor sam nie wystarcza. Po błędzie użytkownik powinien zachować wpisane informacje, jeśli nie ma powodu ich usuwać.

Na telefonie sprawdź, czy wysunięta klawiatura nie zakrywa istotnego pola lub przycisku. Przewiń do miejsca błędu i wróć. Nie dodawaj animacji, która spowalnia ponowną próbę.

Powtórz po publikacji

Lokalna makieta i opublikowany sklep mogą korzystać z innych zasobów, danych lub płatności. Powtórz najważniejsze próby w rzeczywistym publicznym widoku, zachowując testowy zakres. Zapisz datę, urządzenie i znalezione problemy.

Wynik tej karty to lista wykonanych prób oraz ograniczeń. Nie nazywaj sklepu w pełni dostępnym lub zgodnym z WCAG po kilku ręcznych sprawdzeniach. Pełna ocena wymaga szerszego zakresu.

Dane demonstracyjne dla dwóch wariantów

Własne ćwiczenie ma fikcyjny produkt UI-01. Wariant A ma cenę 149 PLN i stan dostępny, wariant B cenę 169 PLN i stan niedostępny. Początkowy wybór jest pusty. To założenia naszego lokalnego komponentu HTML, nie oferta, zapas magazynu ani aktualna cena w rzeczywistym sklepie. Nie ma klienta, danych płatniczych lub zamówienia.

Przed próbą zapisz oczekiwane zachowanie: brak wyboru wskazuje pole, A pokazuje 149, B 169 i zatrzymanie dalszego kroku. Zmiana z B z powrotem na A powinna zmienić wszystkie zależne informacje. Nie poprawiaj danych testowych po zobaczeniu wyniku, żeby dopasować je do błędnego widoku. Zachowaj wcześniej przyjęte wartości obok obserwacji.

Wykonaj działanie, nie tylko zdjęcie ekranu

W izolowanym własnym komponencie wykonano rzeczywiste kliknięcie pustego wyboru, zmianę A/B i kontrolę komunikatu. Wbudowana walidacja pola wymaganego zatrzymała etap bez wariantu, a niedostępny B dał wskazane zatrzymanie przykładu. To sprawdzenie naszego małego komponentu, nie test Shopify, generatora ani sklepu. Nie wykonano zakupu lub wysyłki danych.

W3C opisuje znaczenie walidacji wymaganych danych i czytelnego powiadomienia o błędzie. Sprawdzenie w przeglądarce nie zastępuje kontroli serwera. Nasz komponent nie ma płatności i nie dowodzi bezpieczeństwa prawdziwego checkoutu. Przy rzeczywistym wdrożeniu potrzebujesz osobnej oceny procesu, danych i odpowiedzi serwera.

Zapisz, skąd startuje klawiatura

W rzeczywistej izolowanej próbie przy 390 i 1440 pikselach ustawiono fokus na wyborze wariantu i użyto klawisza Tab. Fokus przeszedł do przycisku. Początkowy obserwator nie ustalił miejsca startu po wcześniejszym kliknięciu i błędnie oczekiwał tej kolejności. Ustalenie rzeczywistego fokusu poprawiło opis próby; nie udajemy, że ten problem dotyczył jakiegokolwiek sklepu.

W swojej karcie dopisz kolejność elementów, widoczność fokusu i możliwość powrotu do błędu. Nie oceniaj klawiatury wyłącznie na podstawie tego, że przycisk ma kolorową ramkę. Sprawdź samo działanie. Nie nazywaj kilku przejść pełnym audytem dostępności; różne elementy i technologie wymagają szerszego zakresu.

Powiększenie i publiczny widok wymagają osobnych sprawdzeń

W lokalnym przykładzie podwojono rozmiar tekstu i sprawdzono, że dokument nie wychodzi poziomo poza wskazane widoki. Nie testowano wszystkich systemów, czytników ekranu lub prawdziwej wysuwanej klawiatury telefonu. Te granice zapisujemy obok wyniku. Własny telefon i publiczny sklep mogą zachowywać się inaczej niż kontrolowany komponent.

CSV pozwala odtworzyć wejścia, pięć stanów i ograniczenia. Dokumentacja wariantów Shopify pomaga rozumieć przypisanie danych do wariantu, ale nie potwierdza naszej fikcyjnej dostępności. Przed rzeczywistą publikacją połącz cenę i stan z prawdziwym źródłem oraz powtórz bezpieczny zakres w publicznym widoku. Testowe potwierdzenie przykładu nie jest złożonym zamówieniem ani gwarancją działania całego sklepu.

Pobierz dane do własnego ćwiczenia

CSV zawiera wyłącznie przypadek syntetyczny opisany powyżej. To karta do samodzielnego sprawdzenia, nie wynik rzeczywistego przypadku ani plik do importu.

Otwórz ćwiczenie CSV

Źródła i metoda

Autorska karta zadania z jawnymi założeniami i ograniczeniami. Nie przedstawia wykonanych prób, wyników sklepu ani opinii klientów. Aktualne ustawienia i obowiązki sprawdź w źródłach przed wdrożeniem. Rozwinięcie z 9.10.2026: własne ćwiczenie syntetyczne, karta danych i warunki interpretacji. Nie użyto rzeczywistych danych klientów, wyników kampanii ani wykonanych zamówień.

• Shopify: konfiguracja sklepu — sprawdzono: 2026-10-08
• W3C: formularze i dostępność — sprawdzono: 2026-10-08
• W3C: walidacja danych i czytelne błędy — sprawdzono: 2026-10-09
• Shopify: warianty produktów — sprawdzono: 2026-10-09

Daty sprawdzenia podano przy źródłach. Przykłady liczbowe są ilustracją obliczeń, a nie danymi konkretnego sklepu.