Wtyczki nie zapewniają dostępności, lecz tworzą nowe problemy: analiza

Termin minął z końcem czerwca 2025 roku: wiele stron internetowych musi być teraz dostępnych cyfrowo. Wiele agencji oferuje dostępność przez wtyczkę, bazującą na określonych narzędziach, które mają uczynić stronę dostępną praktycznie jednym kliknięciem. Brzmi kusząco: jedno kliknięcie, jeden overlay i wszystko jest zgodne z prawem. Rzeczywistość wygląda jednak inaczej. Kto przyjrzy się bliżej, zauważy: te narzędzia rozwiązują tylko niewielką część problemów, tworzą za to nowe.

Niniejsza analiza zawiera w skrócie następujące wnioski:

• Najważniejsze na początek: wtyczki dostępności nie są w stanie sprawić, aby Twoja strona internetowa była zgodna z technicznymi wymaganiami WCAG.
• Wtyczki i overlaye dostępności są problematyczne dla PageSpeed i Core Web Vitals Twoich stron internetowych.
• Tego rodzaju rozwiązania tworzą problemy w technicznym SEO, co może wywrzeć presję na Twoje rankingi … i zapewne wywrze.
• User experience Twojej strony spada w wyniku wolniejszego działania witryny, co oznacza negatywne sygnały użytkowników dla Google.
• Osoby z niepełnosprawnościami w większości odrzucają overlaye dostępności oparte na takich wtyczkach.
• Obiecywane bezpieczeństwo prawne to śmiała teza, która gdzie indziej doprowadziła już do ogromnych kar finansowych.

Wniosek: wtyczki i overlaye dostępności, mimo kuszących obietnic szybkich rozwiązań, nie stanowią realnej pomocy dla osób z niepełnosprawnościami i dają fałszywe poczucie bezpieczeństwa, za które ostatecznie płaci się drogo (oprócz miesięcznych kosztów) gorszą wydajnością i niższym user experience, co ma niemałe znaczenie dla SEO i rankingów. Google chce zapewniać użytkownikom najlepsze doświadczenia. Na stronach z tymi wtyczkami Google już tego nie znajdzie.

Iluzja natychmiastowej dostępności

Najpóźniej teraz, wraz z wejściem w życie ustawy BFSG, dostępność cyfrowa stron internetowych przekształciła się z luźnego rozważania w podstawową konieczność dla firm zatrudniających co najmniej dziesięciu pracowników lub osiągających 2 mln obrotu, które oferują usługi elektroniczne na swojej stronie internetowej. Aby zakwalifikować się jako usługa elektroniczna, wystarczy już umieszczony formularz kontaktowy służący nawiązaniu współpracy lub umówieniu terminu. Również my jako agencja ds. dostępności cyfrowej w maju, czerwcu i także teraz w lipcu uczyniliśmy strony internetowe wielu klientów dostępnymi — na poziomie kodu, nie za pomocą wtyczek. Nie chodziło wyłącznie o etyczną inkluzję. Jeśli mamy być szczerzy, firmom zależy przede wszystkim na przestrzeganiu przepisów prawa. Bez nowej ustawy raczej niewielu klientów zdecydowałoby się na optymalizację pod kątem dostępności. Tyle szczerości trzeba mieć. Ponieważ firmy są pod presją działania, zanim zaczną grozić dotkliwe kary, pokusa pozornie bezwysiłkowych rozwiązań typu „jedna linijka kodu” jest niezwykle silna: witamy w potiomkinowskiej wiosce wtyczek i overlayów dostępności, które przedstawiają się jako rozwiązanie, a w istocie jedynie maskują istniejące bariery, tworząc przy tym nowe problemy.

Narzędzia te są często prezentowane jako natychmiastowe, w pełni automatyczne, a czasem także wspierane przez AI rozwiązania problemów dostępności cyfrowej. Obiecują natychmiastową zgodność i bezwysiłkową inkluzywność, oferując złudny skrót omijający złożoność prawdziwej dostępności. Ten marketing często posługuje się hasłami takimi jak „kompleksowe rozwiązanie dostępności stron internetowych” czy „szybko & łatwo , przez co powstaje wrażenie magicznego rozwiązania.

Tak na przykład strona internetowa jednego z dostawców prezentuje wtyczkę dostępności, która jest oferowana klientom również za pośrednictwem Händlerbund: zgodność z BSFG jednym kliknięciem.

Oto landing page Händlerbund z pakietem dostępności, gdzie praktycznie wykorzystywana jest także sama wtyczka (zobacz niebieską ikonę po lewej na dole): „prawnie zabezpieczona … technicznie dostępna obecność w sieci”.

Krótkie wyjaśnienie: my również jako firma jesteśmy klientem Händlerbund od 2018 roku i cenimy usługę tekstów prawnych oraz świadczenia związane z bezpieczeństwem prawnym dla firm, stron internetowych i sklepów. Poleciliśmy też Händlerbund kilku naszym klientom … z przekonania.

Tej wtyczki ani podobnych overlayów dostępności nigdy byśmy jednak nie zastosowali ani nie zainstalowali u naszych klientów. Ten raport wykaże, że te rozwiązania typu „szybko & łatwo” są nie tylko niewystarczające, lecz wręcz aktywnie szkodliwe dla SEO i PageSpeed, a przy tym oddalają strony internetowe od rzeczywistego rozwiązania prawdziwych problemów z dostępnością. Tak rozbudowane wtyczki dostępności wprowadzają natomiast szereg nowych problemów, które znacząco pogarszają wydajność strony, nie zapewniają realnej ochrony prawnej i ostatecznie utrudniają prawdziwą inkluzję użytkowników z niepełnosprawnościami.

Wykorzystane zostaną rzeczywiste dane sklepu internetowego Deutsche See, aby dokładnie zobrazować, jak te narzędzia podważają swój własny deklarowany cel. Analiza pokaże, dlaczego głębsze, oparte na kodzie podejście z dodatkowymi testami manualnymi jest jedyną trwałą, etyczną i prawnie ugruntowaną drogą do osiągnięcia kompleksowej dostępności stron internetowych.

Spadek wydajności: wgląd w dane PageSpeed

Gdy jako użytkownik wchodzisz do sklepu Deutsche See, znajdziesz po prawej stronie ekranu małą ikonę, która pozwala wyświetlić funkcje dostępności. Załadowane są one już wcześniej, niezależnie od tego, czy widzisz panel, czy nie. Klikasz na nią i panel się rozwija. Spójrz na niebieski pasek przewijania po prawej … użytkownikowi oferuje się mnóstwo funkcji, gdy przewija panel dalej w dół.

Zrozumienie Core Web Vitals (CWV): podstawa doświadczenia użytkownika

Core Web Vitals (CWV) Google to zestaw metryk, które mierzą rzeczywiste doświadczenie użytkownika i bezpośrednio wpływają na rankingi wyszukiwarek oraz zaangażowanie użytkowników. Metryki te obejmują Largest Contentful Paint (LCP), który ocenia wydajność ładowania; Interaction to Next Paint (INP) , który mierzy interaktywność, oraz Cumulative Layout Shift (CLS), który kwantyfikuje stabilność wizualną.

Oto wynik analizy PageSpeed Insights dla strony głównej sklepu: Core Web Vitals nie zostały zaliczone z powodu kumulatywnych przesunięć layoutu. Nas również przez kilka miesięcy dręczyły problemy z CLS, które udało nam się naprawić tylko dużym nakładem pracy.

