Najważniejsze wnioski
- Widget i audyt rozwiązują różne problemy.
- Funkcje wspierające mogą od razu poprawić komfort części użytkowników.
- Błędy w semantyce, formularzach i procesach zwykle wymagają naprawy w źródle.
- Najlepszy plan łączy szybkie wsparcie, diagnozę, naprawy i monitoring.
Wokół widgetów dostępności narosło sporo nieporozumień, i to w obie strony. Jedni sprzedają je jako „zgodność w jednym kliknięciu”, co jest po prostu nieprawdą. Drudzy odrzucają je w całości, co również jest uproszczeniem, bo część użytkowników realnie korzysta z możliwości dopasowania prezentacji strony.
Ten tekst rozdziela dwie rzeczy, które łatwo pomylić: funkcje wspierające użytkownika i zgodność serwisu z wytycznymi. To nie są konkurencyjne rozwiązania tego samego problemu. To odpowiedzi na dwa różne problemy.
Czym jest zgodność z WCAG
WCAG to zestaw testowalnych kryteriów sukcesu dla treści internetowych. Zgodności nie orzeka się dla pojedynczego elementu ani dla widgetu — orzeka się ją dla konkretnych stron i procesów, na wskazanym poziomie (A, AA lub AAA). Ocena obejmuje strukturę dokumentu, alternatywy tekstowe, obsługę klawiaturą, komunikaty błędów, kontrast, nazwy dostępne kontrolek i wiele innych aspektów, które są wpisane w kod i treść serwisu.
W kontekście europejskim technicznym punktem odniesienia jest norma EN 301 549. W wersji V3.2.1 z marca 2021 r. jej rozdział 9, dotyczący treści webowych, odwołuje się do WCAG 2.1 na poziomie AA. Więcej o wzajemnych relacjach tych dokumentów znajdziesz w tekście o różnicach między WCAG 2.1, WCAG 2.2 i EN 301 549.
Co realnie robi widget
Widget działa w przeglądarce i zmienia sposób prezentacji istniejącej strony. Typowy zakres to zwiększenie tekstu, zmiana kontrastu i nasycenia, podświetlenie linków, powiększenie kursora, zatrzymanie animacji, prowadnica czytania oraz odczyt zaznaczonego fragmentu. Szczegółowy przegląd tych funkcji opisujemy w tekście o kontraście, tekście i czytaniu treści w WCAGbot.
To realna wartość dla użytkownika, który ma trudność z odczytaniem drobnego druku albo potrzebuje wyciszyć ruch na stronie. Jest to jednak wartość ograniczona do warstwy prezentacji.
Gdzie przebiega granica
Najprostszy test: zapytaj, czy problem da się rozwiązać zmianą wyglądu. Jeżeli tak — widget może pomóc. Jeżeli nie — potrzebna jest zmiana w kodzie albo w treści.
| Problem | Widget | Naprawa źródłowa |
|---|---|---|
| Za mały tekst dla użytkownika | Pomaga od razu | Warto poprawić domyślną typografię |
| Zbyt niski kontrast tekstu | Pomaga w trybie kontrastowym | Konieczna korekta palety |
| Pole formularza bez etykiety | Nie rozwiązuje | Konieczna zmiana w kodzie |
| Zdjęcie produktu bez opisu alternatywnego | Nie rozwiązuje | Konieczne uzupełnienie treści |
| Pułapka fokusu w oknie modalnym | Nie rozwiązuje | Konieczna zmiana w kodzie |
| Błąd walidacji sygnalizowany samym kolorem | Nie rozwiązuje | Konieczny komunikat tekstowy |
| Rozpraszające animacje | Pomaga | Warto uszanować preferencję ograniczonego ruchu |
Zwróć uwagę na strukturę tej tabeli. Widget wygrywa tam, gdzie problemem jest sposób pokazania informacji. Przegrywa wszędzie tam, gdzie problemem jest brak informacji — brakującej etykiety, brakującego opisu, brakującego komunikatu. Czego nie ma w dokumencie, tego żadna warstwa prezentacji nie doda.
Widget zmienia to, jak wygląda strona. Audyt zmienia to, czym strona jest. Tylko drugie z tych zdań opisuje zgodność.
Dlaczego obietnica „zgodności jednym kliknięciem” jest ryzykowna
Deklaracja zgodności, która nie ma pokrycia w stanie serwisu, tworzy trzy rodzaje ryzyka naraz. Po pierwsze, ryzyko wobec użytkownika, który ufa deklaracji i trafia na barierę. Po drugie, ryzyko reputacyjne — takie zgłoszenia trafiają do mediów społecznościowych szybciej niż do działu obsługi. Po trzecie, ryzyko wobec organu nadzoru rynku, dla którego liczy się rzeczywisty stan usługi, a nie treść banera.
Uczciwa komunikacja brzmi inaczej: „udostępniamy funkcje wspierające, prowadzimy audyt i publikujemy plan napraw”. To zdanie jest mniej efektowne i znacznie łatwiejsze do obrony.
Scenariusz: dwa sklepy, ten sam widget
Rozważmy dwa sklepy, które tego samego dnia instalują ten sam panel. Pierwszy traktuje instalację jako koniec projektu. Drugi traktuje ją jako początek: uruchamia panel, a równolegle zamawia przegląd ścieżki zakupowej, dostaje listę dwudziestu kilku problemów, naprawia najpierw formularz zamówienia i etykiety pól, potem kontrast przycisków, a na końcu kolejność fokusu w oknie koszyka.
Po pół roku pierwszy sklep ma dokładnie to, co miał na starcie, oraz baner sugerujący zgodność. Drugi ma serwis, który realnie da się obsłużyć klawiaturą i czytnikiem ekranu — i ten sam widget jako dodatkowe udogodnienie. Różnicy nie zrobił produkt. Zrobiła ją decyzja o tym, co dzieje się po jego wdrożeniu.
Sensowna kolejność działań
Sprawdza się układ czterech kroków: włącz funkcje wspierające, zdiagnozuj stan faktyczny, napraw to, co blokuje kluczowe procesy, a potem monitoruj po każdej większej zmianie. Pierwszy krok jest najszybszy i opisujemy go w tekście o instalacji WCAGbot w pięć minut. Drugi i trzeci wymagają czasu — dla sklepów punktem startu jest checklista dostępności sklepu internetowego. Kontekst obowiązków dla handlu elektronicznego znajdziesz w przewodniku po Polskim Akcie o Dostępności.
Co naprawia warstwa prezentacji, a co kod
Jak czytać obietnice dostawców
Rynek narzędzi dostępnościowych jest pełen sformułowań, które brzmią podobnie, a znaczą co innego. Kilka zwrotów warto umieć rozkodować, zanim trafią do umowy albo na stronę sprzedażową.
„Zgodność z WCAG w jednym kliknięciu” — deklaracja nie do obrony, bo zgodność ocenia się dla stron i procesów, a nie dla wtyczki. „Automatyczna naprawa dostępności” — zwykle oznacza podstawianie brakujących atrybutów przez skrypt; poprawia wynik testu automatycznego, ale nie gwarantuje sensownej treści opisu. „Certyfikat dostępności” — warto sprawdzić, kto go wystawia, na jakiej podstawie i czy dotyczy Twojego serwisu, czy samego narzędzia.
Uczciwy dostawca chętnie odpowie na pytanie „czego wasze rozwiązanie nie naprawia”. Brak odpowiedzi na to pytanie jest odpowiedzią sam w sobie.
Koszt: co się skaluje, a co nie
Funkcje wspierające mają koszt niemal stały niezależnie od wielkości serwisu — jedna instalacja obsługuje zarówno stronę z dziesięcioma podstronami, jak i sklep z dziesięcioma tysiącami produktów. To ich największa zaleta ekonomiczna.
Naprawy źródłowe skalują się inaczej: rosną wraz z liczbą unikalnych szablonów, integracji i wariantów procesu. Dlatego rozsądny budżet liczy się nie od liczby podstron, lecz od liczby różnych typów widoków — karta produktu, koszyk, checkout, konto klienta, listing. Naprawa jednego szablonu poprawia wszystkie strony, które z niego korzystają.
Z tego wynika praktyczny wniosek dla planowania: najpierw policz szablony, potem szacuj koszt. Sklep z tysiącem produktów i pięcioma szablonami jest tańszy do naprawy niż serwis ze stu stronami zbudowanymi ręcznie, każda inaczej. Szczegółową listę miejsc do sprawdzenia znajdziesz w checkliście dostępności sklepu.
Podsumowanie w jednym zdaniu
Widget i audyt nie konkurują ze sobą, bo odpowiadają na różne pytania: pierwszy na to, jak użytkownik może dopasować stronę do siebie tu i teraz, drugi na to, czy strona w ogóle daje się obsłużyć. Sklep, który uruchamia funkcje wspierające i równolegle naprawia bariery w kodzie, po kilku miesiącach ma jedno i drugie. Sklep, który zatrzymuje się na pierwszym kroku, ma tylko poczucie, że temat został odhaczony.
Najczęstsze pytania
Czy widget dostępności jest niezgodny z WCAG?
Sam widget nie jest ani zgodny, ani niezgodny — zgodność ocenia się dla strony i procesu, a nie dla pojedynczego komponentu. Istotne jest natomiast, żeby panel sam był obsługiwalny klawiaturą i nie tworzył nowych barier.
Czy instalacja widgetu wystarczy do spełnienia wymagań ustawowych?
Nie. Wymagania odnoszą się do usługi jako całości. Widget może być jednym z elementów, ale nie zastępuje audytu, napraw w kodzie ani obowiązków informacyjnych.
Czy warto instalować widget, skoro nie daje zgodności?
Tak, jeżeli traktujesz go jako natychmiastowe wsparcie dla części użytkowników, a nie jako zamiennik prac źródłowych. Wartość pojawia się od pierwszego dnia, koszt wdrożenia jest niski.
Co powinien zawierać audyt dostępności?
Testy manualne z klawiaturą i czytnikiem ekranu, weryfikację kontrastu, sprawdzenie formularzy i komunikatów błędów, przegląd struktury nagłówków oraz opis wyników z priorytetami napraw. Testy automatyczne są uzupełnieniem, nie podstawą.
Czy audyt trzeba powtarzać?
Tak, po każdej istotnej zmianie: nowym motywie, nowej bramce płatności, przebudowie koszyka albo dodaniu aplikacji zewnętrznej. Dostępność potrafi się zepsuć jedną aktualizacją.
Kto odpowiada za dostępność sklepu — agencja czy właściciel?
Wobec użytkownika i organu nadzoru odpowiada podmiot świadczący usługę. Umowa z agencją może rozkładać zadania i odpowiedzialność kontraktową, ale nie przenosi obowiązku wynikającego z przepisów.
Czy testy automatyczne wystarczą do oceny?
Nie. Narzędzia automatyczne wykrywają część problemów, głównie technicznych, ale nie ocenią sensowności opisu alternatywnego, logiki kolejności fokusu ani zrozumiałości komunikatu błędu.
Od czego zacząć, gdy budżet jest ograniczony?
Od jednej ścieżki, która generuje przychód: wyszukanie produktu, koszyk, płatność, potwierdzenie. Naprawa barier na tej ścieżce daje największy efekt na złotówkę.
