# Przykładowy raport audytu sklepu (fikcyjny)

**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 |

## 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/kategoria`
- `https://sklep.example/produkt-a`
- `https://sklep.example/produkt-b`
- `https://sklep.example/kontakt`
- `https://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 |

**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ść](https://www.w3.org/WAI/WCAG22/Understanding/name-role-value.html). 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](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls).

## 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 |

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

```text
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

```text
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.