Osiągnięcie najniższych, czyli najlepszych wartości CWV jest kluczowe dla szybkiej, responsywnej i wizualnie stabilnej strony internetowej, ponieważ wpływa to na zaangażowanie użytkowników i widoczność Twojej witryny w wynikach wyszukiwania. Core Web Vitals są oficjalnym czynnikiem rankingowym Google i były częścią aktualizacji Page Experience w 2021 roku.

Jak wtyczki dostępności stają się wąskim gardłem wydajności

Overlaye dostępności są zazwyczaj implementowane jako zewnętrzne pliki JavaScript (third party), które są dynamicznie wstrzykiwane w istniejący kod strony internetowej. Ta „nakładkowa” metodyka, zamiast prawidłowej integracji w kodzie, z natury prowadzi do znacznej objętości i złożoności. Jeśli przyjrzysz się bogactwu funkcji tego rodzaju wtyczek, możesz sobie wyobrazić, jak dużo tego kodu jest wstrzykiwane.

Wtyczki te wprowadzają znaczną ilość dodatkowego JavaScriptu i CSS, którą przeglądarka musi pobrać, sparsować i wykonać, zanim strona zostanie w pełni wyrenderowana. A na przykładzie Deutsche See widzimy, że kod jest ładowany, jeszcze zanim ikona zostanie w ogóle kliknięta. Kod jest więc obecny już przy pierwszym ładowaniu strony. A tak wygląda wynik testu PageSpeed dla wersji mobilnej:

Nie dość, że mobilny PageSpeed z wynikiem 37 jest szczególnie fatalny, to znamiennie Google przyznaje stronie w kategorii Accessibility również tylko umiarkowane 72.

Na desktopie z reguły każda strona internetowa ma dobry wynik PageSpeed. Zielony to standard, żółty jest już niemal rzadkością. A jednak Deutsche See to „osiągnęło”. Smutny widok. A wartość dla Accessibility spadła jeszcze niżej..

Wtyczka dostępności dodaje „niepotrzebne warstwy” i tworzy ociężałe skrypty oraz zależności od dostawców zewnętrznych, co bezpośrednio przyczynia się do wydłużenia czasów ładowania. Główny wątek przeglądarki odpowiada za krytyczne zadania, takie jak parsowanie HTML, stosowanie stylów i wykonywanie JavaScriptu. Overlaye często monopolizują lub blokują ten główny wątek, co znacznie opóźnia renderowanie widocznych treści i utrudnia interaktywność. Dynamiczne wstrzykiwanie licznych dodatkowych elementów i stylów może prowadzić do nadmiernego rozmiaru DOM. To, w połączeniu z dużymi rozmiarami plików zasobów wtyczki, skutkuje ogromnymi obciążeniami sieciowymi, co dodatkowo pogłębia wolne ładowanie stron, zwłaszcza u użytkowników z wolniejszymi łączami lub na urządzeniach mobilnych.

Na liście zaleceń dotyczących usunięcia tych problemów w raporcie PageSpeed Insights oznaczyłem niebieską ikoną miejsca, w których raport diagnostyczny faktycznie bezpośrednio wymienia z nazwy skrypty wtyczki dostępności jako część problemu.

Techniczna architektura tego overlaya dostępności prowadzi bezpośrednio do pogorszenia wydajności ze wszystkimi wadami dla user experience i SEO. Tego rodzaju overlaye działają poprzez wstrzykiwanie dużych ilości JavaScriptu i CSS w istniejącą strukturę strony internetowej. To wstrzykiwanie zwiększa całkowitą ilość przesyłanych danych (obciążenie sieciowe) i dodaje do Document Object Model (rozmiar DOM) liczne elementy. Dochodzi do tego dodatkowy problem: wraz z tymi skryptami przenoszona jest także masa niepotrzebnego kodu, którego nie powinno tam być wcale albo jeszcze nie w tym momencie.

Oto analiza po rozwinięciu sekcji „Reduced unused CSS” i „Reduced unused JavaScript”.

Wtyczka dostępności ładuje przy wejściu na stronę duży pakiet JavaScriptu (950 KiB), nawet jeśli panel nie jest jeszcze w ogóle używany. Dopiero po kliknięciu niebieskiej ikony panel zostaje aktywowany. I dopiero wtedy wiele funkcji faktycznie wchodzi do gry. Lepsze rozwiązanie wyglądałoby tak, że lekki JavaScript inicjalizowałby tylko ikonę. A dopiero po kliknięciu ładowany byłby on demand pełny panel + funkcjonalność

Tutaj wygląda to inaczej: aby przeglądarka mogła wyrenderować stronę przy jej otwarciu, musi przetworzyć i wykonać nowo wstrzyknięty, często niezoptymalizowany, zewnętrzny kod wtyczki dostępności. To intensywne przetwarzanie prowadzi bezpośrednio do wydłużonego czasu wykonywania JavaScriptu i większego obciążenia głównego wątku. To absolutnie krytyczne czynniki dla Core Web Vitals.

PageSpeed Insights wykazuje bardzo słabe wartości wydajności, z negatywnym efektem, który jest jednoznacznie przypisywany także zastosowanej wtyczce dostępności. Czy tylko na deutschesee.de jest tak źle, a inni klienci rozwiązali to lepiej? Przyjrzyjmy się kilku kolejnym stronom firmowym korzystającym z wtyczki bfw – od lewej do prawej: trelino.com, hb-marketplace.com (od Händlerbund), christopeit-sport.com i ottowildegrillers.com.

Wartości są konsekwentnie w czerwonej strefie. Żadna strona nie spełnia Core Web Vitals. Nie tylko wtyczka odpowiada za te negatywne wyniki wydajności. Wszystkie badane strony mają także inne niedociągnięcia, które stoją na przeszkodzie optymalnym wartościom PageSpeed. Ale overlay dodatkowo zaciąga hamulec ręczny. Wskazówki diagnostyczne PageSpeed Insights są bezpośrednim potwierdzeniem teoretycznych problemów z wydajnością, które wiążą się z overlayami dostępności. Te konkretne dane pokazują, że wtyczki te aktywnie podkopują kluczowe metryki wydajności strony, co prowadzi do mierzalnych negatywnych skutków dla doświadczenia użytkownika, SEO i potencjalnie współczynników konwersji.

Podstawowej funkcjonalności wtyczki służącej lepszemu odbiorowi treści przez osoby z niepełnosprawnościami wcale tutaj nie kwestionuję, ale

• … cały kod (tutaj: 1,2 MB tylko dla wtyczki … absolutny performance killer) jest mimo to ładowany w całości, jeszcze zanim użytkownik cokolwiek zrobi.
• … wielu użytkowników w ogóle nie korzysta z panelu. Kod jest więc niepotrzebnym balastem.
• … LCP (Largest Contentful Paint) jako ważna metryka Core Web Vitals cierpi, ponieważ JS i CSS blokują lub opóźniają proces renderowania.
• … nie ma lazy loadingu, nie ma code splittingu, nie ma dynamicznego doładowywania.

Podsumowując, z technicznego punktu widzenia wtyczka wygląda jak overkill. Dodaje mnóstwo balastu, przy czym nie widać, które prawdziwe funkcje dostępności są z tego w ogóle sensownie wykorzystywane.

Jak myląca jest w tym kontekście autoreklama dostawcy wtyczki na jego stronie internetowej z rzekomymi korzyściami z zastosowania narzędzia:

