Najważniejsze wnioski
- Platforma nie jest certyfikatem dostępności: konkretny sklep należy oceniać razem z motywem, dodatkami, treścią i procesem zakupu.
- WordPress daje zwykle szeroką kontrolę nad kodem oraz naprawami, ale każda wtyczka, page builder i zmiana motywu może wprowadzić nową barierę.
- Shopify ma bardziej kontrolowane elementy platformy, lecz motyw, aplikacje, własny Liquid i JavaScript nadal wymagają testów.
- Widget może szybko dodać funkcje wspierające dostępność użytkownika, ale nie zastępuje audytu, testów manualnych ani naprawy błędów w kodzie i treści.
Dla zarządzającego
Nie wybieraj WordPressa ani Shopify wyłącznie na podstawie deklaracji o dostępności. Włącz wymagania dostępności do wyboru motywu, aplikacji, odbioru zmian i utrzymania sklepu.
Dla sprzedaży
W rozmowie z klientem warto rozdzielić szybkie wsparcie użytkownika od trwałej poprawy sklepu. WCAGbot można wdrożyć jako pierwszy krok, równolegle planując testy kluczowych ścieżek i naprawy źródłowe.
Dostępność WordPress i Shopify zależy od wdrożenia, a nie od samej nazwy platformy. Sklep może mieć poprawny rdzeń technologiczny, a jednocześnie blokować zakup przez niedostępny formularz, menu, popup, aplikację marketingową lub źle obsługiwany koszyk. Najbezpieczniejsza decyzja to nie pytanie „która platforma jest zgodna z WCAG?”, lecz „nad którymi elementami mamy kontrolę i jak będziemy je regularnie testować?”.
Najważniejsze wnioski
- Nie zakładaj zgodności na podstawie motywu. W WordPressie oznaczenie „accessibility-ready” nie oznacza zgodności z WCAG AA. W Shopify wysoki wynik Lighthouse jest użytecznym sygnałem jakości, ale nie zastępuje testów manualnych.
- Testuj ścieżkę zakupu. Strona główna nie wystarczy. Sprawdź wyszukiwanie, produkt, wybór wariantu, koszyk, logowanie, formularze i płatność.
- Utrzymanie jest częścią dostępności. Nowa aplikacja, banner, wtyczka, motyw lub kampania promocyjna mogą wywołać regresję.
- Rozdziel wsparcie od naprawy. WCAGbot może dodać użytkownikowi funkcje pomocnicze w kilka minut. Bariery w semantyce, kolejności fokusu, opisach formularzy czy działaniu checkoutu nadal wymagają audytu i naprawy źródłowej.
Dostępność sklepu nie jest właściwością platformy. Jest jakością każdego kroku, który użytkownik wykonuje od znalezienia produktu do otrzymania potwierdzenia zamówienia.
Czy WordPress jest dostępniejszy od Shopify?
Nie ma rzetelnej podstawy, aby uznać jedną z tych platform za automatycznie dostępniejszą od drugiej. Obie mogą obsługiwać dobrze zaprojektowany sklep. Obie mogą też zawierać istotne bariery.
WordPress jest ekosystemem o dużej zmienności. Właściciel lub agencja mogą zwykle zmienić motyw, szablon WooCommerce, kod formularza i zachowanie komponentów. To ułatwia trwałe naprawy, ale oznacza też odpowiedzialność za jakość wtyczek, page builderów, integracji i własnego JavaScriptu.
Shopify zapewnia bardziej kontrolowane środowisko SaaS. Dostawca opisuje WCAG 2.2 jako wytyczne projektowe dla swoich produktów i deklaruje różne metody testowania. Sprzedawca nadal odpowiada jednak za to, co dodaje w motywie, aplikacjach, treści, niestandardowym Liquid oraz kodzie JavaScript. Ponadto zakres kontroli nad elementami zarządzanymi przez platformę może być mniejszy niż w rozwiązaniu opartym na WordPressie.
Co pokazują dane automatycznego skanowania?
Raport WebAIM Million 2025 wykrył błędy związane z WCAG na 94,8% analizowanych stron głównych. Najczęściej występowały problemy z kontrastem, alternatywami tekstowymi obrazów i opisami pól formularzy.
To ważny sygnał dla e-commerce, ale nie ranking platform. Automatyczne narzędzie nie ocenia w pełni sensu tekstu alternatywnego, logiki procesu zakupowego, jakości komunikatu błędu, kolejności obsługi modalu czy zrozumiałości instrukcji. Badanie dotyczyło też stron głównych, a nie kompletnego checkoutu.
WordPress: co sprawdzić przed wyborem motywu i wtyczek?
W WordPressie największe ryzyko pojawia się na styku motywu, WooCommerce, page buildera i dodatków. Jeden niedostępny moduł może wpływać na wiele podstron, zwłaszcza gdy obsługuje nagłówek, menu, formularz kontaktowy, filtr produktów albo popup rabatowy.
Nie myl „accessibility-ready” ze zgodnością z WCAG
Dokumentacja WordPressa wyjaśnia, że motyw oznaczony jako „accessibility-ready” spełnia minimalne wymagania programu przeglądu motywów. Nie jest to potwierdzenie pełnej zgodności z WCAG na poziomie AA. Traktuj oznaczenie jako punkt startu do weryfikacji, a nie jako kryterium końcowe.
WordPress a Shopify: gdzie powstają bariery?
Lista odbiorowa dla WordPressa
- Przejdź klawiaturą przez nagłówek, menu, wyszukiwarkę, filtry, produkt, koszyk i formularz.
- Sprawdź, czy widzisz fokus na każdym interaktywnym elemencie.
- Zweryfikuj, czy menu, akordeony, galerie i modale działają klawiszami Tab, Shift+Tab, Enter, Spacja i Esc tam, gdzie to właściwe.
- Sprawdź etykiety pól, instrukcje, walidację i komunikaty błędów. Praktyczną listę znajdziesz we wpisie Kontrast, alt i błędy formularza: checklista WCAG.
- Oceń każdy dodatek, który wstawia własny interfejs: cookie banner, chat, wyszukiwarkę, pop-up, program lojalnościowy, rezerwacje i płatności.
- Po zmianie motywu lub wtyczki wykonaj retest. Pomocny będzie plan: Regresja dostępności po zmianie motywu: jak jej uniknąć?.
Shopify: jakie ograniczenia trzeba uwzględnić?
Shopify może uprościć utrzymanie części środowiska, ale nie zwalnia z oceny sklepu. Szczególnie uważnie sprawdzaj motyw, aplikacje dodające elementy do strony oraz własne modyfikacje.
Motywy zgłaszane do Shopify Theme Store muszą spełnić wymóg średniego wyniku co najmniej 90 w Lighthouse Accessibility dla strony głównej, kolekcji i produktu na desktopie oraz mobile. Nie należy jednak utożsamiać tego wyniku z pełną zgodnością z WCAG 2.2 AA. Lighthouse wykrywa tylko część problemów możliwych do automatycznej oceny.
Na co zwrócić uwagę w sklepie Shopify?
- Czy warianty produktu są opisane zrozumiale i dają się wybrać klawiaturą?
- Czy filtr, sortowanie i szybki podgląd nie gubią fokusu po aktualizacji wyników?
- Czy aplikacje do opinii, rekomendacji, subskrypcji i promocji nie wstawiają pustych przycisków albo nieopisanych kontrolek?
- Czy po błędzie w koszyku użytkownik dowiaduje się, co poprawić i gdzie znajduje się problem?
- Czy proces zakupu został sprawdzony na rzeczywistych metodach płatności oraz dostawy używanych w sklepie?
Jeżeli działasz na Shopify, zobacz również szczegółowy materiał WCAGbot na Shopify: instalacja i test koszyka. Opisuje on wdrożenie funkcji wspierających dostępność oraz retest koszyka po instalacji.
Porównanie: WordPress czy Shopify pod kątem dostępności?
| Obszar | WordPress | Shopify | Co zrobić w praktyce? |
|---|---|---|---|
| Kontrola nad kodem | Zwykle bardzo duża, zależna od hostingu, motywu i wdrożenia. | Duża w warstwie motywu, ograniczona w komponentach zarządzanych przez platformę. | Ustal, które bariery zespół może naprawić samodzielnie. |
| Motyw | Jakość jest zróżnicowana; „accessibility-ready” nie jest WCAG AA. | Motywy Theme Store mają wymagania Lighthouse, lecz potrzebują testów manualnych. | Testuj wersję demonstracyjną na klawiaturze przed zakupem. |
| Dodatki | Wtyczki mogą zmieniać cały interfejs i wchodzić ze sobą w konflikt. | Aplikacje mogą wstrzykiwać komponenty do motywu i koszyka. | Włączaj dodatki pojedynczo i wykonuj test regresji. |
| Koszyk i płatność | Silnie zależne od WooCommerce, motywu, bramki płatności i konfiguracji. | Część procesu zależy od Shopify, ale motyw i integracje nadal wpływają na doświadczenie. | Testuj pełny zakup, a nie tylko kartę produktu. |
| Naprawy źródłowe | Najczęściej możliwe szeroko, ale wymagają kompetencji i kontroli jakości. | Możliwe w motywie i własnym kodzie; trudniejsze w obszarach platformowych. | Podziel listę błędów według właściciela problemu. |
WCAGbot Accessibility Path dla sklepu
Jak zastosować WCAGbot Accessibility Path?
WCAGbot Accessibility Path porządkuje pierwszy etap pracy nad dostępnością sklepu. Nie jest metodą certyfikacji ani zastępstwem audytu. Pomaga połączyć szybkie wsparcie dla użytkownika z planem trwałego usuwania barier.
- Wybierz ścieżki krytyczne. Zapisz adresy strony głównej, kategorii, produktu, koszyka, logowania, formularza i płatności.
- Sprawdź podstawy bez narzędzi. Przejdź ścieżkę samą klawiaturą. Zobacz, czy fokus jest widoczny, a kolejność logiczna.
- Dodaj funkcje wspierające dostępność. WCAGbot uruchamiasz jedną linią kodu. Użytkownik może skorzystać między innymi z kontrastu, powiększenia tekstu, interlinii, czytania treści, większego kursora, przewodnika do czytania i gotowych profili.
- Otwórz panel i przetestuj własny przykład. Zwiększ tekst, włącz kontrast, sprawdź przewodnik do czytania oraz zachowanie layoutu w koszyku. To doświadczeniowy test, który pomaga zauważyć część problemów interfejsu.
- Zapisz bariery wymagające naprawy źródłowej. Przykłady: brak etykiety pola, nieopisany przycisk, błędna hierarchia nagłówków, pułapka klawiaturowa, nieczytelny komunikat błędu lub niewłaściwie działający modal.
- Wykonaj retest po wdrożeniu zmian. Powtarzaj testy po aktualizacji motywu, aplikacji, wtyczki, bramki płatności i komponentów marketingowych.
Funkcje typograficzne warto sprawdzać na rzeczywistych kartach produktu, w filtrach i koszyku. Zobacz, jak wykonać taki test we wpisie Większy tekst, interlinia i odstępy: test layoutu.
Mini-scenariusz: sklep po zmianie motywu
Scenariusz ilustracyjny: sklep WooCommerce zmienia motyw przed sezonową kampanią. Zespół sprawdza wygląd strony na telefonie i komputerze, ale nie wykonuje testu klawiaturą. Po publikacji okazuje się, że fokus w filtrach kategorii jest niewidoczny, a przycisk zamknięcia popupu rabatowego nie ma nazwy dostępnej dla czytnika ekranu.
Rozsądny plan reakcji obejmuje trzy działania:
- tymczasowe ograniczenie popupu, jeśli blokuje obsługę sklepu;
- poprawę kontrastu fokusu i semantycznej nazwy przycisku w kodzie motywu lub dodatku;
- retetst kategorii, produktu, koszyka i formularza zapisu po wdrożeniu poprawki.
Jeśli budżet nie pozwala od razu na pełny zakres prac, warto świadomie ustalić kolejność. Pomocny może być materiał Widget dostępności czy audyt WCAG przy małym budżecie?. Widget może wspierać użytkownika od razu, ale nie naprawi nieopisanej kontrolki ani pułapki fokusu w motywie.
Jak zaplanować testy WordPressa i Shopify?
Zacznij od małego, powtarzalnego zestawu testów. Nie próbuj ocenić całego sklepu wyłącznie skanerem ani wyłącznie wizualnie.
- Przejdź najważniejszą ścieżkę zakupu klawiaturą bez myszy.
- Zweryfikuj nagłówki, linki, kontrast, teksty alternatywne i błędy formularza.
- Sprawdź zachowanie dynamicznych elementów: filtrów, modali, rozwijanych menu, koszyka bocznego i komunikatów statusu.
- Wykonaj podstawowy test czytnikiem ekranu na kluczowych widokach.
- Przypisz każdą barierę do właściciela: motyw, wtyczka, aplikacja, treść, integracja płatnicza lub kod własny.
- Po naprawie powtórz dokładnie ten sam scenariusz.
Instrukcję dla zespołu, który zaczyna od testu manualnego, znajdziesz w artykule Testy klawiaturą i czytnikiem ekranu: praktyczny plan. Dla e-commerce szczególnie ważna jest też Mapa dostępności sklepu: od produktu do kontaktu.
Mapa testu zakupu w sklepie
Co powinno trafić do briefu dla agencji lub developera?
W wymaganiach nie wpisuj ogólnego zdania „strona ma być zgodna z WCAG”. Opisz zakres i sposób odbioru. Wymagaj testu klawiaturą, przeglądu formularzy, kontroli komponentów dynamicznych oraz retestu po zmianach. Dla większego zakresu warto zlecić audyt WCAG i ustalić kryteria odbioru poprawek.
Gotową strukturę zamówienia omawia wpis Jak zamówić audyt WCAG: brief i kryteria odbioru. Jeżeli problem dotyczy przede wszystkim błędów przy finalizacji zakupu, przeczytaj także Dostępne komunikaty błędów w koszyku i płatności.
FAQ: dostępność WordPress i Shopify
Czy WordPress jest zgodny z WCAG?
Nie można przypisać zgodności z WCAG całej witrynie tylko dlatego, że działa na WordPressie. Oceny wymaga konkretna implementacja: motyw, wtyczki, WooCommerce, kod własny, treść oraz integracje.
Czy Shopify gwarantuje dostępność sklepu?
Nie. Shopify opisuje własne działania dotyczące dostępności platformy, ale sprzedawca nadal wybiera motyw, aplikacje, treści i customizacje. Te elementy mogą tworzyć bariery dla użytkowników.
Czy motyw „accessibility-ready” WordPress wystarczy?
Nie. To oznaczenie nie jest potwierdzeniem zgodności z WCAG AA. Motyw należy testować w realnej konfiguracji sklepu, razem z używanymi wtyczkami i treścią.
Czy wynik Lighthouse 90 oznacza zgodność z WCAG?
Nie. Wynik Lighthouse jest pomocnym wskaźnikiem automatycznych testów, lecz nie ocenia wszystkich kryteriów i problemów użyteczności. Konieczne są również testy manualne.
Co testować najpierw w sklepie internetowym?
Najpierw przetestuj ścieżkę, która prowadzi do zakupu: wyszukanie produktu, karta produktu, warianty, dodanie do koszyka, koszyk, formularze, płatność i potwierdzenie.
Czy można przetestować dostępność bez czytnika ekranu?
Można zacząć od testu klawiaturą, kontrastu, struktury nagłówków i formularzy. Nie zastąpi to jednak testu z czytnikiem ekranu ani oceny przez osoby korzystające z technologii asystujących.
Czy WCAGbot naprawia błędy motywu WordPress lub Shopify?
WCAGbot dodaje funkcje wspierające dostępność, takie jak tryby kontrastu, narzędzia typograficzne czy czytanie treści. Nie zastępuje napraw źródłowych błędów w kodzie, semantyce HTML, formularzach, kolejności fokusu i treści.
Jak sprawdzić, czy aplikacja Shopify lub wtyczka WordPress tworzy problem?
Wykonaj test przed i po jej uruchomieniu. Sprawdź szczególnie fokus, obsługę klawiaturą, nazwy przycisków, komunikaty dynamiczne, kontrast oraz zachowanie na telefonie.
Kiedy warto zamówić audyt WCAG?
Audyt warto zaplanować przed dużym redesignem, po migracji, przy rozbudowanym checkoutcie, po zgłoszeniach użytkowników albo gdy zespół potrzebuje uporządkowanej listy barier i kryteriów odbioru poprawek.
Podsumowanie
Wybór między WordPressem a Shopify powinien wynikać z modelu biznesowego, kompetencji zespołu i zakresu kontroli nad sklepem, nie z obietnicy automatycznej dostępności. W obu rozwiązaniach najwięcej daje regularny test ścieżki zakupowej, kontrola zmian oraz usuwanie barier w kodzie i treści.
Jeśli chcesz szybko udostępnić użytkownikom dodatkowe opcje kontrastu, czytania i dostosowania widoku, a jednocześnie rozpocząć uporządkowaną pracę nad barierami, Dodaj funkcje dostępności.
