To fikcyjny przykład. Sklep Przykład, adresy sklep.example, obserwacje, role, daty i numery dowodów wymyśliłem na potrzeby artykułu. Nie pochodzą od klienta, z CometWeb, z Google ani z żadnego narzędzia. E-01 i E-02 na końcu to opisy wymyślonych dowodów, a nie załączone pomiary.
Metryka scenariusza
| Pole | Wartość w przykładzie |
|---|---|
| Numer raportu | DEMO-RPT-001 |
| Wersja | 1.0 |
| Data | wrzesień 2026 |
| Projekt | Sklep Przykład, firma fikcyjna |
| Rodzaj materiału | Publiczny przykład do nauki, bez danych klienta |
| Autor | CometWeb |
| Cel | Pokazać raport, z którego wynika decyzja, zadanie i retest |
Tabela przewijana poziomo.
Podsumowanie dla klienta (przykład)
W tym scenariuszu sprawdziliśmy sześć publicznych stron i wybrane interakcje. Wyszły dwie grupy problemów: link „Moje konto” nie ma dostępnej nazwy, czyli tej, którą odczytuje czytnik ekranu, a dwa produkty mają sprzeczne deklaracje canonical. Razem to osiem wystąpień w dwóch grupach.
Oba ustalenia dostają priorytet P2. Najpierw trzeba potwierdzić wszystkie warianty komponentu z linkiem i zatwierdzić docelowe adresy produktów. Zmianę canonical wykonawca zgłosił już jako wdrożoną, ale retestu jeszcze nie było, więc nie liczymy jej jako zweryfikowanej poprawki.
Od klienta potrzebujemy trzech decyzji: akceptacji zakresu A11Y-01, wskazania osoby, która zatwierdzi adresy produktów, i dostępu do retestu SEO-01. Kto i kiedy to zrobi, jeszcze nie uzgodniliśmy.
Poza zakresem zostały panel po zalogowaniu, cały proces zakupu, płatności, pełna zgodność z WCAG i bezpieczeństwo aplikacji. Brak danych INP od prawdziwych użytkowników oznacza brak pomiaru, a nie wynik zero. Wnioski nie dotyczą przychodu, pozycji w Google ani zgodności sklepu z prawem.
Zakres scenariusza
Fikcyjna lista sprawdzonych adresów:
https://sklep.example/https://sklep.example/kategoriahttps://sklep.example/produkt-ahttps://sklep.example/produkt-bhttps://sklep.example/kontakthttps://sklep.example/konto
Przyjęliśmy publiczną polską wersję bez logowania, widok na komputerze i stan zgód przy pierwszym wejściu. Ta próbka pasuje do przykładu, a dla prawdziwego sklepu dobierasz ją osobno. W prawdziwym raporcie wpisz wersje przeglądarki i narzędzi, których tu brakuje, bo nikt nie wykonał testów.
Sprawdzenie linku obejmuje nazwę, rolę, fokus i aktywację, bez pełnego logowania. Canonical oceniliśmy tylko w HTML z tego scenariusza, bez danych z indeksu Google.
Tabela decyzji
| ID | Ustalenie | Wystąpienia | Priorytet | Stan pracy | Weryfikacja poprawki |
|---|---|---|---|---|---|
| A11Y-01 | Link konta bez nazwy | 6 na 6 sprawdzonych stron z tym nagłówkiem | P2 | Do realizacji | Nie wykonano |
| SEO-01 | Sprzeczne deklaracje canonical | 2 na 2 sprawdzone produkty | P2 | Wdrożono, czeka na retest | Nie wykonano |
Tabela przewijana poziomo.
Dwie grupy ustaleń, osiem wystąpień, zero zweryfikowanych poprawek. Stron z co najmniej jednym z tych problemów jest sześć, bo oba produkty mają też problem z linkiem. Dlatego 6 + 2 daje osiem wystąpień na sześciu stronach.
Brak danych INP od użytkowników zapisaliśmy osobno jako lukę w danych D-01, poza listą błędów technicznych.
A11Y-01: karta ustalenia
Wszystkie dane w tej karcie są fikcyjne.
Obserwacja: wspólny link konta na sześciu stronach ma rolę link i pustą dostępną nazwę, a prowadzi do /konto. Ta obserwacja nie mówi, czy samo przejście klawiaturą działa.
Dowód: E-01, czyli wymyślony opis drzewa dostępności z sekcji dowodów. W prawdziwym raporcie potrzebny jest plik albo zapis z testu razem z jego metadanymi.
Skutek: osoba z czytnikiem ekranu może nie rozpoznać, dokąd prowadzi link. Nie ustaliliśmy, ilu użytkowników to dotyczy ani jak wpływa na sprzedaż.
Przyczyna: hipoteza, że komponent zawiera tylko ikonę. Przed zmianą trzeba ją potwierdzić w kodzie i spisać warianty mobilne, których tu nie oceniano.
Rekomendacja: nadać linkowi właściwą nazwę, najlepiej widocznym tekstem. Dla komponentu z samą ikoną rozważyć inne rozwiązanie, bez dokładania zbędnych atrybutów ARIA.
Kto realizuje: proponowany developer komponentu, przydział jeszcze nieprzyjęty. Weryfikator: proponowany tester z doświadczeniem w dostępności. Koszt i termin: nieustalone.
Warunek odbioru: nazwa i rola są poprawne we wszystkich zapisanych wariantach, a osobno sprawdzono fokus, Enter i przejście na stronę konta. Warianty mobilne wymagają rozszerzenia zakresu i osobnego wyniku.
Stan: do realizacji. Weryfikacja poprawki: nie wykonano. Kryterium do sprawdzenia to WCAG 2.2, 4.1.2 Nazwa, rola, wartość. Karta ocenia to jedno kryterium, a nie całe WCAG.
SEO-01: karta ustalenia
Wszystkie dane w tej karcie są fikcyjne.
Obserwacja: kod obu produktów deklaruje dwa różne adresy canonical: własny adres produktu i adres kategorii.
Dowód: E-02, wymyślony zapis. Brakuje danych ze sprawdzania adresu URL w Search Console, więc nie wiadomo, który adres wybrał Google ani czy produkt jest w indeksie.
Znaczenie: sprzeczne sygnały o preferowanym adresie trzeba rozstrzygnąć. Ten scenariusz nie daje podstaw, by twierdzić, że produkty wypadły z indeksu albo straciły ruch.
Hipoteza: canonical generują jednocześnie szablon i dodatek. Kodu w tym scenariuszu nie sprawdzano.
Rekomendacja: osoba odpowiedzialna za SEO zatwierdza adresy, a developer usuwa sprzeczną deklarację i sprawdza spójność linków i sitemapy. Produkty zostają w sprzedaży, więc przekierowania nie są tu domyślnym rozwiązaniem.
Stan: wykonawca zgłosił publikację zmiany. To deklaracja wdrożenia bez testu, więc priorytet zostaje P2, a stan techniczny po zmianie jest nieznany.
Warunek odbioru: w początkowym i wyrenderowanym HTML obu produktów nie ma sprzecznych deklaracji, wskazane adresy zgadzają się z zatwierdzoną mapą, a nagłówki, linki i sitemapa są sprawdzone w uzgodnionym zakresie. To, co zrobi Google po ponownym crawlowaniu, obserwujesz w osobnym zadaniu.
Znaczenie canonical opisuje dokumentacja Google Search Central.
D-01: luka w danych
W scenariuszu zabrakło danych INP od prawdziwych użytkowników dla konkretnych adresów. Przyczyny nie ustaliliśmy i nie zastąpiliśmy tych danych ani TBT, ani danymi z innego urządzenia, ani wynikiem dla całej domeny.
Następny krok: sprawdzić dokładny zakres zapytania i to, czy dane w ogóle są dostępne, a jeśli zasady projektu na to pozwalają, rozważyć własny pomiar. Kto i kiedy, do ustalenia. Werdykt: na razie brak podstaw, by ocenić INP u użytkowników.
Plan prac i koszt
| Kolejność | Działanie | Zależność | Kto odpowiada | Koszt i termin |
|---|---|---|---|---|
| Najpierw | Potwierdzić warianty A11Y-01 | Dostęp do komponentu | Przydział do akceptacji | Do wyceny |
| Równolegle | Zatwierdzić mapę adresów SEO-01 | Decyzja osoby odpowiedzialnej za SEO | Właściciel do wskazania | Do uzgodnienia |
| Potem | Wdrożyć A11Y-01 i zrobić retest obu ustaleń | Poprawka, środowisko i dostęp | Developer i weryfikator, do uzgodnienia | Do wyceny razem z retestem |
| Osobno | Uzupełnić D-01 | Dostępność danych i zakres zapytania | Właściciel pomiaru do wskazania | Do ustalenia |
Tabela przewijana poziomo.
Kwot ani godzin nie wpisaliśmy. Rozpoznanie kodu, zmiany, wdrożenie i odbiór wyceń osobno od samego raportu.
Odbiór i decyzje
Retestu żadnego z ustaleń jeszcze nie wykonano, więc żadne nie ma wyniku pozytywnego.
Akceptacja zakresu przez klienta: nie zebrano. Akceptacja ryzyka: brak. Termin kolejnego przeglądu: do ustalenia.
Po teście dopisz wynik, datę, wersję wdrożenia, weryfikatora i linki do dowodów po zmianie. Przy wyniku częściowym część zakresu zostaje otwarta.
Dowody: opisy wymyślone do przykładu
E-01: fikcyjny opis drzewa dostępności
Typ danych: wymyślony przykład, nie log narzędzia
Przykładowy URL: https://sklep.example/produkt-a
Obszar: nagłówek
Rola: link
Dostępna nazwa: pusta
Cel: /konto
Pozostałe warianty: według fikcyjnej listy 6 stron
E-02: fikcyjny fragment deklaracji
Typ danych: wymyślony przykład, nie pobrany HTML
Przykładowy URL: https://sklep.example/produkt-a
Deklaracja canonical A: https://sklep.example/produkt-a
Deklaracja canonical B: https://sklep.example/kategoria
Wybór Google: nieznany
Te opisy pokazują tylko formę zapisu. W prawdziwym zleceniu dołącz zapisy z rzeczywistego badania i zabezpiecz w nich dane wrażliwe.