• Lepszy zasięg i SEO: dostępne strony rankują lepiej.
• Lepsze doświadczenie użytkownika: dla wszystkich odwiedzających – niezależnie od ograniczeń.

Utrata wydajności spowodowana zastosowanym narzędziem dostępności jest tak ogromna, że user experience odczuwalnie się pogarsza – z przewidywalnymi konsekwencjami dla rankingów. Pozostaje mieć nadzieję, że osoby odpowiedzialne za SEO w Deutsche See & Co. nie będą szukać przyczyny wyłącznie w szeroko obecnie dyskutowanych AI Overviews, które od momentu wdrożenia powodują spadki ruchu na wielu stronach, lecz dostrzegą także bezpośredni związek między technicznym narzutem a utratą widoczności.

Dylemat zgodności: dlaczego overlaye dostępności zawodzą przy prawdziwej inkluzji

Ograniczony zakres automatycznych poprawek: plaster, a nie lekarstwo

Obietnica „w pełni automatycznego” rozwiązania dostępności to niebezpieczne nieporozumienie. Zautomatyzowane narzędzia i overlaye są z natury ograniczone i potrafią wykryć jedynie ułamek rzeczywistych problemów z dostępnością.

Narzędzia te koncentrują się głównie na powierzchownych zmianach, takich jak zmiana kolorów czy dostosowanie rozmiaru tekstu. To i tak funkcje, którymi użytkownicy z niepełnosprawnościami często sterują już poprzez swój system operacyjny lub ustawienia przeglądarki. Kluczowe jest to, że overlaye nie są w stanie naprawić leżących u podstaw problemów strukturalnych, zakotwiczonych w HTML, CSS i rolach ARIA strony internetowej. Nie potrafią skutecznie usunąć złożonych problemów, takich jak nieprawidłowe struktury nagłówków, brakujące lub błędne etykiety ARIA czy dostarczanie naprawdę treściwego tekstu alternatywnego dla obrazów, ponieważ brakuje im ludzkiego kontekstu i zdolności interpretacji, które są do tego niezbędne.

Overlaye usuwają objawy, a nie przyczyny. Prawdziwa dostępność cyfrowa jest głęboko zakorzeniona w semantycznej strukturze i logicznym przepływie kodu strony internetowej, a nie tylko w jej wizualnej prezentacji. Overlaye z założenia wstrzykują warstwę kodu ponad istniejącą stronę, zamiast modyfikować rdzeń HTML, CSS i JavaScript. Oznacza to, że mogą wprowadzać powierzchowne zmiany (np. korekty kontrastu), ale nie są w stanie naprawić fundamentalnych błędów strukturalnych, takich jak nieprawidłowe hierarchie nagłówków, nielogiczna kolejność czytania czy problemy z treściami dynamicznymi, które wymagają bezpośredniej korekty w kodzie.

Oto analiza deutschesee.de wykonana przez crawler OnPage SEOBILITY z niewielkim wycinkiem nieprawidłowości:

Jak więc narzędzie accessibility rozwiązuje problemy z nagłówkami i strukturą hierarchiczną? Co wtyczka robi z brakującymi atrybutami alt przy obrazach? Nic z tego nie jest rozwiązywane przez wtyczkę, w przeciwnym razie crawler nie wychwyciłby tych błędów. Co gorsza: sama wtyczka dostarcza obraz bez atrybutu alt, co widać na poniższym zrzucie ekranu, gdzie PageSpeed Insights dla strony głównej sklepu nie znajduje tekstu alternatywnego przy obrazie popupu i przy logo wtyczki.

To ograniczenie oznacza, że jedynie „łatają” widoczne objawy, podczas gdy przeważająca większość złożonych problemów z dostępnością pozostaje nierozwiązana. Tworzy to fałszywe poczucie bezpieczeństwa i prowadzi do czegoś, co można nazwać pokazem zgodności. To pozór konformności bez rzeczywistego spełniania wymogów.

Brak dostępności przy osadzonych wideo, iFrame’ach czy plikach PDF

Deutsche See pisze o tym sama w deklaracji dostępności i bardzo dobrze podsumowuje tym samym kolejne obszary, w których wtyczka dostępności nie oferuje żadnej pomocy.

Pomimo naszych starań wymienione poniżej treści nie są dostępne cyfrowo:

• Dokumenty PDF: niektóre z naszych dokumentów PDF nie są dostępne cyfrowo. Staramy się w krótkim czasie udostępnić dostosowaną wersję lub dostępne alternatywy. Jeśli potrzebują Państwo konkretnego pliku PDF od nas, który dotychczas nie jest dostępny cyfrowo, prosimy o informację.
• Wideo: niektóre z naszych osadzonych materiałów wideo nie mają obecnie napisów. Staramy się w krótkim czasie opatrzyć napisami wszystkie wideo.
• Obrazy bez tekstu alternatywnego: niektóre obrazy na stronie internetowej nie mają tekstu alternatywnego. Staramy się o szybką aktualizację.
• iFrame: części treści naszej strony internetowej są z przyczyn technicznych osadzone przez iFrame i dlatego nie są dostępne cyfrowo.

O obrazach bez tekstów alt powiedziano już wystarczająco dużo (zobacz także powyżej). Również dostawcy platform rezerwacyjnych, którzy poprzez iFrame lub oparte na API widgety rezerwacyjne dla stron hoteli, apartamentów wakacyjnych czy łodzi, muszą podjąć działania, aby nie generować problemów u swoich klientów.

Wideo powinny otrzymać napisy lub transkrypcje. Jest to problem zawsze wtedy, gdy wideo nie jest osadzone np. przez YouTube, gdzie napisy można po prostu włączyć.

Pliki PDF również powinny być dostępne cyfrowo, co stanowi problem, gdy plików PDF jest wiele. My także dla kilku klientów uczyniliśmy zintegrowane na stronie pliki PDF dostępnymi. Nakład czasu był, szczerze mówiąc, wyższy niż oczekiwano. Pliki PDF można zresztą testować tym checkerem dostępności PDF.

Zakłócanie technologii asystujących i doświadczenia użytkownika

Krytycznym problemem jest to, że overlaye dostępności często zakłócają technologie asystujące (AT), które rzekomo mają wspierać, takie jak czytniki ekranu, narzędzia nawigacji klawiaturowej i lupy ekranowe.

Użytkownicy z niepełnosprawnościami starannie konfigurują swoje urządzenia i AT, aby odpowiadały ich specyficznym potrzebom. Overlaye mogą nadpisywać te spersonalizowane ustawienia, zmuszając tym samym użytkowników do dostosowywania się na każdej stronie do nieznanego systemu. Prowadzi to do fatalnego user experience i ostatecznie czyni strony internetowe bardziej frustrującymi i mniej użytecznymi. Społeczność osób z niepełnosprawnościami w przeważającej mierze wypowiedziała się przeciwko overlayom. Ankieta WebAIM wykazała, że 72% użytkowników z niepełnosprawnościami oceniło te narzędzia jako „w ogóle nieskuteczne lub mało skuteczne” … a tylko 2,4% uznało je za skuteczne.

Overlaye tworzą nowe bariery dla użytkowników, którym w założeniu mają pomagać. Czytniki ekranu są zaprojektowane tak, aby interpretować leżącą u podstaw semantyczną strukturę strony internetowej (elementy HTML, atrybuty ARIA) w celu przekazywania informacji użytkownikom. Wiele stron stawiających na rozwiązania overlay nie ma w samym kodzie czystej struktury semantycznej. Ważne atrybuty, takie jak aria-label, brakują całkowicie. I właśnie tu leży problem: technologie asystujące, takie jak czytniki ekranu, potrzebują tych informacji, aby prowadzić użytkowników przez treści.

