Najważniejsze wnioski
- W standardowym wdrożeniu ręczny kod WCAGbot należy wkleić do wspólnego pliku motywu Shopify, zwykle przed zamknięciem znacznika </body> w theme.liquid.
- Przed edycją aktywnego motywu warto utworzyć jego kopię, przetestować zmianę na komputerze i telefonie, a dopiero potem publikować motyw.
- Koszyk Shopify i checkout to odrębne obszary techniczne. Kod działający w motywie nie powinien być automatycznie uznawany za działający na ekranach checkoutu.
- Widget wspiera użytkownika funkcjami prezentacji i nawigacji, ale bariery w nazwach przycisków, fokusie, formularzach, błędach i strukturze kodu wymagają audytu oraz naprawy źródłowej.
- Najważniejszy test nie kończy się na stronie głównej: trzeba przejść pełną ścieżkę od produktu przez koszyk do checkoutu, używając klawiatury i co najmniej jednego czytnika ekranu.
Dla zarządzającego
Wdrożenie WCAGbot w motywie Shopify jest szybkim pierwszym krokiem do dostępności cyfrowej, ale decyzja zarządcza powinna obejmować także plan audytu koszyka, checkoutu, treści i integracji płatniczych. Największe ryzyko nie dotyczy samego wklejenia kodu, lecz pominięcia krytycznej ścieżki zakupowej po zmianach motywu lub aplikacji.
Dla sprzedaży
W rozmowie z klientem warto jasno rozdzielać dwie rzeczy: WCAGbot daje użytkownikowi narzędzia, takie jak kontrast, większy tekst i czytanie treści, natomiast dostępność procesu zakupu wymaga testu przycisków, koszyka, formularzy, błędów i płatności. Uczciwy komunikat zwiększa zaufanie: widget wspiera dostępność, lecz nie zastępuje audytu WCAG ani poprawek w kodzie.
WCAGbot na Shopify zainstalujesz najczęściej przez wklejenie otrzymanego fragmentu kodu do pliku theme.liquid, przed </body>. Zrób to najpierw w kopii motywu i sprawdź pełną drogę zakupu: produkt, dodanie do koszyka, koszyk lub cart drawer oraz przejście do checkoutu. Samo uruchomienie widgetu daje użytkownikowi dodatkowe funkcje wspierające dostępność, ale nie zastępuje testów ani napraw barier w kodzie i treści.
Najważniejsze rozróżnienie w Shopify brzmi: koszyk jest zwykle częścią motywu, a checkout jest osobnym środowiskiem. Dlatego panel widoczny na karcie produktu nie jest dowodem, że będzie dostępny na każdym kroku płatności.
Najważniejsze wnioski
- Wklej kod do wspólnego layoutu motywu, a nie tylko do szablonu produktu.
- Pracuj na duplikacie motywu, ponieważ edycja Liquid może wpłynąć na cały sklep.
- Testuj koszyk klawiaturą, na telefonie i z czytnikiem ekranu.
- Traktuj checkout jako osobny zakres kontroli technicznej.
- Zapisuj wykryte bariery jako zadania do audytu i naprawy źródłowej.
Widget może dać użytkownikowi kontrolę nad prezentacją strony. Dostępny zakup wymaga jednak, aby sama ścieżka zakupu była zrozumiała, obsługiwana klawiaturą i poprawnie opisana w kodzie.
Gdzie dodać kod WCAGbot w Shopify?
Jeśli otrzymujesz od WCAGbot ręczny fragment <script>, standardowym miejscem jest wspólny plik layoutu motywu. Dzięki temu skrypt może zostać załadowany na stronach korzystających z tego motywu, między innymi na stronie głównej, listach kolekcji, kartach produktów i standardowej stronie koszyka.
- W panelu Shopify przejdź do Sklep online → Motywy.
- Przy aktywnym motywie wybierz menu działań i utwórz kopię motywu.
- Otwórz kopię przez Edytuj kod.
- Wyszukaj plik
layout/theme.liquid. - Wklej kod WCAGbot bezpośrednio przed
</body>. - Zapisz zmiany i otwórz podgląd kopii motywu.
To zgodne z opisanym przez WCAGbot sposobem wdrożenia jedną linią kodu. Shopify zaleca ostrożność przy bezpośredniej edycji kodu motywu i wskazuje, aby przed zmianami utworzyć kopię. Jest to praktyczne zabezpieczenie: można porównać zachowanie starej i testowej wersji sklepu, bez ryzyka natychmiastowej ingerencji w sprzedaż.
Kiedy użyć app embed zamiast edycji pliku?
App embed ma sens tylko wtedy, gdy dana aplikacja udostępnia natywną integrację Shopify w tej formie. Shopify opisuje osadzenia aplikacji jako mechanizm dla skryptów i elementów pływających, aktywowany w edytorze motywu. Nie zakładaj jednak, że każda usługa zewnętrzna ma gotowe osadzenie aplikacji.
Jeżeli WCAGbot przekazuje ręczny kod, stosuj instrukcję wdrożeniową produktu i umieść fragment w theme.liquid. Nie przenoś go samodzielnie do przypadkowej sekcji Liquid, bloku produktu lub opisu strony. Taki montaż może ograniczyć działanie widgetu do jednego widoku albo powodować wielokrotne ładowanie skryptu.
Czy warto użyć Google Tag Managera?
Technicznie jest to możliwe, lecz przed wyborem sprawdź zasady uruchamiania tagów po zgodzie cookies. Jeżeli kontener ładuje widget dopiero po uzyskaniu zgody, użytkownik może wejść na stronę bez panelu. W przypadku funkcji wspierających dostępność jest to istotne ograniczenie doświadczenia użytkownika. Dla stałego elementu sklepu prostsze i bardziej przewidywalne jest wdrożenie w motywie.
WCAGbot Accessibility Path: bezpieczny proces wdrożenia
W sklepie Shopify warto uporządkować pracę w prostym schemacie WCAGbot Accessibility Path. Jego celem nie jest deklarowanie zgodności, lecz ograniczenie ryzyka, że szybka instalacja ominie kluczowe elementy zakupu.
- Zabezpiecz motyw: utwórz kopię aktywnej wersji.
- Dodaj kod: umieść fragment WCAGbot przed
</body>wtheme.liquid. - Sprawdź panel: otwórz go na desktopie i telefonie; przetestuj kontrast, powiększenie tekstu, odstępy oraz czytanie treści.
- Przejdź ścieżkę zakupu: produkt, wariant, dodanie do koszyka, koszyk, checkout.
- Oddziel obserwacje: zapisz, co jest funkcją widgetu, a co jest błędem wymagającym zmiany w motywie, aplikacji lub treści.
- Opublikuj świadomie: po testach opublikuj motyw albo wróć do poprawki.
WCAGbot Accessibility Path dla sklepu Shopify
Otwórz panel WCAGbot na kopii motywu i sprawdź stronę na własnym przykładzie: zmień kontrast, zwiększ tekst, uruchom czytanie zaznaczonego opisu produktu, a następnie przejdź do koszyka. W ten sposób najszybciej zobaczysz, czy pływające elementy interfejsu nie nachodzą na siebie.
Dlaczego koszyk i checkout trzeba testować osobno?
Standardowa strona /cart oraz koszyk wysuwany, czyli cart drawer, są najczęściej renderowane przez motyw. Kod dodany do theme.liquid może więc działać w tych widokach, o ile motyw lub aplikacja nie zmienia sposobu ich ładowania.
Checkout Shopify ma natomiast własną architekturę. Dokumentacja Shopify wskazuje, że rozszerzenia motywu, w tym app embeds i app blocks, nie są renderowane na stronach checkoutu. Nie należy więc obiecywać, że widget zainstalowany w motywie pojawi się automatycznie na ekranie danych kontaktowych, dostawy, płatności i potwierdzenia zamówienia.
Dotyczy to także aplikacji płatniczych, punktów odbioru, szybkich płatności oraz innych komponentów zewnętrznych. Każdy taki element wymaga odrębnego sprawdzenia w realnej konfiguracji sklepu.
Co sprawdzić w koszyku Shopify?
| Element | Co testować | Typowa bariera wymagająca naprawy źródłowej | Co może wspierać WCAGbot |
|---|---|---|---|
| Ikona koszyka | Nazwa dostępna, Tab, Enter i Space | Ikona odczytywana przez czytnik wyłącznie jako „button” | Większy tekst, kontrast i narzędzia ułatwiające czytanie interfejsu |
| Cart drawer | Fokus po otwarciu, Escape, powrót fokusu po zamknięciu | Fokus przechodzi za panel lub nie wraca do przycisku otwierającego | Funkcje skupienia, większy kursor i przewodnik do czytania |
| Zmiana ilości | Etykieta pola, nazwy przycisków, komunikat o aktualizacji | Brak informacji, którego produktu dotyczy kontrolka | Powiększenie tekstu i odstępów |
| Usunięcie produktu | Nazwa z kontekstem produktu, komunikat po usunięciu | Sama ikona kosza bez nazwy dostępnej | Ułatwienia prezentacji, nie zastępują opisu kontrolki |
| Rabat i suma | Logiczna kolejność, opis rabatu, czytelna waluta | Informacja przekazana tylko kolorem lub niejasną strukturą | Tryby kontrastu i skali szarości |
| Przejście do checkoutu | Widoczność na telefonie, klawiatura, jednoznaczna nazwa | Przycisk zasłonięty przez chat, banner cookies lub drawer | Możliwość sprawdzenia widoku przy większym tekście |
1. Przycisk otwierający koszyk
Sprawdź, czy przycisk ma programowo dostępną nazwę, na przykład „Otwórz koszyk, 2 produkty”. Sama grafika torby lub wózka nie jest wystarczającą informacją dla użytkownika czytnika ekranu. Przycisk powinien działać po przejściu klawiszem Tab oraz po aktywacji Enterem lub spacją.
Po dodaniu produktu licznik koszyka powinien zostać zaktualizowany nie tylko wizualnie. W3C w kryterium 4.1.3 opisuje komunikaty statusowe, które technologia asystująca może przekazać bez wymuszania przenoszenia fokusu. To właściwy punkt odniesienia dla komunikatu „Produkt dodany do koszyka”.
2. Koszyk wysuwany, czyli cart drawer
Cart drawer przypomina dialog: pojawia się nad stroną, ma własne kontrolki i powinien przejąć uwagę użytkownika. Po jego otwarciu fokus powinien trafić do nagłówka albo pierwszego sensownego elementu panelu. Użytkownik klawiatury nie powinien przechodzić Tabem do przycisków ukrytych pod nakładką.
Sprawdź też zamknięcie klawiszem Escape. Po zamknięciu fokusu nie należy gubić: powinien wrócić do przycisku, który otworzył koszyk. Szczegółową procedurę przejścia po stronie bez myszy znajdziesz w artykule Nawigacja klawiaturą: test strony bez myszy w 15 minut.
3. Ilość, usuwanie i aktualizacja sumy
Przyciski zwiększenia i zmniejszenia ilości potrzebują zrozumiałych nazw oraz kontekstu produktu. Zamiast nieokreślonego „minus” lepsze jest „Zmniejsz ilość produktu Czarna koszula”. Pole ilości musi mieć widoczną lub programowo powiązaną etykietę, a po zmianie użytkownik powinien otrzymać informację o aktualizacji ilości i kwoty.
Koszyk motywu a checkout Shopify
Podobnie działa usuwanie produktu. Ikona kosza bez dostępnej nazwy jest barierą w kodzie, której widget nie naprawia trwale. Automatyczne uzupełnianie wybranych wykrywalnych atrybutów przez WCAGbot może wspierać część elementów, ale nie powinno zastępować ręcznego sprawdzenia etykiet, kontekstu i działania aplikacji koszykowej. Więcej o granicach takich działań wyjaśnia tekst ARIA bez pułapek: kiedy pomaga, a kiedy psuje dostępność?.
4. Kontrast, mobilność i nakładające się elementy
Na telefonie otwórz koszyk przy aktywnym większym tekście i sprawdź, czy nadal widzisz przyciski „Usuń”, „Przejdź do checkoutu” oraz zamknięcie panelu. Zwróć uwagę na chat, baner cookies, komunikaty promocyjne i sticky bar. Każdy z nich może kolidować z panelem WCAGbot albo z przyciskiem zakupu.
Funkcje kontrastu, powiększenia tekstu, interlinii, odstępów liter i czytania treści pozwalają użytkownikowi dopasować warstwę prezentacji. Ich praktyczne zastosowania opisuje wpis Kontrast, większy tekst i czytanie treści w WCAGbot. Jeżeli jednak przy powiększeniu tekstu przycisk znika, nachodzi na inny element lub wypada poza ekran, jest to sygnał do poprawy CSS i układu motywu.
Co sprawdzić po przejściu do checkoutu?
Po kliknięciu przycisku przejścia do checkoutu wykonaj osobny test. Nie oceniaj checkoutu wyłącznie na podstawie deklaracji platformy ani na podstawie zachowania strony koszyka. Shopify rozwija dostępność checkoutu, jednak zewnętrzne metody płatności, rozszerzenia oraz konfiguracja konkretnego sklepu nadal mogą zmieniać doświadczenie użytkownika.
- Każde pole ma widoczną etykietę oraz określony cel, na przykład e-mail, telefon lub kod pocztowy.
- Komunikat błędu opisuje problem tekstem, wskazuje pole i podpowiada sposób poprawy.
- Po błędzie wcześniej wpisane dane nie znikają bez potrzeby.
- Kolejność przechodzenia klawiszem Tab jest logiczna.
- Wybór dostawy, punktu odbioru i płatności jest możliwy bez myszy.
- Wyskakujące okno lub przekierowanie do płatności informuje użytkownika o zmianie kontekstu.
- Podsumowanie zamówienia, rabaty i suma są zrozumiałe bez opierania się wyłącznie na kolorze.
Wytyczne WCAG są dobrym punktem odniesienia dla etykiet, błędów, fokusu i komunikatów. W kontekście wymagań dla usług warto pamiętać, że WCAG, norma EN 301 549 i Polski Akt o Dostępności to różne dokumenty o różnych rolach. To rozróżnienie omawia artykuł WCAG 2.1, WCAG 2.2 i EN 301 549 – czym się różnią?, a szerszy zakres techniczny przedstawia tekst EN 301 549 dla e-commerce: wymagania poza samym WCAG.
Mini-scenariusz: test sklepu z cart drawer
Scenariusz ilustracyjny — nie jest wynikiem wdrożenia u klienta. Sklep odzieżowy korzysta z motywu Shopify z koszykiem wysuwanym z prawej strony. Administrator tworzy kopię motywu, dodaje kod WCAGbot przed </body> i otwiera podgląd na telefonie.
Po włączeniu większego tekstu panel WCAGbot działa poprawnie na stronie produktu. Podczas testu koszyka okazuje się jednak, że przycisk „Przejdź do checkoutu” znajduje się pod pływającym przyciskiem czatu. Dodatkowo przycisk usuwania produktu ma wyłącznie ikonę kosza, a po otwarciu drawer fokus nadal pozostaje na tle strony.
W tym scenariuszu rozwiązaniem nie jest wyłączenie widgetu ani uznanie, że panel „naprawi” koszyk. Zespół zapisuje trzy zadania: korektę pozycjonowania elementów mobilnych, nadanie przyciskowi usuwania jednoznacznej nazwy i poprawę zarządzania fokusem w cart drawer. Widget pozostaje funkcją wspierającą dostępność, natomiast bariery interakcji trafiają do naprawy źródłowej.
Kiedy instalacja widgetu nie wystarczy?
Wklejenie kodu nie rozwiąże problemów takich jak brak etykiet formularzy, nieprawidłowa kolejność fokusu, niedostępne komunikaty błędów, źle opisane przyciski, tekst alternatywny zdjęć produktów czy struktura nagłówków. Widget nie powinien być przedstawiany jako zamiennik audytu WCAG, testów z użytkownikami ani trwałych zmian w HTML, Liquid, JavaScript, CSS i treści.
Checklist testu cart drawer na telefonie
Jeżeli sklep realizuje usługę e-commerce objętą wymaganiami dostępności, zakres obowiązków warto analizować na podstawie aktualnych przepisów i konkretnej sytuacji firmy. Informacyjny przewodnik o tym, czy PAD może dotyczyć sklepu online, znajdziesz w tekście Czy Polski Akt o Dostępności dotyczy sklepu online?. Ten artykuł ma charakter techniczno-informacyjny i nie stanowi porady prawnej.
Podsumowanie dla zarządzającego i sprzedaży
Dla osoby zarządzającej najrozsądniejszy plan jest dwutorowy: uruchomić WCAGbot jako szybki pierwszy krok do dostępności oraz równolegle wyznaczyć właściciela testu koszyka i checkoutu. Dzięki temu użytkownik może od razu korzystać z funkcji kontrastu, typografii, czytania treści czy ułatwień skupienia, a zespół nie myli tego z zakończeniem prac nad dostępnością.
Dla zespołu sprzedaży kluczowy jest precyzyjny przekaz. WCAGbot może zostać dodany do Shopify bez przebudowy strony i wspiera użytkowników w korzystaniu z treści. Nie zastępuje jednak audytu oraz naprawy źródłowej tam, gdzie koszyk, formularz lub płatność mają bariery. Takie rozróżnienie jest zgodne z uczciwym opisem widgetu dostępności a zgodności z WCAG.
FAQ
Gdzie wkleić kod WCAGbot w Shopify?
W standardowym wdrożeniu ręczny kod wkleja się do pliku layout/theme.liquid, bezpośrednio przed znacznikiem </body>. Najpierw wykonaj tę zmianę w kopii motywu.
Czy kod WCAGbot powinien trafić do opisu produktu?
Nie. Kod dodany tylko do opisu produktu ograniczy działanie do wybranego widoku i może powodować problemy z utrzymaniem sklepu. Właściwym miejscem dla wspólnego skryptu jest layout motywu.
Czy WCAGbot będzie działał w koszyku Shopify?
Może działać w koszyku renderowanym przez motyw, na przykład na stronie /cart lub w cart drawer. Po instalacji trzeba to sprawdzić w konkretnej konfiguracji motywu i aplikacji.
Czy WCAGbot działa automatycznie w Shopify Checkout?
Nie należy tego zakładać. Checkout jest odrębnym obszarem Shopify, a rozszerzenia motywu nie są tam standardowo renderowane. Każdy etap checkoutu należy przetestować osobno.
Czy widget dostępności zapewnia zgodność sklepu z WCAG?
Nie. Widget może wspierać dostępność funkcjami prezentacji i obsługi, ale zgodność wymaga oceny całej strony, kodu, treści, formularzy, interakcji oraz technologii asystujących.
Co najpierw przetestować w cart drawer?
Najpierw sprawdź otwarcie i zamknięcie z klawiatury, fokus po otwarciu, powrót fokusu po zamknięciu, dostępność wszystkich kontrolek oraz widoczność przycisku przejścia do checkoutu na telefonie.
Jak sprawdzić, czy przycisk usuń produkt jest dostępny?
Przejdź do niego klawiszem Tab i uruchom czytnik ekranu. Powinien przekazać nie tylko fakt, że to przycisk, lecz także działanie oraz najlepiej nazwę produktu, którego dotyczy.
Czy sama ikona koszyka wystarcza jako etykieta?
Nie zawsze. Ikona jest zrozumiała wizualnie dla wielu osób, ale użytkownik czytnika ekranu potrzebuje dostępnej nazwy, na przykład „Otwórz koszyk”.
Jak testować sklep Shopify na telefonie?
Sprawdź widok przy większym tekście, aktywnym kontraście i w pionowej orientacji ekranu. Otwórz koszyk, zmień ilość, usuń produkt oraz przejdź do checkoutu. Zobacz, czy żaden przycisk nie jest zasłonięty przez chat, banner cookies lub pływający element.
Co zrobić po aktualizacji motywu Shopify?
Sprawdź ponownie, czy kod WCAGbot pozostał w aktywnym motywie i wykonaj krótki test strony produktu, koszyka oraz przycisku przejścia do checkoutu. Aktualizacja może zmienić layout, skrypty lub zachowanie cart drawer.
Czy warto wykonywać audyt, gdy panel WCAGbot jest już aktywny?
Tak. Audyt pomaga wykryć bariery, których widget nie usuwa trwale, między innymi problemy w formularzach, semantyce, fokusie, komunikatach błędów i strukturze treści.
Chcesz sprawdzić WCAGbot w swoim motywie Shopify? Dodaj funkcje dostępności i przetestuj panel na własnej stronie produktu, w koszyku oraz na widoku mobilnym.
