Czwarty wpis z serii o budowie nexowork.pl. Sprzedajemy strony zgodne z WCAG, więc najpierw musieliśmy to zrobić u siebie. Pokazujemy, co znaleźliśmy, co poprawiliśmy i czego jeszcze nie sprawdziliśmy. Liczby pochodzą z naszych testów z listopada 2026 roku.
Dlaczego dostępność, skoro „u nas nikt nie ma problemu”?
Dostępność to nie tylko osoby niewidome. To także:
- osoby starsze, które powiększają tekst,
- ktoś, kto czyta stronę na telefonie w pełnym słońcu i potrzebuje mocnego kontrastu,
- osoby, które poruszają się po stronie klawiaturą zamiast myszką,
- osoby, którym przesuwające się animacje utrudniają czytanie.
Według badania WebAIM Million 2025 94,8% stron głównych z miliona najpopularniejszych witryn ma wykrywalne błędy dostępności. Od czerwca 2025 roku w Polsce obowiązuje też ustawa wdrażająca Europejski Akt o Dostępności (EAA), która obejmuje m.in. sklepy internetowe. Mikroprzedsiębiorstwa świadczące usługi są z niej zwolnione, ale klienci tego nie sprawdzają: po prostu wychodzą ze strony, z której nie da się korzystać.
Punkt wyjścia
Pierwszy pomiar zrobiliśmy testem Google Lighthouse (część PageSpeed), a potem dokładniejszym testem axe-core.
| Strona | Dostępność, telefon | Dostępność, komputer |
|---|---|---|
| nexowork.pl (przed poprawkami) | 92/100 | 96/100 |
| vetroarte.pl, nasza realizacja (przed poprawkami) | 93/100 | 97/100 |
Wynik 92 brzmi dobrze, ale Lighthouse sprawdza tylko część wymagań. Automatyczne testy wyłapują szacunkowo 30–40% problemów, resztę trzeba sprawdzić ręcznie. Dlatego połączyliśmy test axe-core 4.10.2 z testami klawiaturą i na najwęższym ekranie.
Co znaleźliśmy i co poprawiliśmy
| Obszar | Problem | Poprawka |
|---|---|---|
| Kontrast tekstu | ok. 40 miejsc: jasne końcówki gradientów pod białym tekstem, szare podpisy, jasnoturkusowe teksty | kolory z palety marki, przyciemnione tam, gdzie było za słabo |
| Fokus z klawiatury | ciemna obwódka znikała na ciemnym nagłówku | biało-fioletowa obwódka widoczna na każdym tle |
| Animacje (kryterium 2.2.2) | przesuwające się zrzuty i zmieniające się słowa bez końca | przycisk „Zatrzymaj animacje”, strona pamięta wybór |
| Kropki karuzel | pole kliknięcia 8 px | pole 24×24 px, wygląd bez zmian |
| Karuzele na telefonie | brak obsługi klawiaturą i opisu | przewijanie z klawiatury i opis dla czytnika |
| Pola formularzy | słabo widoczne ramki | kontrast ramek co najmniej 3:1 |
| Kalendarz rezerwacji | czytnik nie ogłaszał wyboru | ogłasza wybrany dzień i godzinę |
| Menu na telefonie | „Oferta” i „Więcej” bez informacji o stanie | przyciski z informacją „rozwinięte / zwinięte” |
| Szerokość 320 px | nagłówek wystawał o 4 px | mieści się bez przewijania w bok |
| Tabele we wpisach | przewijane palcem, ale nie klawiaturą | da się je przewinąć klawiaturą |
Kontrast: ok. 40 poprawek bez zmiany marki
To był największy blok pracy. Nasza paleta to granat, niebieski, fiolet i turkus. Problem pojawiał się na jasnych końcach gradientów, gdzie biały tekst tracił kontrast. Standardowe narzędzia sprawdzają kontrast do jednego koloru tła, a nie do gradientu, więc napisaliśmy własny test, który mierzy kontrast w najjaśniejszym punkcie gradientu pod tekstem.
Wymagany kontrast to 4,5:1 dla zwykłego tekstu i 3:1 dla dużego tekstu i elementów interfejsu. Każda poprawka to przyciemnienie koloru w tej samej tonacji, więc strona dalej wygląda jak NexoWork.
Pauza animacji: kryterium, o którym mało kto pamięta
WCAG wymaga, żeby ruch trwający dłużej niż 5 sekund dało się zatrzymać. U nas w hero przesuwały się zrzuty realizacji i zmieniało się słowo w nagłówku. Dodaliśmy:
- przycisk „Zatrzymaj animacje” w rogu hero, który zapamiętuje wybór na kolejnych wizytach,
- automatyczne zatrzymanie dla osób, które w systemie mają włączone „ogranicz ruch”,
- zatrzymanie tylko animacji ciągłych, a nie jednorazowych efektów pojawiania się sekcji.
Ten ostatni punkt to nasza wpadka: pierwsza wersja pauzy zatrzymywała wszystko, także animacje pojawiania się, przez co część sekcji zostawała niewidoczna. Poprawiona wersja dotyczy tylko animacji, które się zapętlają.
Kropki 8 px, które wyglądają tak samo
Kropki karuzeli na telefonie miały 8 px. Palec potrzebuje większego celu, a WCAG 2.2 wymaga co najmniej 24×24 px. Nie zmieniliśmy wyglądu kropek, tylko powiększyliśmy niewidoczne pole kliknięcia wokół nich. Projekt zostaje, a obsługa jest wygodniejsza.
Wynik
Test axe-core (reguły WCAG 2.2 AA) pokazuje 0 błędów na 10 typach stron. Sprawdziliśmy je na komputerze i na najwęższym telefonie (320 px):
| Typ strony | Komputer | Telefon 320 px |
|---|---|---|
| Strona główna | 0 błędów | 0 błędów |
| Kontakt | 0 | 0 |
| Umów konsultację (kalendarz) | 0 | 0 |
| Oferta | 0 | 0 |
| Strona pakietu | 0 | 0 |
| Nexo Core | 0 | 0 |
| Nexo Shield | 0 | 0 |
| O nas | 0 | 0 |
| Blog | 0 | 0 |
| Wpis na blogu | 0 | 0 |
Już wcześniej działały: link „Przejdź do treści”, język strony pl-PL, etykiety pól formularzy i poprawna struktura nagłówków.
Czego nie sprawdziliśmy (i mówimy o tym otwarcie)
Zero błędów w automacie to nie to samo co pełna zgodność. Dlatego w naszej deklaracji dostępności status to „częściowo zgodna”, a nie „w pełni zgodna”. Otwarcie wymieniamy braki:
- brak testu z czytnikami ekranu NVDA i VoiceOver,
- liczby, które animują się od zera w statystykach,
- tekst na zrzutach stron klientów, którego czytnik nie odczyta,
- niedokończone treści, czyli pola z danymi firmy do uzupełnienia.
Deklaracja zawiera też 10 udogodnień (klawiatura, widoczny fokus, kontrast, pauza animacji, 320 px, powiększenie 200%, kalendarz z klawiatury i inne) oraz kontakt w sprawie dostępności z odpowiedzią w ciągu 7 dni roboczych.
Ile to kosztuje przy nowej stronie, a ile przy starej?
Najtańsza dostępność to ta zaplanowana od początku. Przy nowej stronie kontrast, fokus, etykiety i obsługa klawiatury to po prostu dobrze napisany kod. Przy gotowej stronie każdą rzecz trzeba znaleźć, poprawić i sprawdzić, czy nie zepsuła wyglądu. U nas sama poprawka kontrastu objęła ok. 40 miejsc, a każde trzeba było sprawdzić na komputerze i na telefonie.
Więcej o obowiązkach sklepów piszemy w poradniku EAA i WCAG 2.2: co musi zrobić sklep internetowy. Inne części tej serii: audyt SEO i przyspieszenie serwera.
Najczęstsze pytania
Czy wynik 100/100 w Lighthouse oznacza zgodność z WCAG?
Nie. Lighthouse sprawdza tylko część wymagań. Strona może mieć 100 punktów i dalej być trudna w obsłudze klawiaturą albo czytnikiem ekranu. Potrzebne są testy ręczne.
Czy moja firma musi spełniać WCAG?
Obowiązek z ustawy o dostępności dotyczy m.in. sklepów internetowych i usług dla konsumentów, ale mikroprzedsiębiorstwa świadczące usługi są zwolnione. Szczegóły warto potwierdzić z prawnikiem. Niezależnie od obowiązku dostępna strona jest po prostu wygodniejsza dla wszystkich.
Czy dostosowanie do WCAG zmieni wygląd strony?
Zwykle minimalnie. U nas kolory zostały w palecie marki, tylko trochę ciemniejsze tam, gdzie kontrast był za słaby. Kropki karuzel wyglądają identycznie, a zmieniło się tylko niewidoczne pole kliknięcia.
Jak sprawdzić dostępność własnej strony?
Na start zainstaluj w Chrome rozszerzenie axe DevTools i przejdź stronę samą klawiaturą (Tab, Enter, Esc). Jeśli zgubisz miejsce, w którym jesteś, albo nie da się czegoś kliknąć, to sygnał, że strona wymaga poprawek.
Chcesz wiedzieć, ile barier ma Twoja strona? Umów bezpłatną rozmowę: zrobimy test dostępności i pokażemy wyniki.