Jeśli zamiast tego overlay z JavaScriptem po prostu nakłada na wierzch tylko funkcje wizualne, w samej strukturze nic się nie zmienia. Overlaye często nie aktualizują poprawnie tej podstawowej struktury semantycznej lub mogą nawet wchodzić z nią w konflikt, wstrzykując JavaScript i wprowadzając powierzchowne zmiany wizualne.

Rezultat jest taki, że narzędzie, które ma poprawiać dostępność, paradoksalnie tworzy nowe, frustrujące bariery dokładnie dla tych osób, które są zdane na AT, przez co ich doświadczenie użytkownika pogarsza się zamiast poprawiać. Na końcu powstaje złudna powierzchnia, która dobrze wygląda, ale może niszczyć kluczowe funkcje dla technologii asystujących.

Zdecydowane stanowisko społeczności osób z niepełnosprawnościami

Społeczność osób z niepełnosprawnościami, wraz z ogromną większością ekspertów ds. dostępności i dostawców technologii asystujących, wypowiedziała się w przeważającej mierze i jednoznacznie przeciwko stosowaniu overlayów dostępności.

Ta zbiorowa opozycja jest znacząca: ponad 970 ekspertów ds. dostępności i osób z niepełnosprawnościami podpisało – według stanu na 12 lipca 2025 roku – list otwarty, w którym potępiają ich stosowanie.

Wielu użytkowników aktywnie stosuje ad-blockery, aby zapobiec ładowaniu overlayów. To zdecydowane stanowisko wynika stąd, że overlaye często tworzą więcej barier, zakłócają istniejące, preferowane narzędzia asystujące, a nawet mogą budzić poważne obawy o ochronę danych, automatycznie wykrywając i potencjalnie rejestrując korzystanie z technologii asystujących bez wyraźnej zgody użytkownika.

Funkcje, które rozdymają stronę, ale których nikt nie potrzebuje

Patrząc na bogactwo funkcji wtyczki BFW, z jednej strony imponujące jest to, co deweloperzy stworzyli, aby umożliwić użytkownikom ulepszony widok strony internetowej. Z drugiej strony można zapytać, co w ogóle jest potrzebne po stronie użytkownika, ponieważ wiele funkcji, takich jak zmiany rozmiaru tekstu, kontrasty kolorów itd., i tak jest już dostarczanych przez przeglądarkę (zobacz na przykład zaimplementowany w Chrome tryb czytania) lub czytniki ekranu.

Nowy kod, który jest wstrzykiwany przez overlaye w istniejącą strukturę kodu, nie tylko spowalnia PageSpeed, ale też nie jest dostrojony do warunków layoutu strony. Oto przykład widoku przy aktywowanym trybie dla dyslektyków. Przy trzech produktach tytuł produktu jest ucięty, a także przy wyróżnieniach brakuje już miejsca na tekst w zielonych zajawkach graficznych. To, co ma być przyjazne dla dyslektyków, utrudnia dostęp do informacji.

Tego silnego przerostu można było uniknąć, gdyby każda funkcja została poważnie sprawdzona pod kątem sensowności.

Dochodzi jeszcze jedna osobliwość. Ta czcionka, która jest wyświetlana po kliknięciu przycisku „Przyjazne dla dyslektyków”, nazywa się Open Dyslexic. Została pierwotnie opracowana, aby zapewnić lepszą czytelność. Tak brzmi hipoteza.

Na konferencji Axe-Con 2021 Readability Group zaprezentowała swoje duże badanie typograficzne, w którym przetestowała skuteczność 20 różnych czcionek na 2022 uczestnikach. W tym ponad 250 osobach z wyraźnymi cechami dyslektycznymi. Axe-Con to coroczna, międzynarodowa konferencja online, poświęcona wyłącznie dostępności cyfrowej. Readability Group to niezależna firma badawczo-doradcza, specjalizująca się w czytelności, typografii i projektowaniu dostępnych krojów pisma.

Celem badania typograficznego było ustalenie na podstawie prawdziwych danych użytkowników, które fonty są rzeczywiście czytelne, a które noszą jedynie etykietę „dostępne”. Każda czcionka została obejrzana ponad 16 000 razy w około 7000 godzin testów. Oto lista 20 czcionek, zaczynając od kroju z najwyższą aprobatą.

• BBC Reith Sans 65%
• SF Pro 65% … Apple opracowało SF Pro wewnętrznie, ponieważ Helvetica Neue wyglądała na iPhone’ach zbyt ciasno
• Verdana 64% … dobrze pamiętam, wiele stron internetowych 20 lat temu wybierało ten font. Verdana została zaprojektowana specjalnie dla Microsoftu z myślą o monitorach o niskiej rozdzielczości. Litery zostały zaprojektowane szczególnie szeroko, aby były wyraźne nawet na monitorach kineskopowych.
• Segoe UI 62%
• Legend Decca 62%
• Atkinson 60%
• Red Hat Text 60%
• Roboto 57% … font od Google. Stosowaliśmy go już także w kilku projektach klientów.
• FS Me 56%
• Calibri 55% … przez długi czas standardowa czcionka Microsoftu, po tym jak w 2007 roku zastąpiła Times New Roman.
• BBC Reith Serif 54%
• Ubuntu 54% … tego kroju używamy także tutaj, na naszej stronie agencji. Tę linijkę czytasz właśnie w tym foncie.
• Helvetica 47% … everybody’s darling.
• Roboto Slab 47%
• Lexie Readable 44% … opracowana specjalnie dla lepszej czytelności dla osób z dysleksją
• Times New Roman 36%
• Sylexiad Sans 36% … opracowana specjalnie dla lepszej czytelności dla osób z dysleksją
• Dislexie 30% … opracowana specjalnie dla lepszej czytelności dla osób z dysleksją
• Comic Sans 28% … najbrzydsza czcionka w ogóle.
• Open Dyslexic 18% … opracowana specjalnie dla lepszej czytelności dla osób z dysleksją

Interesujące jest to, że najsłabiej wypadające czcionki dla grupy dyslektyków to dokładnie te, które zostały „zaprojektowane” na ich korzyść. Tryb dla dyslektyków oferuje osobom dotkniętym dysleksją czcionkę z najniższą aprobatą. Tak też okazuje się w tym przypadku z wtyczką dostępności: w dobrej wierze, obok celu i niepotrzebnie.

Co mówią narzędzia testujące o dostępności deutschesee.de?

Audyt Accessibilitychecker.org dla sklepu deutschesee.de dostarcza zobiektywizowanych danych na temat porażki wtyczek w zapewnianiu prawdziwej dostępności. Pomimo ładowania wtyczki dostępności strona otrzymała mizerny wynik „Audit Score: 29%” i została jednoznacznie oznaczona jako „NOT COMPLIANT” w ramach „Germany law”.

Audyt wykazał ponadto 117 krytycznych problemów tylko dla testowanej podstrony sklepu i wskazuje, że strona nie spełnia licznych kryteriów WCAG. Znamienne jest przy tym, że Accessibilitychecker.org w tym przypadku nawet nie rozpoznaje overlaya jako takiego, co przy innych narzędziach jak najbardziej robi. Ironia losu: Händlerbund również oblewa test ze swoją stroną marketplace, na której oferowana jest wtyczka dostępności.

Niemniej jednak ograniczona część wymienionych problemów jest faktycznie rozwiązywana przez wtyczkę, jak na przykład kontrasty kolorów, które obecnie są zbyt słabe. Pozostałe kwestie, takie jak brakujące teksty alt, brakujące etykiety ARIA czy brak dostępnych nazw przycisków, nie są rozwiązywane przez wtyczkę … a to właśnie te informacje, które są elementarne dla osób z dysfunkcją wzroku korzystających z czytników ekranu.

Poniższa tabela porównuje, jak overlaye i rozwiązania code-level radzą sobie z zasadami WCAG:

Ta tabela uwidacznia fundamentalne różnice w podejściu i skuteczności między overlayami a rozwiązaniami code-level.

Ograniczone ulepszenia są możliwe dzięki wtyczkom i overlayom

Kto zadaje sobie teraz pytanie, o ile procent wtyczki i overlaye pomagają na drodze do zgodności, może jako regułę kciuka przyjąć ok. 40% poprawy.

Skynet Technologies ma do tego tryb, który dolicza działanie wtyczki do wyniku. Także tutaj można bezpłatnie przeprowadzić kontrolę jednej podstrony. Dla Deutsche See wynik to niecałe 57 procent i status Semi Compliant.

https://freeaccessibilitychecker.skynettechnologies.com/?website=deutschesee.de

Interesujący jest przede wszystkim przełącznik u góry po prawej, przy którym symulowane jest zastosowanie oferowanego przez Skynet Technologies narzędzia All in One Accessibility w wariancie płatnym — ile problemów zostaje dzięki niemu rozwiązanych. Ponad 200 problemów może zostać usuniętych. Wynik rośnie o ponad 25 punktów procentowych. Pozostaje jednak status Semi Compliant.

Kuszący czy wprowadzający w błąd marketing dostawców?

Wtyczki dla zgodności z przepisami to obietnica marketingowa, do której należy podchodzić z ostrożnością. Założenie operatorów stron internetowych jest przecież właśnie takie, że wtyczka zapewnia spełnienie wymogów ustawowych. Ale najwyraźniej tego nie robią. Większą implikacją jest to, że firmy nie tylko kupują i wdrażają wadliwe rozwiązanie techniczne, lecz aktywnie inwestują w ryzyko prawne.

Overlaye dostępności nie spełniają swojego głównego reklamowanego celu, jakim jest zagwarantowanie zgodności z przepisami prawa. Potwierdza to szeroko rozpowszechniony konsensus ekspertów, że narzędzia te dają fałszywe poczucie bezpieczeństwa i nie chronią przed brakiem zgodności.

Interesująca jest różnica w komunikacji przy reklamowaniu wtyczek dostępności między uznanymi amerykańskimi dostawcami, którym w skłonnym do pozwów środowisku pokazano już granice, a nowymi poszukiwaczami złota na niemieckim rynku. Amerykańskie strony reklamują swoje narzędzie stwierdzeniami takimi jak:

• wspiera firmy w optymalizacji pod kątem dostępności
• poprawia dostępność
• redukuje ryzyka prawne

Jedyne, co da się tutaj zrobić kilkoma kliknięciami lub w dwie minuty, to wyłącznie integracja narzędzia na stronie internetowej, ale nie dostępność. I dostawcy piszą to też całkiem otwarcie.

Nowi niemieccy dostawcy narzędzi, którzy wyrastają jak grzyby po deszczu, komunikują to natomiast w zróżnicowany sposób. Wtyczka BFW obiecuje z pełnym przekonaniem:

• Czy to strona internetowa, sklep czy portal – zgodność z BFSG jednym kliknięciem
• Dzięki naszemu wysoce kompatybilnemu rozwiązaniu wtyczkowemu Państwa strona internetowa spełnia wymogi ustawowe.
• Zapewnij sobie bezpieczną prawnie i dostępną cyfrowo stronę internetową dzięki naszej wtyczce – szybko i łatwo.
• Dzięki naszej wtyczce unikną Państwo ryzyk prawnych i poprawią doświadczenie użytkownika dla WSZYSTKICH odwiedzających.
• Dzięki naszej wtyczce zintegrują Państwo dostępność na swojej istniejącej stronie internetowej w ciągu kilku minut. Tylko dwie linijki kodu – natychmiast więcej inkluzji i bezpieczeństwa prawnego.
• Bezpieczeństwo prawne: spełnia wszystkie wymagania WCAG 2.1 i BITV 2.0.
• Aktywuj dostępność w kilka minut.
• Dzięki naszej certyfikowanej wtyczce uczynią Państwo swoją stronę internetową dostępną w kilka minut – zgodnie z prawem, bezpiecznie i całkowicie bez nakładu programistycznego.

Chętnie bym się dowiedział, o jakim dokładnie rodzaju certyfikacji mówi dostawca. Nie znajduję o tym żadnej informacji.

U konkurenta AccessGo znajdują się obietnice takie jak:

• … spełnij wymogi ustawowe łatwo, szybko i bezstresowo.
• … wdróż wytyczne automatycznie i w sposób bezpieczny prawnie – całkowicie bez nakładu technicznego.

W deklaracji dostępności firm, które faktycznie stosują to narzędzie, następuje wycofywanie się z obietnic. Tak przykładowo na stronie Eintracht Braunschweig, która korzysta z wtyczki AccessGo. Gdy odwiedzasz tę stronę, od razu napotykasz pierwszą barierę dostępu: ikona wtyczki dostępności jest obecnie jeszcze zasłonięta przez baner cookie. Ponadto baner cookie jest po angielsku, ponieważ reaguje na język przeglądarki, mimo że jestem na niemieckiej stronie Eintrachtu.

Banery cookie niestety nazbyt często nie dają się odczytać przez czytniki ekranu, co jest krytykowane bezpośrednio także przez społeczność osób niedowidzących.

Jeśli zajrzysz na stronie do deklaracji dostępności, czytamy tam:

Jak dostępna jest oferta?

Ocena opiera się na samoocenie z wykorzystaniem narzędzia accessibility od AccessGO.

Na podstawie tej weryfikacji strona internetowa jest częściowo zgodna z wyżej wymienionymi wymaganiami dostępności.

W szczególności następujące punkty nie są w pełni zgodne z obowiązującymi nas przepisami dotyczącymi dostępności:

Bariera: niektóre przyciski są puste lub nie zawierają opisowego tekstu.
Bariera: niektóre linki są puste lub nie zawierają tekstu, przez co ich cel lub funkcja nie są rozpoznawalne.
Bariera: niektóre obrazy są puste lub nie zawierają opisowego tekstu.
Obecnie planujemy realizację usunięcia tych barier.

Z marketingowego punktu widzenia AccessGo rozegrało to sprytnie. Firmom zobowiązanym do dostępności obiecuje się szybkie i łatwe spełnienie wymagań WCAG. Bezpieczeństwo prawne kilkoma kliknięciami. Agencje i/lub firmy decydują się więc na narzędzie, ale na końcu dostarczana jest tylko częściowa zgodność. Po zainstalowaniu wtyczki liczne problemy pozostają, o czym następnie informuje się w deklaracji dostępności. Czy to wystarczy, aby zapobiec grzywnom lub wezwaniom do zaniechania? Szczerze mówiąc, nie wiem. Czas pokaże.

Psychologicznie zręcznie dobrano także nazwę firmy, która w stopce prezentowana jest jako podmiot stojący za narzędziem AccessGo: Deutsche Gesellschaft für Barrierefreiheit (Niemieckie Towarzystwo Dostępności).

Poniżej tej poprzeczki się nie schodzi. Od razu przypomina to prawdziwe instytucje, takie jak Deutsche Gesellschaft für internationale Zusammenarbeit czy Deutsche Gesellschaft für Psychologie, towarzystwa ds. żywienia, medycyny paliatywnej lub inne znane towarzystwa, w których członkowie wymieniają się doświadczeniami i w interesie danego tematu dążą do społecznych ulepszeń. Z tą tylko różnicą, że Deutsche Gesellschaft für Barrierefreiheit nie jest stowarzyszeniem ani fundacją, lecz spółką GmbH, która została wpisana do rejestru handlowego dopiero w marcu 2025 roku.

Co najmniej 100 firm już stosuje to narzędzie, zwabionych obietnicą szybkiego spełnienia wymagań WCAG i bezpieczeństwa prawnego – szybko i bez większego wysiłku dostępne cyfrowo, jak głosi też stopka na dole. Jako firma chce się przecież postawić na właściwe narzędzie. Na wielkie (sprzedażowe) szczęście dostawca narzędzia otrzymał już w styczniu 2025 roku – a więc jeszcze przed założeniem spółki – odpowiednie najlepsze oceny na aż trzech portalach, od trzech identycznych nazw użytkowników: Patrick, Laura i Anonymus.

Dzięki temu można było od samego startu reklamować się na stronie internetowej ocenami „klientów”.

My jako agencja jesteśmy szczerze wdzięczni, gdy klienci dorzucą recenzję Google. To, że klient składa swoją pochwalną pieśń od razu na trzech platformach z opiniami, jest dla mnie od dziś nowym złotym standardem.

Naprawdę topornie robi się przy testimonialach wtyczki BFW, która jest aktywnie promowana przez Händlerbund.

Klienci Thomas Klein i Anna Schubert chwalą ponad miarę. Oczywiście. Nazwiska tak niemieckie i chwytliwe, jakby każdy miał kiedyś w swojej klasie osobę o tym nazwisku. Czy oni naprawdę istnieją? To pozostaje wątpliwe. Bo obydwoje odtwórcy testimoniali na innej stronie internetowej nazywają się Christa i John Smith.

Istnieją jednak jeszcze inne zastosowania tych zdjęć, łatwe do ustalenia przez Google Lens. Niezależnie od tego, czy zdjęcie pochodzi z portalu stockowego, czy z AI, przypuszczalnie zdjęcia były już zintegrowane jako placeholdery w użytym szablonie strony.

Także trzeci niemiecki dostawca, którego narzędzie według własnych słów kilkoma kliknięciami „automatycznie czyni Państwa stronę internetową dostępną”, stosuje to podejście na swoim landing page’u:

Klient Leon na tej innej stronie internetowej nazywa się już Markus, a w ponad 150 kolejnych obecnościach online Ben, Will, David albo może też Heinz.

Ryzyka prawne: overlaye nie chronią przed pozwami

Agencje i firmy ufają nowym dostawcom, aby szybko i łatwo uczynić swoje strony lub strony klientów bezpiecznymi prawnie, wsparte chwytliwymi obietnicami spełnienia wymagań WCAG, rekomendacją poważnych usługodawców, takich jak Händlerbund, oraz rzekomymi cytatami klientów, których pochodzenie jest więcej niż mgliste. W zamian firmy są gotowe ponosić roczne koszty, co samo w sobie jest w porządku, jeśli świadczenie wzajemne się zgadza. Tutaj jednak firmy otrzymują rozwiązanie, które nie zapewnia zgodności. I prędzej czy później otrzymamy na to w Niemczech także sądowe potwierdzenie.

Przykład z końca 2025 roku – milionowa kara: Fashion Nova potyka się o dostępność (ADA). Gigant fast fashion Fashion Nova musiał głęboko sięgnąć do kieszeni. Firma zapłaciła ugodę w wysokości 5,15 miliona USD w ramach pozwu zbiorowego za naruszenie ustawy Americans with Disabilities Act (ADA). Sedno problemu? Strona e-commerce była dla niewidomych i niedowidzących użytkowników, zdanych na oprogramowanie czytników ekranu, po prostu bezużyteczna.

Na czym polegał błąd techniczny? Pozew dotyczył fundamentalnych wad w kodowaniu strony internetowej, które naruszały uznane międzynarodowo wytyczne WCAG (Web Content Accessibility Guidelines). Najważniejsze zaniedbania to:

• Brak kompatybilności z czytnikami ekranu: ważne elementy sterujące i informacje o produktach nie mogły być poprawnie odczytywane ani rozpoznawane przez technologie asystujące.
• Brak struktury: strona była tak źle oznaczona, że efektywna nawigacja i proces zakupowy były niemożliwe.

Czy Fashion Nova korzystała z „szybkiego” accessibility overlaya, nie wynika z dokumentów – ale ten przypadek to jasny sygnał: overlaye nie są w stanie naprawić głęboko osadzonych problemów w kodzie, które prowadzą do pozwów.

W USA od dawna jest jasne: overlaye dostępności nie zapewniają żadnej ochrony prawnej. Amerykańskie Ministerstwo Sprawiedliwości wyraźnie zaleca przestrzeganie wytycznych WCAG 2.1 AA jako minimalnego standardu zgodności z ADA (amerykańskim odpowiednikiem naszej europejskiej dyrektywy EAA, do której odnosi się niemiecka ustawa BFSG). Mimo to wiele firm nadal ufa technicznym rozwiązaniom pozornym, takim jak overlaye. Miało to już kosztowne konsekwencje. Tylko w 2023 roku 24,5% wszystkich pozwów ADA dotyczyło stron internetowych, które stosowały właśnie takie wtyczki.

Wyroki sądowe, takie jak Murphy vs. Eyebobs czy Quezada vs. US Wings, pokazały, że overlaye nie stanowią zabezpieczenia prawnego. Tymczasem pozwy zbiorowe kierowane są nawet bezpośrednio przeciwko dostawcom overlayów: tak na przykład w sprawie accessiBe, które za wprowadzające w błąd obietnice dotyczące skuteczności swojego narzędzia musiało zapłacić karę w wysokości milionów. Były to obietnice nie tak odległe od tych składanych przez przedstawione tutaj narzędzia.

To, co dzieje się dziś w USA, może być zwiastunem dla Europy. Wraz z wejściem w życie ustawy o wzmocnieniu dostępności (BFSG) podobne ryzyka odpowiedzialności stają się realne także u nas. Sama BFSG przewiduje grzywny do 100 000 euro. Firmy stawiające na rzekomo „szybkie” rozwiązania wtyczkowe nie inwestują w dostępność, lecz w ryzyko prawne: wtyczki udają bowiem zgodność, nie spełniając rzeczywistych wymagań. A gdyby firmy były szczere, inwestycja w takie wtyczki nigdy nie była motywowana większą inkluzją, lecz wyłącznie zapewnieniem bezpieczeństwa prawnego.

Powstaje niebezpieczny łańcuch: wprowadzający w błąd marketing → wdrożenie nieskutecznych overlayów → nieprzestrzeganie wymogów ustawowych → zwiększona podatność na pozwy → utrata wizerunku → potencjalnie dotkliwe grzywny → poprawki przy optymalizacji dostępności właściwym podejściem code-level, a tym samym ponowne koszty.

Podobnie wspólna ocena federalnych i krajowych organów nadzoru ds. dostępności technologii informacyjnych dotycząca stosowania narzędzi overlay wskazuje, że obecnie narzędzia overlay nie są w stanie sprawić, aby serwis internetowy zawierający bariery był prezentowany jako całkowicie dostępny.

Możliwy jest także kolejny scenariusz: pozwy z AGG z powodu niewystarczającej dostępności. Jeśli jako osoba z dysfunkcją wzroku nie możesz zapoznać się z ogłoszeniem o pracę na stronie internetowej firmy lub go obsłużyć z powodu braku dostępności (np. brakujących tekstów alternatywnych, nieczytelnych PDF-ów czy niedostępnych pól formularzy), mogłoby to stanowić pośrednią dyskryminację ze względu na niepełnosprawność. Kto potrafi uwiarygodnić, że został poszkodowany z powodu braku dostępności i że wyniknęła z tego niekorzyść w procesie rekrutacji, mógłby być skłonny żądać odszkodowania lub zadośćuczynienia. Raz po raz czytamy w prasie o procesach przed sądami pracy, w których niektóre osoby setki razy wnosiły pozwy o dyskryminację w procesie rekrutacji.

Poleganie wyłącznie na overlayach dostępności czyni firmy podatnymi na pozwy i konsekwencje prawne z powodu braku zgodności. To, co w USA wydarzyło się już w ostatnich latach, prognozuję dokładnie tak samo dla UE i dla Niemiec.

Händlerbund dalej pilnie bębni na rzecz rozwiązania z wtyczką BFW i 10 lipca zapytał swoich członków wprost w temacie maila swojego newslettera informacyjnego: Dostępność: kogo trafi pierwsze wezwanie do zaniechania? ⏳

Być może się tutaj w całości mylę i błędnie oceniam realia wdrażania wymagań WCAG w Niemczech, po prostu przenosząc na nas z USA ryzyka prawne, na które narażają się firmy stosujące overlaye. Bardzo cenię serwis prawny Händlerbund. Korzystamy z niego od lat. A moje słowa w tym wpisie na blogu nie są poradą prawną, lecz po prostu moim osobistym spojrzeniem, a więc głosem w dyskusji. Naprawdę więc nie pojmuję, jak Händlerbund sprzedaje swoim dziesiątkom tysięcy członków wtyczkę jako rozwiązanie bezpieczne prawnie. Wtyczka skoryguje tylko ok. 40% problemów. I właściwie ma sens tylko wtedy, gdy chodzi o rozwiązanie problemów z kontrastami kolorów, gdy na przykład korekty kolorystyczne nie są możliwe ze względu na corporate design. Ale nawet wtedy można na bazie kodu po prostu dodać przełącznik kontrastu, który ładuje jedynie kod potrzebny do dostosowania kolorów przez CSS po kliknięciu. Wtedy nie ma problemów z nadmiarem kodu, z wpływem na PageSpeed ani innych wad.

Właściwą drogą jest zatem zapewnienie dostępności na poziomie kodu – zabezpieczone narzędziami testującymi i testami manualnymi.

Code-level accessibility: złoty standard trwałej inkluzji

Dostępność zaczyna się w kodzie, nie we wtyczce. Chodzi o takie ustrukturyzowanie HTML, CSS i JavaScriptu, aby treści były użyteczne dla wszystkich, także dla użytkowników czytników ekranu czy nawigacji klawiaturowej. To nie jest quick fix, lecz praca na lata.

Co przemawia za rozwiązaniami w kodzie:

• Brak opóźnień ładowania. Żadnych ociężałych overlayów, żadnych migoczących interfejsów. Tylko czysty, szybki szkielet.
• Brak ryzyk związanych z dostawcami zewnętrznymi. Żadnych obcych skryptów, które blokują inne narzędzia lub paraliżują sklep.
• Wsparcie społeczności. Osoby korzystające z technologii asystujących ufają przemyślanej, zakotwiczonej w kodzie dostępności.
• Mniejsze ryzyko prawne. Kto pracuje nad dostępnością w kodzie, spełnia prawdziwe standardy: WCAG, ADA, BFSG. Żadnych rozwiązań pozornych.
• Taniej. Co raz siedzi w kodzie, nie musi być później drogo poprawiane.

Wbudowane, nie nałożone: fundament prawdziwej dostępności

Dostępność code-level oznacza wprowadzanie zasadniczych, strukturalnych zmian bezpośrednio w HTML, CSS i JavaScripcie Twojej strony internetowej. To podejście jest najbardziej niezawodną i najtrwalszą drogą do osiągnięcia prawdziwej dostępności cyfrowej”. Dzięki bezpośredniej integracji dostępności z podstawową strukturą strony zostaje ona „wbudowana w fundament Państwa strony”, co zapewnia, że ulepszenia są trwałe, solidne i integralne, a nie tymczasowymi łatkami.

W jaskrawym przeciwieństwie do overlayów zmiany code-level nie powodują żadnego dodatkowego czasu ładowania, żadnego migoczącego interfejsu i żadnego zbędnego balastu. To podejście z natury utrzymuje stronę lekką, szybką i pod Twoją kontrolą. Poprzez wyeliminowanie konieczności korzystania z zewnętrznych zależności od dostawców trzecich i unikanie niepotrzebnych warstw rozwiązania oparte na kodzie usuwają ryzyko błędów, konfliktów z innymi narzędziami czy nieoczekiwanych zakłóceń działania strony.

Dostępność code-level to akcelerator wydajności, a nie przeszkoda. Nie trzeba niczego najpierw aktywować, co być może jest zasłonięte przez baner cookie. Jest tam od samego początku. Dobre praktyki dostępności code-level z natury obejmują optymalizację HTML, CSS i JavaScriptu, zapewnienie wydajnego ładowania i minimalizowanie niepotrzebnego rozdęcia kodu. Praktyki te prowadzą bezpośrednio do mniejszych rozmiarów plików, mniejszej pracy głównego wątku i szybszych czasów renderowania, które są kluczowymi komponentami mocnych Core Web Vitals.

Wiele ulepszeń napędzanych przez dostępność, takich jak logiczna nawigacja, czytelny tekst i responsywny design, w naturalny sposób przynosi korzyści wszystkim użytkownikom, nie tylko tym z niepełnosprawnościami. To uniwersalne podejście projektowe prowadzi do lepszego ogólnego doświadczenia użytkownika i faktycznie pozytywnie przyczynia się do SEO.

Postępowanie jest stosunkowo proste. Najpierw przeprowadzany jest pełny skan wszystkich podstron profesjonalnym narzędziem. My wykorzystujemy do tego na przykład accessibilitychecker.org. Strony naszych klientów są sprawdzane w trybie WCAG 2.2 z dodatkowymi wymaganiami best practice ze społeczności. Wykazane problemy składają się na wynik. Problemy są usuwane po stronie kodu, a w kolejnych skanach realizacja jest technicznie weryfikowana. Przykładowo tutaj wynik przed i po dla strony szpitala.

Ponieważ narzędzia testujące nie potrafią wykryć wszystkich barier, muszą dodatkowo zostać przeprowadzone jeszcze testy manualne.

Co znaczące, społeczność osób z niepełnosprawnościami, w tym osoby zdane na technologie asystujące, w przeważającej mierze preferuje „dostępność code-level”, ponieważ gwarantuje ona bezproblemową i niezawodną interakcję z ich istniejącymi narzędziami bez zakłóceń.

Ponieważ poprawki code-level usuwają bariery dostępności u ich źródła, jest bardziej prawdopodobne, że spełnią ustawowe standardy zgodności, takie jak WCAG. To proaktywne, fundamentalne podejście redukuje ryzyko pozwów czy skarg i pokazuje rzeczywistą inwestycję w prawdziwie inkluzywne projektowanie stron, co oferuje solidniejszą ochronę prawną niż overlaye.

Szczuplejszy kod oznacza także mniejszy ślad węglowy. Z natury strony dostępne cyfrowo są zwykle lżejsze, szybsze i wydajniejsze, co bezpośrednio przyczynia się do mniejszego zużycia energii przez urządzenia i sieci.

Porównanie kosztów: code-level accessibility vs. wtyczka/overlay dostępności

Dostępność to nie dodatek. Ona należy do fundamentu. Kto stawia na wtyczki, może na pierwszy rzut oka oszczędza, ale długoterminowo dopłaca wielokrotnie. Kosztami dostępności cyfrowej zajęliśmy się już w osobnym wpisie na blogu. Porównanie kosztów dostępności code-level, tak jak wdrażamy ją jako agencja ds. dostępności, i zastosowania wtyczki jest opłacalne.

Wtyczki: tani start, drogi koniec

Miesięczne koszty dostawców narzędzi są podobne. Koszty wtyczki BFW wynoszą na przykład od 29 € do 59 € miesięcznie, do tego dochodzi jednorazowa opłata konfiguracyjna około 299 €, o ile dwóch linijek kodu nie da się zintegrować samodzielnie po stronie klienta. Brzmi znośnie. Ale jaka jest prawdziwa cena?

• Technicznie żadne prawdziwe rozwiązanie: wtyczka tylko przesłania, mnóstwo barier w kodzie pozostaje.
• Słabe wartości PageSpeed: zewnętrzne skrypty hamują czasy ładowania, co negatywnie wpływa na SEO & doświadczenie użytkownika.
• Brak bezpieczeństwa prawnego: wymagania BFSG czy EAA z reguły nie są spełniane przez overlaye.
• Zależność od dostawcy narzędzia: wynajmujesz rozwiązanie. Gdy tylko wypowiesz umowę, „ochrona” znika.

Code-level accessibility: raz porządnie i trwale skutecznie

Nasze własne prace nad stronami naszych klientów pokazują: już przy nakładzie 3–20 godzin wiele stron internetowych da się uczynić technicznie czystymi, dostępnymi cyfrowo i bezpiecznymi prawnie. Przy stawce godzinowej 120 € netto to według naszych doświadczeń:

• Onepager: 360–840 € netto
• Strona korporacyjna: 720–1.800 € netto
• Sklep internetowy: 1.200–2.400 € netto

W tym zawarte: dostosowania techniczne, deklaracja dostępności i ewentualnie treści w języku łatwym do czytania – wraz z audytem i potwierdzeniem 100% spełnienia WCAG certyfikatem narzędzia.

Choć początkowa implementacja dostępności code-level może wymagać większego nakładu pracy i inwestycji, redukuje ona potrzebę ciągłych prowizorek, zależność od zewnętrznych narzędzi czy kosztownych reakcji prawnych. Model proaktywny pozwala uniknąć dodatkowych wydatków i zmniejsza konieczność przerabiania lub restrukturyzowania produktów końcowych.

Wniosek: inwestycja zamiast najmu, bezpieczeństwo zamiast rozwiązania pozornego

Kto czyni swoją stronę dostępną porządnie w kodzie, inwestuje w substancję – i zyskuje:

• lepsze wartości SEO
• szybsze czasy ładowania
• pozytywne user signals
• większe bezpieczeństwo prawne
• brak bieżących kosztów wtyczki

Wskazówka: niektóre agencje żądają za sam audyt 2.500 €. U nas dostaniesz go bezpłatnie. Powiemy Ci szczerze, co jest do zrobienia … i wdrożymy to, jeśli chcesz. Uczciwie. Przejrzyście. Z prawdziwym rezultatem.

Dostępność code-level to strategiczna inwestycja biznesowa, a nie tylko wydatek na zgodność z przepisami. Postrzegane wyższe koszty początkowe dostępności code-level są często wymieniane jako przeszkoda … także w deklaracjach dostępności co jakiś czas pojawia się stwierdzenie o ekonomicznej niewspółmierności. Z naszej perspektywy nie jest to do końca zrozumiałe. To raczej wymówka obronna. Odcinków podcastów nie da się transkrybować? AI robi to już w sposób zautomatyzowany. Wideo bez napisów? Te również można stworzyć przez AI i przypisać do wideo, o ile filmy i tak nie są ładowane przez YouTube, gdzie napisy można aktywować kliknięciem. Tekstów alt nie da się uzupełnić? Wymówka. Korekty po stronie kodu są zbyt kosztowne? Zdecydowanie nie, co udowodniliśmy dziesiątki razy w różnych systemach CMS i sklepowych.

Jeśli chcesz, aby Twoja strona działała dla wszystkich – zrób to porządnie. Zrób to w kodzie. Pomożemy Ci uczynić stronę internetową dostępną cyfrowo.

Podsumowanie: budowa naprawdę dostępnej i wydajnej sieci

Wtyczki i overlaye dostępności, mimo kuszących obietnic szybkich rozwiązań, to fałszywe poczucie bezpieczeństwa. Overlay może poprawić zgodność z niektórymi postanowieniami najważniejszych standardów dostępności. Pełnej zgodności ze standardami WCAG nie da się jednak osiągnąć samym overlayem. Niemieccy dostawcy wtyczek reklamują, że dostępność jest osiągalna kilkoma kliknięciami, a w deklaracjach dostępności ich klientów czytamy potem, czego to wszystkiego jednak się nie da.

Jak pokazuje przykład deutschesee.de, overlaye te znacznie pogarszają wydajność strony z negatywnymi konsekwencjami dla user experience i SEO. Wbrew swojemu przeznaczeniu nie spełniają rzeczywistych wymagań WCAG, lecz zamiast tego nadal narażają firmy na ryzyka prawne. Ostatecznie frustrują użytkowników z niepełnosprawnościami i częściowo nadal aktywnie ich wykluczają.

To podejście code-level jest trwałym, skalowalnym i prawdziwym rozwiązaniem, które oferuje wszystkim odwiedzającym lepsze doświadczenie użytkownika, poprawia SEO, wzmacnia pozycję prawną, a nawet pozytywnie przyczynia się do zrównoważonego rozwoju ekologicznego.

Dostępność to proces ciągły, a nie jednorazowa instalacja produktu. Zautomatyzowane narzędzia overlay są niewystarczające do osiągnięcia prawdziwej dostępności. Oznacza to również, że podejście „skonfiguruj i zapomnij”, często kojarzone z wtyczkami, jest z gruntu błędne. Zamiast tego dostępność wymaga ciągłego procesu, który integruje ludzką wiedzę (np. w pielęgnacji treści), regularne audyty i monitoring. To przesuwa paradygmat od postrzegania dostępności jako produktu, który trzeba kupić, w stronę osadzonego procesu wewnątrz firmy, w którym inkluzja jest rzeczywiście brana pod uwagę.

Wiele z tych szybkich rozwiązań zawodzi jednak w praktyce, ponieważ prawdziwa dostępność nie powstaje dzięki wtyczce, lecz dzięki czystemu kodowi, przemyślanej strukturze i ciągłej pielęgnacji.