Wytyczne Dostępności Treści Internetowych (WCAG) – Wersje 2.0, 2.1 i 2.2

Definicja WCAG

Wytyczne dotyczące Dostępności Treści Internetowych (Web Content Accessibility Guidelines – WCAG – więcej tutaj) stanowią zbiór międzynarodowych, technicznych standardów i rekomendacji, których celem jest zapewnienie szerokiego dostępu do treści cyfrowych. Opracowane i publikowane przez Inicjatywę na rzecz Dostępności Internetu (Web Accessibility Initiative – WAI), działającą w ramach Konsorcjum World Wide Web (World Wide Web Consortium – W3C), wytyczne te są uznawane za globalny benchmark w dziedzinie dostępności cyfrowej. Głównym celem WCAG jest uczynienie treści internetowych – w tym stron internetowych, aplikacji mobilnych, dokumentów i innych zasobów cyfrowych – bardziej dostępnymi, przede wszystkim dla osób z niepełnosprawnościami. Jednakże korzyści płynące z ich wdrożenia wykraczają daleko poza tę grupę, obejmując również osoby starsze ze zmieniającymi się zdolnościami, użytkowników urządzeń mobilnych o ograniczonych możliwościach interfejsu, a także osoby znajdujące się w nietypowych sytuacjach, np. korzystające z ekranu w pełnym słońcu.

Twórcy i Kontekst

Za opracowanie i rozwój standardu WCAG odpowiada Konsorcjum World Wide Web (W3C), które jest główną międzynarodową organizacją normalizacyjną dla Internetu, odpowiedzialną za rozwój kluczowych technologii, takich jak HTML czy CSS. W 1997 roku w ramach W3C powołano do życia Inicjatywę na rzecz Dostępności Internetu (WAI), której misją jest prowadzenie działań na rzecz poprawy dostępności sieci dla osób z niepełnosprawnościami poprzez rozwój standardów, wytycznych, materiałów edukacyjnych i narzędzi. Pierwsza wersja wytycznych, WCAG 1.0, została opublikowana w 1999 roku. Kolejne wersje, począwszy od WCAG 2.0 (opublikowanej w 2008 roku), są wynikiem szerokiego, międzynarodowego konsensusu, w którego budowanie zaangażowane są jednostki, organizacje i rządy z całego świata. Ta globalna współpraca zapewnia, że WCAG jest standardem uniwersalnym, odpowiadającym na zróżnicowane potrzeby i konteksty prawne.

Zasięg Niepełnosprawności

WCAG został zaprojektowany tak, aby adresować potrzeby użytkowników z szerokim spektrum niepełnosprawności. Wytyczne uwzględniają bariery, z jakimi mogą spotykać się osoby z:

• Niepełnosprawnościami wzroku: w tym osoby niewidome, które korzystają z czytników ekranu, oraz osoby słabowidzące, które potrzebują wysokiego kontrastu i możliwości powiększania tekstu.
• Niepełnosprawnościami słuchu: osoby głuche i słabosłyszące, dla których kluczowe są napisy do materiałów wideo i transkrypcje nagrań audio.
• Niepełnosprawnościami ruchowymi: osoby, które nie mogą korzystać z myszy i nawigują za pomocą klawiatury, przełączników lub poleceń głosowych, a także osoby z ograniczoną precyzją ruchów.
• Niepełnosprawnościami mowy: które mogą wymagać alternatywnych metod komunikacji i wprowadzania danych.
• Niepełnosprawnościami poznawczymi, językowymi i w uczeniu się: osoby, dla których ważna jest prosta nawigacja, zrozumiały język, przewidywalność działania interfejsu oraz pomoc w unikaniu i korygowaniu błędów.
• Wrażliwością na światło (fotosensytywnością): osoby, u których migające treści mogą wywoływać ataki padaczki.

WCAG uwzględnia również sytuacje, w których różne rodzaje niepełnosprawności występują jednocześnie.

Status Międzynarodowy

Znaczenie i autorytet WCAG zostały formalnie potwierdzone na arenie międzynarodowej. Wersja WCAG 2.0 została przyjęta jako norma ISO/IEC 40500:2012 przez Międzynarodową Organizację Normalizacyjną (ISO). Nadanie statusu normy ISO oznacza, że WCAG jest oficjalnie uznanym standardem technicznym, co znacząco ułatwia jego adaptację w krajowych i międzynarodowych ramach prawnych, systemach zamówień publicznych oraz politykach korporacyjnych na całym świecie.

Fundamentalną cechą, która zapewnia trwałość i uniwersalność standardu, jest jego niezależność od technologii. Zamiast tworzyć reguły ściśle powiązane z konkretną wersją HTML czy CSS, które szybko stałyby się przestarzałe, W3C oparło WCAG na ponadczasowych zasadach. Przykładowo, zasada „zapewnij alternatywę tekstową dla treści nietekstowej” (Wytyczna 1.1) pozostaje aktualna niezależnie od tego, czy treść nietekstowa jest obrazem w formacie JPEG, modelem 3D w technologii WebGL, czy interaktywnym elementem w wirtualnej rzeczywistości. Takie podejście sprawia, że WCAG nie jest jedynie listą kontrolną dla deweloperów, ale strategicznym frameworkiem dla projektowania inkluzywnego. Inwestycja w zrozumienie i wdrożenie tych fundamentalnych zasad, a nie tylko mechaniczne spełnianie poszczególnych kryteriów, jest dla organizacji strategią na rzecz budowy długoterminowej, zrównoważonej dostępności cyfrowej, która przetrwa kolejne cykle ewolucji technologicznej.

Architektura WCAG: Zasady, Wytyczne i Poziomy Zgodności

Struktura Wytycznych dotyczących Dostępności Treści Internetowych jest hierarchiczna i została zaprojektowana w sposób, który ułatwia zrozumienie celów dostępności na różnych poziomach abstrakcji – od ogólnych filozofii po konkretne, testowalne wymagania. Ta wielowarstwowa architektura składa się z czterech zasad, trzynastu wytycznych oraz mierzalnych kryteriów sukcesu.

Cztery Zasady (POUR)

Fundamentem WCAG są cztery nadrzędne zasady, które definiują, czym jest dostępność cyfrowa. Są one często określane akronimem POUR. Każda treść cyfrowa, aby była dostępna, musi być:

1. Postrzegalna (Perceivable): Informacje i komponenty interfejsu użytkownika muszą być prezentowane w sposób, który użytkownicy mogą odebrać za pomocą dostępnych dla nich zmysłów. Oznacza to, że treść nie może być „niewidzialna” dla żadnego ze zmysłów użytkownika. W praktyce realizuje się to poprzez dostarczanie alternatyw, np. tekstu alternatywnego dla obrazów (dla osób niewidomych), napisów do filmów (dla osób niesłyszących) czy zapewnienie odpowiedniego kontrastu kolorów (dla osób słabowidzących).
2. Funkcjonalna (Operable): Komponenty interfejsu użytkownika i nawigacja muszą być możliwe do obsłużenia. Użytkownik musi być w stanie wejść w interakcję ze wszystkimi elementami. Kluczowe aspekty to m.in. możliwość obsługi wszystkich funkcji za pomocą klawiatury, zapewnienie użytkownikom wystarczającej ilości czasu na wykonanie zadań, unikanie treści, które mogą wywoływać ataki padaczki, oraz oferowanie łatwych w użyciu mechanizmów nawigacyjnych.
3. Zrozumiała (Understandable): Informacje oraz obsługa interfejsu użytkownika muszą być zrozumiałe. Nie wystarczy, że użytkownik może treść postrzec i obsłużyć – musi ją również zrozumieć. Osiąga się to poprzez stosowanie prostego i jasnego języka, zapewnienie przewidywalnego i spójnego działania stron internetowych oraz oferowanie mechanizmów pomagających użytkownikom unikać błędów i je korygować, np. w formularzach.
4. Solidna (Robust): Treści muszą być wystarczająco solidne (niezawodne), aby mogły być poprawnie interpretowane przez szeroką gamę programów użytkownika, w tym przez technologie asystujące (AT). Oznacza to, że treść powinna być zgodna z aktualnymi standardami (np. HTML, CSS) i działać poprawnie na różnych przeglądarkach, urządzeniach oraz z różnymi technologiami wspomagającymi, zarówno dziś, jak i w przyszłości. W prawie polskim i unijnym zasada ta jest często określana jako Kompatybilność.

Hierarchia Wytycznych

Pod każdą z czterech zasad znajdują się wytyczne, które precyzują cele, do jakich powinni dążyć twórcy treści cyfrowych. Struktura ta wygląda następująco :

• Zasady: Cztery nadrzędne filary (POUR), które stanowią filozoficzną podstawę dostępności.
• Wytyczne: W ramach WCAG 2.2 istnieje 13 wytycznych (np. „1.1 Alternatywa tekstowa”, „2.1 Dostępność z klawiatury”). Wytyczne te określają podstawowe cele i stanowią ramy dla niższych poziomów. Same w sobie nie są testowalne.
• Kryteria Sukcesu: Dla każdej wytycznej zdefiniowano konkretne, testowalne kryteria sukcesu (np. „1.1.1 Treść nietekstowa”). To właśnie na podstawie spełnienia tych kryteriów formalnie ocenia się zgodność strony internetowej lub aplikacji ze standardem WCAG. Są one sformułowane w sposób neutralny technologicznie, co zapewnia ich trwałość.

Poziomy Zgodności (A, AA, AAA)

Aby umożliwić elastyczne i stopniowe wdrażanie dostępności w różnych kontekstach i projektach, kryteria sukcesu zostały podzielone na trzy poziomy zgodności :

• Poziom A (podstawowy): Jest to minimalny poziom dostępności. Zawiera kryteria, które muszą być spełnione, w przeciwnym razie jedna lub więcej grup użytkowników z niepełnosprawnościami nie będzie w stanie uzyskać dostępu do treści. Niespełnienie tego poziomu oznacza istnienie fundamentalnych, krytycznych barier.
• Poziom AA (rozszerzony): Ten poziom powinien być spełniony, aby usunąć istotne bariery, które znacznie utrudniają dostęp do treści niektórym grupom użytkowników. Poziom AA jest najczęściej wymaganym standardem w przepisach prawnych na całym świecie, w tym w Unii Europejskiej, ponieważ stanowi rozsądny i osiągalny kompromis między wysoką dostępnością a możliwościami wdrożeniowymi.
• Poziom AAA (najwyższy): Jest to najwyższy i najbardziej rygorystyczny poziom dostępności. Kryteria na tym poziomie mogą być spełnione, aby jeszcze bardziej ułatwić dostęp i poprawić doświadczenia użytkowników, w tym osób z poważnymi niepełnosprawnościami. Wdrożenie wszystkich kryteriów AAA może być bardzo trudne lub wręcz niemożliwe dla niektórych typów treści, dlatego nie zaleca się wyznaczania poziomu AAA jako obowiązkowego dla całych witryn internetowych.

Struktura poziomów A, AA i AAA nie jest przypadkowa. Odzwierciedla ona starannie przemyślany model priorytetyzacji, który opiera się na analizie wpływu, jaki dana bariera wywiera na użytkownika. Przypisanie kryterium do konkretnego poziomu nie zależy od trudności jego technicznej implementacji, lecz od dotkliwości skutków jego niespełnienia. Bariery na poziomie A, takie jak brak możliwości obsługi serwisu za pomocą klawiatury, całkowicie blokują dostęp do funkcjonalności. Bariery na poziomie AA, jak zbyt niski kontrast tekstu, nie uniemożliwiają dostępu całkowicie, ale czynią go niezwykle trudnym i męczącym. Z kolei bariery na poziomie AAA, jak brak tłumaczenia na język migowy, utrudniają dostęp specyficznej grupie użytkowników, która może jednak skorzystać z alternatywnego rozwiązania (np. napisów), choć jest ono dla niej mniej komfortowe. W związku z tym organizacje powinny postrzegać te poziomy nie jako „brązowy, srebrny i złoty medal” do zdobycia, ale jako system zarządzania ryzykiem. Niespełnienie poziomu A to krytyczne ryzyko prawne i operacyjne. Niespełnienie poziomu AA to ryzyko wysokie. Niespełnienie poziomu AAA to ryzyko utraty części rynku i pogorszenia reputacji. Taka perspektywa zmienia dyskusję z „ile to kosztuje?” na „jakie jest ryzyko biznesowe i społeczne zaniechania?”.

Kontekst Prawny: WCAG w Prawie Polskim i Unijnym

Standard WCAG, choć z natury jest zbiorem technicznych rekomendacji, stał się fundamentem dla obowiązujących regulacji prawnych dotyczących dostępności cyfrowej w Polsce i całej Unii Europejskiej. Zrozumienie tego kontekstu jest kluczowe, ponieważ przekształca ono dobrowolne stosowanie najlepszych praktyk w prawny obowiązek dla wielu podmiotów.

Polska: Ustawa o dostępności cyfrowej

W Polsce kluczowym aktem prawnym jest Ustawa z dnia 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych. Ustawa ta stanowi implementację dyrektywy unijnej (UE) 2016/2102 i nakłada konkretne obowiązki na szeroko rozumiany sektor publiczny.

• Zakres podmiotowy: Ustawa obejmuje m.in. jednostki sektora finansów publicznych, państwowe jednostki organizacyjne bez osobowości prawnej, osoby prawne utworzone w celu zaspokajania potrzeb o charakterze powszechnym, a także, w określonym zakresie, organizacje pozarządowe prowadzące działalność pożytku publicznego.
• Wymagany standard: Zgodnie z ustawą, podmioty publiczne są zobowiązane do zapewnienia zgodności swoich stron internetowych i aplikacji mobilnych z wytycznymi WCAG 2.1 na poziomie AA. Ustawa w swoim załączniku wymienia szczegółowe wymagania, które są spójne z kryteriami sukcesu WCAG i normą europejską EN 301 549.
• Kluczowe obowiązki: Poza technicznym dostosowaniem serwisów, ustawa nakłada na podmioty publiczne dodatkowe obowiązki, w tym:

• Sporządzenie i publikacja „Deklaracji dostępności”, która jest publicznym oświadczeniem na temat stanu dostępności cyfrowej danego serwisu.
• Regularny przegląd i aktualizacja deklaracji (co najmniej raz w roku, do 31 marca).
• Zapewnienie mechanizmu skargowego, który pozwala użytkownikom zgłaszać brak dostępności oraz żądać udostępnienia informacji w formie alternatywnej.
• Sankcje: Ustawa przewiduje możliwość nałożenia kar finansowych. Minister właściwy do spraw informatyzacji może nałożyć karę pieniężną na podmiot, który w sposób uporczywy i nieuzasadniony nie zapewnia dostępności cyfrowej, lub który nie sporządza i nie publikuje deklaracji dostępności.

Unia Europejska: European Accessibility Act (EAA)

Przełomowym krokiem w ujednolicaniu standardów dostępności w Europie jest Europejski Akt o Dostępności (EAA), czyli Dyrektywa Parlamentu Europejskiego i Rady (UE) 2019/882. Jego znaczenie polega na rozszerzeniu obowiązku zapewnienia dostępności cyfrowej poza sektor publiczny, na kluczowe produkty i usługi sektora prywatnego.

• Rozszerzenie na sektor prywatny: EAA obejmuje szeroki katalog produktów i usług, które muszą być dostępne dla osób z niepełnosprawnościami. Należą do nich między innymi:

• Sprzęt komputerowy i systemy operacyjne
• Smartfony i inne urządzenia do komunikacji
• Terminale płatnicze i bankomaty
• Czytniki e-booków
• Usługi e-commerce
• Usługi bankowości detalicznej
• Usługi transportowe (strony internetowe, aplikacje mobilne, bilety elektroniczne)
• Usługi dostępu do treści audiowizualnych.

• Termin wdrożenia: Państwa członkowskie miały czas na transpozycję dyrektywy do prawa krajowego do 28 czerwca 2022 roku, a podmioty gospodarcze objęte regulacją muszą stosować nowe przepisy od 28 czerwca 2025 roku.
• Związek z WCAG: Podobnie jak dyrektywa dotycząca sektora publicznego, EAA nie wymienia bezpośrednio standardu WCAG w swoim tekście. Zamiast tego, określa funkcjonalne wymogi dostępności, które są w pełni zbieżne z czterema zasadami WCAG (POUR). Zgodność z dyrektywą jest osiągana poprzez spełnienie wymagań zharmonizowanej normy europejskiej EN 301 549. Norma ta z kolei wprost odwołuje się do kryteriów WCAG 2.1 na poziomie AA jako technicznej podstawy do oceny zgodności stron internetowych i aplikacji mobilnych.

Obserwujemy postępującą konwergencję standardów technicznych i wymogów prawnych na skalę międzynarodową. Proces ten przekształca dostępność cyfrową z niszowej specjalizacji technicznej w fundamentalny element ładu korporacyjnego (governance) i zarządzania ryzykiem. Globalny standard techniczny (WCAG), tworzony przez międzynarodowe konsorcjum (W3C), staje się podstawą dla dyrektyw unijnych, które następnie są implementowane do porządku prawnego poszczególnych państw członkowskich, jak w przypadku polskiej ustawy. Najnowszy etap tej ewolucji, czyli Europejski Akt o Dostępności, rozszerza te same zasady na cały jednolity rynek europejski w sektorze prywatnym. Dla firm, zwłaszcza tych działających na skalę międzynarodową, oznacza to, że dostępność nie może być już traktowana jako lokalny problem do rozwiązania. Konieczne staje się opracowanie i wdrożenie scentralizowanej, spójnej strategii zgodności, opartej na najwyższym wspólnym mianowniku, jakim jest standard WCAG (optymalnie w jego najnowszej, najbardziej kompletnej wersji). Ignorowanie tego globalnego trendu stanowi nie tylko ryzyko prawne w jednym kraju, ale fundamentalne ryzyko operacyjne i reputacyjne na całym rynku Unii Europejskiej.

Kompletny Przegląd Kryteriów Sukcesu WCAG (Wersje 2.0, 2.1 i 2.2)

Poniższa sekcja stanowi wyczerpujące kompendium wszystkich kryteriów sukcesu zawartych w wersjach WCAG 2.0, 2.1 i 2.2. Zostały one usystematyzowane zgodnie z oficjalną architekturą standardu, tj. według czterech zasad (Postrzegalność, Funkcjonalność, Zrozumiałość, Solidność) oraz przypisanych do nich wytycznych. Przy każdym kryterium wskazano jego numer, nazwę, poziom zgodności (A, AA, AAA) oraz wersję WCAG, w której zostało wprowadzone.

Zasada 1: Postrzegalność

Informacje i komponenty interfejsu muszą być przedstawione użytkownikom w sposób dostrzegalny dla ich zmysłów.

Wytyczna 1.1 Alternatywa tekstowa

Zapewnij tekstowe zamienniki wszystkich treści nietekstowych, aby można je było zamienić na inne formy (np. powiększony druk, brajl, mowa syntetyczna, symbole lub prostszy język).

• 1.1.1 Treść nietekstowa

• Poziom: A
• Wersja WCAG: 2.0
• Opis i Cel: To fundamentalne kryterium wymaga, aby każda treść nietekstowa prezentowana użytkownikowi (np. zdjęcie, ikona, wykres, grafika) posiadała swoją tekstową alternatywę, która pełni tę samą funkcję. Najczęstszym przykładem jest atrybut alt dla obrazów. Celem jest umożliwienie osobom, które nie mogą zobaczyć treści wizualnej (np. niewidomym korzystającym z czytników ekranu), zrozumienie jej znaczenia i celu. Kryterium określa wyjątki: dla elementów interfejsu (np. przycisków graficznych) alternatywa tekstowa powinna opisywać ich funkcję; dla treści czysto dekoracyjnych alternatywa powinna być pusta, aby technologie asystujące mogły ją zignorować; a dla testów typu CAPTCHA należy zapewnić alternatywne formy weryfikacji dostępne dla różnych zmysłów.

Wytyczna 1.2 Media oparte na czasie

Zapewnij rozwiązania alternatywne dla mediów opartych na czasie (audio i wideo).

• 1.2.1 Tylko audio lub tylko wideo (nagranie)

• Poziom: A
• Wersja WCAG: 2.0
• Opis i Cel: Dla nagranych wcześniej materiałów zawierających tylko dźwięk (np. podcast) lub tylko obraz (np. niemy film), należy zapewnić alternatywę. Dla nagrań audio jest to transkrypcja tekstowa. Dla nagrań wideo jest to alternatywa tekstowa (transkrypcja opisująca, co się dzieje) lub audiodeskrypcja. Ma to na celu udostępnienie treści osobom, które nie mogą jej odebrać za pomocą jednego ze zmysłów (np. osobom głuchym lub niewidomym).
• 1.2.2 Napisy rozszerzone (nagranie)

• Poziom: A
• Wersja WCAG: 2.0
• Opis i Cel: Wszystkie nagrane wcześniej materiały wideo zawierające ścieżkę dźwiękową (multimedia zsynchronizowane) muszą posiadać napisy rozszerzone (ang. captions). Napisy te, w odróżnieniu od zwykłych napisów (ang. subtitles), zawierają nie tylko transkrypcję dialogów, ale także opisy ważnych dźwięków (np. „szczekanie psa”, „muzyka napięcia”). Jest to kluczowe dla osób głuchych i słabosłyszących.
• 1.2.3 Audiodeskrypcja lub alternatywa tekstowa dla mediów (nagranie)

• Poziom: A
• Wersja WCAG: 2.0
• Opis i Cel: Dla nagranych wcześniej multimediów zsynchronizowanych należy zapewnić albo audiodeskrypcję, albo alternatywę w postaci pełnej transkrypcji tekstowej (zawierającej zarówno dialogi, jak i opis scen). Audiodeskrypcja to dodatkowa ścieżka dźwiękowa opisująca kluczowe elementy wizualne, które nie wynikają z dialogów. Jest to niezbędne dla osób niewidomych, aby mogły w pełni zrozumieć treść materiału wideo.
• 1.2.4 Napisy rozszerzone (na żywo)

• Poziom: AA
• Wersja WCAG: 2.0
• Opis i Cel: Wymaga zapewnienia napisów rozszerzonych dla wszystkich multimediów nadawanych na żywo (np. transmisji online, webinarów). Jest to odpowiednik kryterium 1.2.2 dla treści transmitowanych w czasie rzeczywistym, kluczowy dla osób głuchych i słabosłyszących.
• 1.2.5 Audiodeskrypcja (nagranie)

• Poziom: AA
• Wersja WCAG: 2.0
• Opis i Cel: To kryterium jest bardziej rygorystyczne niż 1.2.3 (Poziom A). Wymaga ono zapewnienia audiodeskrypcji dla wszystkich nagranych wcześniej treści wideo. Nie dopuszcza już alternatywy w postaci samej transkrypcji tekstowej. Celem jest zapewnienie osobom niewidomym pełnego doświadczenia audiowizualnego.
• 1.2.6 Język migowy (nagranie)

• Poziom: AAA
• Wersja WCAG: 2.0
• Opis i Cel: Wymaga zapewnienia tłumaczenia na język migowy dla wszystkich nagranych wcześniej multimediów zsynchronizowanych. Jest to najwyższy poziom dostępności dla osób głuchych, dla których język migowy jest często pierwszym językiem.
• 1.2.7 Rozszerzona audiodeskrypcja (nagranie)

• Poziom: AAA
• Wersja WCAG: 2.0
• Opis i Cel: Czasami w materiale wideo jest tak mało naturalnych pauz w dialogach, że standardowa audiodeskrypcja nie wystarcza do opisania wszystkich istotnych scen. W takich przypadkach należy zapewnić rozszerzoną audiodeskrypcję, która polega na wstrzymaniu wideo w kluczowych momentach, aby umożliwić odtworzenie dłuższego opisu, a następnie wznowieniu odtwarzania.
• 1.2.8 Alternatywa dla mediów (nagranie)

• Poziom: AAA
• Wersja WCAG: 2.0
• Opis i Cel: Wymaga zapewnienia rozszerzonej, zsynchronizowanej alternatywy dla mediów. Jest to dokument tekstowy, który zawiera transkrypcję dialogów, opis dźwięków oraz opis scen, zsynchronizowany z materiałem wideo. Jest to najbardziej kompleksowa forma alternatywy.
• 1.2.9 Tylko audio (na żywo)

• Poziom: AAA
• Wersja WCAG: 2.0
• Opis i Cel: Wymaga zapewnienia alternatywy dla treści nadawanych na żywo, które składają się wyłącznie z dźwięku (np. radio internetowe). Najczęściej jest to transkrypcja tekstowa tworzona w czasie rzeczywistym (stenotypia).

Wytyczna 1.3 Możliwość adaptacji

Twórz treści, które mogą być prezentowane na różne sposoby (np. w prostszym układzie) bez utraty informacji czy struktury.

• 1.3.1 Informacje i relacje

• Poziom: A
• Wersja WCAG: 2.0
• Opis i Cel: Informacje, struktura i relacje między elementami, które są przekazywane wizualnie, muszą być również możliwe do określenia programowo lub dostępne w formie tekstu. Oznacza to, że należy używać semantycznych znaczników HTML (np. <h1>-<h6> dla nagłówków, <p> dla akapitów, <ul> i <ol> dla list, <table> z odpowiednimi znacznikami dla tabel danych). Dzięki temu technologie asystujące mogą poprawnie zinterpretować strukturę strony i przekazać ją użytkownikowi.
• 1.3.2 Zrozumiała kolejność

• Poziom: A
• Wersja WCAG: 2.0
• Opis i Cel: Jeśli kolejność prezentacji treści ma znaczenie dla jej zrozumienia, musi istnieć możliwość programowego określenia tej kolejności. W praktyce oznacza to, że kolejność elementów w kodzie źródłowym (DOM) powinna być logiczna i odzwierciedlać wizualny układ. Jest to kluczowe dla użytkowników nawigujących za pomocą klawiatury oraz korzystających z czytników ekranu.
• 1.3.3 Właściwości zmysłowe

• Poziom: A
• Wersja WCAG: 2.0
• Opis i Cel: Instrukcje dotyczące obsługi interfejsu nie mogą opierać się wyłącznie na cechach zmysłowych, takich jak kształt, rozmiar, położenie wizualne, orientacja czy dźwięk. Zamiast pisać „Kliknij okrągły przycisk po prawej stronie”, należy napisać „Kliknij przycisk 'Zapisz'”. Jest to niezbędne dla osób, które nie widzą lub inaczej postrzegają interfejs.
• 1.3.4 Orientacja

• Poziom: AA
• Wersja WCAG: 2.1
• Opis i Cel: Nowe w 2.1, wprowadzone z myślą o urządzeniach mobilnych. Treść nie może ograniczać swojego widoku i działania do jednej orientacji ekranu (pionowej lub poziomej), chyba że określona orientacja jest niezbędna (np. w aplikacji do gry na pianinie). Użytkownicy, którzy mają urządzenia zamontowane na stałe (np. na wózku inwalidzkim), mogą nie być w stanie zmienić orientacji.
• 1.3.5 Określenie pożądanej wartości

• Poziom: AA
• Wersja WCAG: 2.1
• Opis i Cel: Nowe w 2.1, mające na celu wsparcie osób z niepełnosprawnościami poznawczymi. Cel każdego pola formularza zbierającego informacje o użytkowniku powinien być możliwy do określenia programowo. W praktyce osiąga się to poprzez użycie atrybutu autocomplete z odpowiednimi wartościami (np. name, email, tel). Umożliwia to przeglądarkom i technologiom asystującym automatyczne uzupełnianie formularzy, co jest ogromnym ułatwieniem dla osób z trudnościami w pisaniu lub zapamiętywaniu.
• 1.3.6 Określenie przeznaczenia

• Poziom: AAA
• Wersja WCAG: 2.1
• Opis i Cel: Nowe w 2.1. Rozszerza ideę z 1.3.5. Przeznaczenie komponentów interfejsu, ikon i regionów strony powinno być możliwe do określenia programowo przy użyciu technologii takich jak WAI-ARIA (np. atrybuty role). Umożliwia to technologiom asystującym i narzędziom personalizującym przedstawienie interfejsu w inny, bardziej zrozumiały dla danego użytkownika sposób (np. zastępując tekst ikonami).

Wytyczna 1.4 Rozróżnialność

Ułatwiaj oglądanie i słuchanie treści oraz oddzielanie informacji od tła.

• 1.4.1 Użycie koloru

• Poziom: A
• Wersja WCAG: 2.0
• Opis i Cel: Kolor nie może być jedynym wizualnym sposobem przekazywania informacji, wskazywania akcji, proszenia o odpowiedź lub wyróżniania elementu. Na przykład, błędy w formularzu nie mogą być sygnalizowane tylko czerwoną ramką pola – musi im towarzyszyć ikona lub komunikat tekstowy. Jest to kluczowe dla osób z daltonizmem oraz dla użytkowników, którzy mogą nie dostrzegać kolorów.
• 1.4.2 Kontrola odtwarzania dźwięku

• Poziom: A
• Wersja WCAG: 2.0
• Opis i Cel: Jeśli na stronie automatycznie odtwarzany jest dźwięk trwający dłużej niż 3 sekundy, musi istnieć mechanizm pozwalający go zatrzymać, wstrzymać lub regulować jego głośność niezależnie od głośności systemu. Automatycznie odtwarzany dźwięk może zakłócać działanie czytników ekranu i być bardzo dezorientujący dla wielu użytkowników.
• 1.4.3 Kontrast (minimalny)

• Poziom: AA
• Wersja WCAG: 2.0
• Opis i Cel: Wizualna prezentacja tekstu i obrazów tekstu musi mieć współczynnik kontrastu co najmniej 4.5:1. Wyjątki dotyczą dużego tekstu (co najmniej 18 pt lub 14 pt pogrubiony), dla którego wymagany jest kontrast 3:1, oraz tekstu w logotypach i elementach nieaktywnych. Wysoki kontrast jest niezbędny dla osób słabowidzących.
• 1.4.4 Zmiana rozmiaru tekstu

• Poziom: AA
• Wersja WCAG: 2.0
• Opis i Cel: Musi być możliwe powiększenie tekstu do 200% bez użycia technologii asystujących i bez utraty treści lub funkcjonalności. Oznacza to, że strona powinna być zaprojektowana w sposób elastyczny (responsywny), aby po powiększeniu czcionki tekst nie wychodził poza kontenery i nie nakładał się na inne elementy.
• 1.4.5 Obrazy tekstu

• Poziom: AA
• Wersja WCAG: 2.0
• Opis i Cel: Należy unikać używania obrazów do prezentacji tekstu. Zamiast tego należy używać rzeczywistego tekstu (stylowanego za pomocą CSS). Obrazy tekstu nie skalują się dobrze, nie mogą być dostosowywane przez użytkownika (np. zmiana kolorów) i są niedostępne, jeśli nie mają odpowiedniej alternatywy tekstowej. Wyjątki dopuszczają obrazy tekstu, gdy dana prezentacja jest niezbędna (np. w logotypie) lub gdy obraz można dostosować.
• 1.4.6 Kontrast (wzmocniony)

• Poziom: AAA
• Wersja WCAG: 2.0
• Opis i Cel: Jest to bardziej rygorystyczna wersja kryterium 1.4.3. Wymaga współczynnika kontrastu co najmniej 7:1 dla normalnego tekstu i 4.5:1 dla dużego tekstu. Zapewnia to czytelność dla jeszcze szerszej grupy osób z poważnymi wadami wzroku.
• 1.4.7 Niska głośność lub bez dźwięków w tle

• Poziom: AAA
• Wersja WCAG: 2.0
• Opis i Cel: W nagraniach audio, gdzie główną treścią jest mowa, dźwięki w tle muszą być albo nieobecne, albo możliwe do wyłączenia, albo co najmniej o 20 decybeli cichsze od mowy. Ułatwia to zrozumienie treści osobom słabosłyszącym.
• 1.4.8 Prezentacja wizualna

• Poziom: AAA
• Wersja WCAG: 2.0
• Opis i Cel: Wymaga zapewnienia mechanizmów, które pozwalają użytkownikowi na pełne dostosowanie prezentacji tekstu: zmianę koloru tekstu i tła, ustawienie szerokości bloku tekstu na maksymalnie 80 znaków, wyłączenie justowania, ustawienie interlinii na co najmniej 1.5 i odstępów między akapitami na co najmniej 1.5 razy większe niż interlinia, oraz możliwość powiększenia tekstu do 200% bez konieczności przewijania w poziomie.
• 1.4.9 Obrazy tekstu (bez wyjątków)

• Poziom: AAA
• Wersja WCAG: 2.0
• Opis i Cel: Zaostrza kryterium 1.4.5, stwierdzając, że obrazy tekstu mogą być używane tylko w celach czysto dekoracyjnych lub gdy konkretna prezentacja tekstu jest absolutnie niezbędna do przekazania informacji (np. historyczny dokument).
• 1.4.10 Dopasowanie do ekranu (Reflow)

• Poziom: AA
• Wersja WCAG: 2.1
• Opis i Cel: Nowe w 2.1. Treść musi być prezentowana bez utraty informacji i funkcjonalności oraz bez konieczności przewijania w dwóch wymiarach. Oznacza to, że przy powiększeniu widoku do 400%, strona powinna przeformatować się do jednej kolumny, wymagając jedynie przewijania w pionie. Jest to niezwykle ważne dla osób słabowidzących, które muszą znacznie powiększać treść, aby ją przeczytać.
• 1.4.11 Kontrast elementów nietekstowych

• Poziom: AA
• Wersja WCAG: 2.1
• Opis i Cel: Nowe w 2.1. Rozszerza wymagania dotyczące kontrastu na elementy interfejsu użytkownika (np. obramowania przycisków, kontury pól formularzy) oraz istotne części grafik (np. poszczególne słupki na wykresie). Te elementy muszą mieć kontrast co najmniej 3:1 względem sąsiednich kolorów. Ułatwia to identyfikację i obsługę interfejsu osobom słabowidzącym.
• 1.4.12 Odstępy w tekście

• Poziom: AA
• Wersja WCAG: 2.1
• Opis i Cel: Nowe w 2.1. Użytkownik musi mieć możliwość dostosowania odstępów w tekście (interlinia, odstępy między akapitami, literami i słowami) do określonych minimalnych wartości bez utraty treści lub funkcjonalności. Jest to kluczowe dla osób z dysleksją i innymi trudnościami w czytaniu, ponieważ pozwala im dostosować tekst do swoich potrzeb.
• 1.4.13 Treść spod kursora lub fokusu

• Poziom: AA
• Wersja WCAG: 2.1
• Opis i Cel: Nowe w 2.1. Dotyczy dodatkowej treści, która pojawia się po najechaniu kursorem lub otrzymaniu fokusu (np. dymki z podpowiedziami, rozwijane menu). Taka treść musi być: (1) możliwa do zamknięcia bez przesuwania kursora/fokusu, (2) możliwa do najechania na nią kursorem (aby np. skopiować z niej tekst), oraz (3) widoczna tak długo, jak użytkownik utrzymuje kursor/fokus. Rozwiązuje to problemy osób słabowidzących (które muszą powiększyć treść dymka) i osób z ograniczeniami motorycznymi.

Zasada 2: Funkcjonalność

Zapewnij, aby komponenty interfejsu użytkownika i nawigacja były możliwe do użycia.

Wytyczna 2.1 Dostępność z klawiatury

Zapewnij dostępność wszystkich funkcjonalności za pomocą klawiatury.

• 2.1.1 Klawiatura

• Poziom: A
• Wersja WCAG: 2.0
• Opis i Cel: Wszystkie funkcjonalności dostępne za pomocą myszy muszą być również możliwe do obsłużenia za pomocą klawiatury. Jest to jedno z najważniejszych kryteriów dostępności, kluczowe dla osób niewidomych oraz osób z niepełnosprawnościami ruchowymi, które nie mogą używać myszy.
• 2.1.2 Bez pułapki na klawiaturę

• Poziom: A
• Wersja WCAG: 2.0
• Opis i Cel: Jeśli fokus klawiatury można przenieść na dany element, musi być również możliwe jego opuszczenie przy użyciu samej klawiatury (np. klawiszem Tab lub Esc). Niektóre widżety (np. okna modalne) mogą „więzić” fokus, uniemożliwiając użytkownikowi klawiatury powrót do reszty strony. Takie pułapki czynią stronę bezużyteczną.
• 2.1.3 Klawiatura (bez wyjątków)

• Poziom: AAA
• Wersja WCAG: 2.0
• Opis i Cel: Zaostrza kryterium 2.1.1, usuwając wyjątek dotyczący funkcji, które wymagają ścieżki ruchu (np. rysowanie odręczne). Wymaga, aby absolutnie każda funkcjonalność była dostępna z klawiatury.
• 2.1.4 Jednoznakowe skróty klawiaturowe

• Poziom: A
• Wersja WCAG: 2.1
• Opis i Cel: Nowe w 2.1. Jeśli na stronie zaimplementowano skróty klawiaturowe używające pojedynczych znaków (liter, cyfr, znaków interpunkcyjnych), musi istnieć mechanizm, aby je wyłączyć, zmienić (np. dodać klawisz modyfikujący jak Ctrl) lub aktywować tylko wtedy, gdy dany komponent ma fokus. Jest to ważne dla użytkowników technologii sterowanych głosem, którzy mogą przypadkowo aktywować skróty, dyktując tekst.

Wytyczna 2.2 Wystarczający czas

Zapewnij użytkownikom wystarczająco dużo czasu na przeczytanie i skorzystanie z treści.

• 2.2.1 Dostosowanie czasu

• Poziom: A
• Wersja WCAG: 2.0
• Opis i Cel: Jeśli na stronie istnieje limit czasu na wykonanie akcji (np. wypełnienie formularza, sesja logowania), użytkownik musi mieć możliwość jego wyłączenia, dostosowania lub przedłużenia. Osoby z niepełnosprawnościami (np. poznawczymi, ruchowymi, wzrokowymi) często potrzebują więcej czasu na interakcję z treścią.
• 2.2.2 Pauza, zatrzymanie, ukrycie

• Poziom: A
• Wersja WCAG: 2.0
• Opis i Cel: Dla wszelkich treści poruszających się, migających lub przewijających się, które uruchamiają się automatycznie i trwają dłużej niż 5 sekund, musi istnieć mechanizm pozwalający je zatrzymać, wstrzymać lub ukryć. Dotyczy to również treści aktualizujących się automatycznie. Ruchome treści mogą być bardzo rozpraszające, zwłaszcza dla osób z zaburzeniami uwagi.
• 2.2.3 Bez ograniczeń czasowych

• Poziom: AAA
• Wersja WCAG: 2.0
• Opis i Cel: Czas nie jest istotną częścią czynności, chyba że jest to absolutnie konieczne (np. w aukcji na żywo). To kryterium promuje projektowanie bez narzucania użytkownikom presji czasu.
• 2.2.4 Przerywanie

• Poziom: AAA
• Wersja WCAG: 2.0
• Opis i Cel: Użytkownik musi mieć możliwość odroczenia lub wyłączenia przerw w pracy (np. wyskakujących powiadomień), chyba że jest to sytuacja wyjątkowa (np. alarm). Jest to ważne dla utrzymania koncentracji.
• 2.2.5 Ponowne potwierdzenie autentyczności

• Poziom: AAA
• Wersja WCAG: 2.0
• Opis i Cel: Gdy wygasa sesja uwierzytelnienia, użytkownik musi mieć możliwość kontynuowania swojej czynności bez utraty danych po ponownym zalogowaniu. Zapobiega to frustracji i utracie pracy.
• 2.2.6 Ostrzeżenie o limicie czasu

• Poziom: AAA
• Wersja WCAG: 2.1
• Opis i Cel: Nowe w 2.1. Użytkownik musi być ostrzeżony o czasie nieaktywności, który może spowodować utratę danych. Wymóg ten dotyczy sytuacji, gdy dane są przechowywane przez ponad 20 godzin.

Wytyczna 2.3 Ataki padaczki i reakcje fizyczne

Prezentuj treść tak, aby nie wywoływała napadów padaczkowych ani innych reakcji fizycznych.

• 2.3.1 Trzy błyski lub wartości poniżej progu

• Poziom: A
• Wersja WCAG: 2.0
• Opis i Cel: Strony internetowe nie mogą zawierać niczego, co błyska częściej niż trzy razy na sekundę, lub błysk musi być poniżej ogólnych i czerwonych progów błysków. Ma to na celu zapobieganie napadom padaczki fotogennej.
• 2.3.2 Trzy błyski

• Poziom: AAA
• Wersja WCAG: 2.0
• Opis i Cel: Bardziej rygorystyczna wersja, która całkowicie zabrania treści błyskających częściej niż trzy razy na sekundę, bez żadnych wyjątków dotyczących progów.
• 2.3.3 Animacja po interakcji

• Poziom: AAA
• Wersja WCAG: 2.1
• Opis i Cel: Nowe w 2.1. Animacje wyzwalane przez interakcję użytkownika (np. efekty paralaksy podczas przewijania) muszą być możliwe do wyłączenia, chyba że animacja jest niezbędna dla funkcjonalności. Jest to ważne dla osób z zaburzeniami przedsionkowymi, u których takie animacje mogą wywoływać zawroty głowy i nudności.

Wytyczna 2.4 Możliwość nawigacji

Zapewnij użytkownikowi narzędzia pomagające w nawigacji, znalezieniu treści i określeniu, gdzie się aktualnie znajduje.

• 2.4.1 Możliwość pominięcia bloków

• Poziom: A
• Wersja WCAG: 2.0
• Opis i Cel: Musi istnieć mechanizm pozwalający pominąć bloki treści, które powtarzają się na wielu stronach (np. menu nawigacyjne, nagłówek). Najczęściej jest to tzw. „skip link” (link „przejdź do treści”), widoczny po otrzymaniu fokusu. Jest to kluczowe dla użytkowników klawiatury, którzy w przeciwnym razie musieliby za każdym razem przechodzić przez dziesiątki linków nawigacyjnych, aby dotrzeć do głównej treści strony.
• 2.4.2 Tytuły stron

• Poziom: A
• Wersja WCAG: 2.0
• Opis i Cel: Każda strona internetowa musi mieć tytuł (w znaczniku <title>), który opisuje jej temat lub cel. Tytuły stron są pierwszą informacją, jaką odczytuje czytnik ekranu, i pomagają wszystkim użytkownikom orientować się w otwartych kartach przeglądarki.
• 2.4.3 Kolejność fokusu

• Poziom: A
• Wersja WCAG: 2.0
• Opis i Cel: Jeśli kolejność nawigacji po stronie ma znaczenie, elementy interaktywne muszą otrzymywać fokus w logicznej i przewidywalnej kolejności. Zazwyczaj oznacza to, że kolejność fokusu (osiągana klawiszem Tab) powinna podążać za wizualnym układem strony (od lewej do prawej, od góry do dołu).
• 2.4.4 Cel łącza (w kontekście)

• Poziom: A
• Wersja WCAG: 2.0
• Opis i Cel: Cel każdego linku musi być zrozumiały z samego tekstu linku lub z jego bezpośredniego kontekstu (np. komórki tabeli, zdania, w którym się znajduje). Należy unikać niejednoznacznych tekstów linków, takich jak „kliknij tutaj” czy „więcej”. Zrozumiałe linki pomagają wszystkim użytkownikom, a w szczególności użytkownikom czytników ekranu, którzy często nawigują po stronie, listując same linki.
• 2.4.5 Wiele dróg

• Poziom: AA
• Wersja WCAG: 2.0
• Opis i Cel: Musi istnieć więcej niż jeden sposób na zlokalizowanie danej podstrony w ramach serwisu, np. poprzez menu nawigacyjne, mapę strony lub wyszukiwarkę. Ułatwia to użytkownikom znalezienie potrzebnych informacji w sposób, który jest dla nich najwygodniejszy.
• 2.4.6 Nagłówki i etykiety

• Poziom: AA
• Wersja WCAG: 2.0
• Opis i Cel: Nagłówki (<h1>-<h6>) i etykiety (np. dla pól formularzy) muszą opisywać temat lub cel treści, którą wprowadzają. Dobre nagłówki tworzą logiczny szkielet strony, ułatwiając jej skanowanie i nawigację, zwłaszcza użytkownikom technologii asystujących.
• 2.4.7 Widoczny fokus

• Poziom: AA
• Wersja WCAG: 2.0
• Opis i Cel: Każdy element interfejsu, który można obsłużyć za pomocą klawiatury, musi mieć wyraźnie widoczny wskaźnik fokusu (np. obramowanie, zmianę tła). Użytkownicy klawiatury muszą wiedzieć, na którym elemencie aktualnie się znajdują, aby móc wejść z nim w interakcję. Domyślne wskaźniki fokusu przeglądarek są często usuwane przez deweloperów ze względów estetycznych, co jest poważnym błędem dostępności.
• 2.4.8 Lokalizacja

• Poziom: AAA
• Wersja WCAG: 2.0
• Opis i Cel: Musi być dostępna informacja o tym, gdzie użytkownik znajduje się w zestawie stron internetowych (np. za pomocą „okruszków” – breadcrumbs). Pomaga to w orientacji w złożonych serwisach.
• 2.4.9 Cel łącza (z samego łącza)

• Poziom: AAA
• Wersja WCAG: 2.0
• Opis i Cel: Zaostrza kryterium 2.4.4. Cel każdego linku musi być zrozumiały z samego jego tekstu, bez potrzeby analizowania kontekstu. Zamiast „Więcej o naszych usługach”, link powinien brzmieć „Przeczytaj o naszych usługach marketingowych”.
• 2.4.10 Nagłówki sekcji

• Poziom: AAA
• Wersja WCAG: 2.0
• Opis i Cel: Sekcje treści powinny być zorganizowane za pomocą nagłówków. Jest to rozszerzenie idei kryterium 2.4.6, promujące dobrą strukturę dokumentu.
• 2.4.11 Fokus niezasłonięty (minimum)

• Poziom: AA
• Wersja WCAG: 2.2
• Opis i Cel: Nowe w 2.2. Kiedy element otrzymuje fokus klawiatury, nie może być całkowicie zasłonięty przez inną treść stworzoną przez autora (np. przyklejone do ekranu banery, nagłówki, stopki czy okna z czatem). Co najmniej część wskaźnika fokusu musi być widoczna. Rozwiązuje to częsty problem, gdy użytkownik klawiatury „traci” fokus za nieprzewijalnym elementem.
• 2.4.12 Fokus niezasłonięty (wzmocnione)

• Poziom: AAA
• Wersja WCAG: 2.2
• Opis i Cel: Nowe w 2.2. Jest to bardziej rygorystyczna wersja kryterium 2.4.11. Wymaga, aby element, który otrzymał fokus, był w pełni widoczny i żadna jego część nie była zasłonięta.
• 2.4.13 Wygląd fokusu

• Poziom: AAA
• Wersja WCAG: 2.2
• Opis i Cel: Nowe w 2.2. Określa minimalne wymagania dotyczące wyglądu wskaźnika fokusu. Musi on mieć odpowiedni kontrast (3:1) i grubość (co najmniej 2px dla obramowania). Ma to na celu zapewnienie, że wskaźnik fokusu jest łatwo dostrzegalny dla osób słabowidzących.

Wytyczna 2.5 Metody obsługi

Ułatwiaj użytkownikom obsługę funkcjonalności za pomocą różnych metod wprowadzania danych, a nie tylko klawiatury.

• 2.5.1 Gesty dotykowe

• Poziom: A
• Wersja WCAG: 2.1
• Opis i Cel: Nowe w 2.1, kluczowe dla urządzeń mobilnych. Wszystkie funkcje, które wykorzystują złożone gesty (np. przeciąganie, szczypanie w celu powiększenia), muszą być również możliwe do obsłużenia za pomocą prostych gestów (pojedyncze dotknięcie, długie naciśnięcie). Osoby z ograniczeniami motorycznymi mogą nie być w stanie wykonać skomplikowanych gestów.
• 2.5.2 Rezygnacja ze wskazania

• Poziom: A
• Wersja WCAG: 2.1
• Opis i Cel: Nowe w 2.1. Dotyczy interakcji z elementami. Akcja nie powinna być wyzwalana w momencie naciśnięcia (down-event), ale w momencie zwolnienia (up-event). Daje to użytkownikowi możliwość anulowania akcji poprzez przesunięcie palca/kursora poza element przed jego zwolnieniem. Zapobiega to przypadkowym aktywacjom, co jest ważne dla osób z drżeniem rąk lub innymi problemami motorycznymi.
• 2.5.3 Etykieta w nazwie

• Poziom: A
• Wersja WCAG: 2.1
• Opis i Cel: Nowe w 2.1. Dla komponentów interfejsu, które mają widoczną tekstową etykietę, dostępna programowo nazwa (tzw. accessible name) musi zawierać tekst tej etykiety. Na przykład, jeśli przycisk ma widoczny tekst „Zapisz dane”, jego nazwa dostępna dla czytnika ekranu (np. w aria-label) musi również zawierać frazę „Zapisz dane”. Jest to kluczowe dla użytkowników sterowania głosowego, którzy aktywują elementy, wymawiając ich widoczną etykietę.
• 2.5.4 Aktywowanie ruchem

• Poziom: A
• Wersja WCAG: 2.1
• Opis i Cel: Nowe w 2.1. Jeśli funkcja może być aktywowana przez ruch urządzenia (np. potrząśnięcie, aby cofnąć), musi istnieć również alternatywny sposób jej aktywacji za pomocą komponentu interfejsu (np. przycisku). Dodatkowo, musi być możliwość wyłączenia aktywacji ruchem, aby zapobiec przypadkowym działaniom.
• 2.5.5 Rozmiar celu dotykowego

• Poziom: AAA
• Wersja WCAG: 2.1
• Opis i Cel: Nowe w 2.1. Wymaga, aby rozmiar celu dla wskaźnika (np. przycisku, linku) wynosił co najmniej 44 na 44 piksele CSS. Ułatwia to trafienie w cel osobom z ograniczeniami motorycznymi oraz wszystkim użytkownikom urządzeń dotykowych.
• 2.5.6 Równoległe mechanizmy wprowadzania danych

• Poziom: AAA
• Wersja WCAG: 2.1
• Opis i Cel: Nowe w 2.1. Treść internetowa nie może ograniczać użycia różnych metod wprowadzania danych dostępnych na platformie (np. klawiatura ekranowa, zewnętrzna, dyktowanie głosowe), chyba że jest to niezbędne ze względów bezpieczeństwa.
• 2.5.7 Ruchy przeciągania

• Poziom: AA
• Wersja WCAG: 2.2
• Opis i Cel: Nowe w 2.2. Jeśli funkcjonalność wymaga od użytkownika przeciągania elementów (np. sortowanie listy, suwak), musi istnieć alternatywny, prostszy sposób jej obsługi za pomocą pojedynczego wskaźnika (np. kliknięcia przycisków „w górę”/”w dół”). Przeciąganie jest trudne lub niemożliwe dla wielu osób z niepełnosprawnościami motorycznymi.
• 2.5.8 Rozmiar celu (minimum)

• Poziom: AA
• Wersja WCAG: 2.2
• Opis i Cel: Nowe w 2.2. Jest to wersja kryterium 2.5.5 na poziomie AA. Wymaga, aby rozmiar celu dla wskaźnika wynosił co najmniej 24 na 24 piksele CSS. Jest to mniejszy wymóg niż w wersji AAA, ale stanowi znaczącą poprawę dostępności, zwłaszcza na urządzeniach mobilnych. Kryterium dopuszcza wyjątki, np. gdy cele są odpowiednio oddalone od siebie.

Zasada 3: Zrozumiałość

Zadbaj o to, aby informacje i obsługa interfejsu były zrozumiałe.

Wytyczna 3.1 Możliwość odczytania

Twórz treści możliwe do odczytania i zrozumienia.

• 3.1.1 Język strony

• Poziom: A
• Wersja WCAG: 2.0
• Opis i Cel: Domyślny język naturalny każdej strony internetowej musi być określony programowo (za pomocą atrybutu lang w znaczniku <html>). Pozwala to przeglądarkom i czytnikom ekranu poprawnie wyświetlać znaki i stosować odpowiednią syntezę mowy.
• 3.1.2 Język części

• Poziom: AA
• Wersja WCAG: 2.0
• Opis i Cel: Jeśli na stronie występują fragmenty w innym języku niż główny, ich język również musi być określony programowo (za pomocą atrybutu lang na odpowiednim elemencie). Dzięki temu czytnik ekranu może przełączyć się na syntezator mowy z poprawnym akcentem i wymową.
• 3.1.3 Nietypowe słowa

• Poziom: AAA
• Wersja WCAG: 2.0
• Opis i Cel: Musi istnieć mechanizm (np. link do słowniczka) pozwalający sprawdzić definicje słów użytych w nietypowy lub specjalistyczny sposób, w tym idiomów i żargonu. Ułatwia to zrozumienie treści osobom z niepełnosprawnościami poznawczymi.
• 3.1.4 Skróty

• Poziom: AAA
• Wersja WCAG: 2.0
• Opis i Cel: Musi istnieć mechanizm pozwalający sprawdzić rozwinięcie skrótów (np. za pomocą znacznika <abbr>). Czytniki ekranu mogą wtedy odczytać pełną formę, co ułatwia zrozumienie.
• 3.1.5 Poziom umiejętności czytania

• Poziom: AAA
• Wersja WCAG: 2.0
• Opis i Cel: Jeśli tekst wymaga umiejętności czytania na poziomie wyższym niż gimnazjalny, należy zapewnić wersję alternatywną lub uzupełniającą, napisaną prostszym językiem. Jest to kluczowe dla osób z trudnościami w czytaniu i niepełnosprawnościami poznawczymi.
• 3.1.6 Wymowa

• Poziom: AAA
• Wersja WCAG: 2.0
• Opis i Cel: Musi istnieć mechanizm pozwalający sprawdzić poprawną wymowę słów, których znaczenie zależy od wymowy (np. homografy). Jest to pomocne dla osób korzystających z syntezatorów mowy.

Wytyczna 3.2 Przewidywalność

Twórz strony internetowe tak, aby otwierały się, wyglądały i działały w sposób przewidywalny.

• 3.2.1 Po otrzymaniu fokusu

• Poziom: A
• Wersja WCAG: 2.0
• Opis i Cel: Samo przeniesienie fokusu na element interfejsu (np. za pomocą klawisza Tab) nie może powodować nieoczekiwanej zmiany kontekstu (np. automatycznego przesłania formularza, otwarcia nowego okna). Takie nieprzewidywalne zachowania są bardzo dezorientujące, zwłaszcza dla użytkowników klawiatury i czytników ekranu.
• 3.2.2 Podczas wprowadzania danych

• Poziom: A
• Wersja WCAG: 2.0
• Opis i Cel: Zmiana ustawienia komponentu (np. zaznaczenie pola wyboru, wybór opcji z listy) nie może automatycznie powodować zmiany kontekstu, chyba że użytkownik został o tym uprzedzony. Użytkownik powinien mieć kontrolę i sam inicjować akcje, np. klikając przycisk „Wyślij”.
• 3.2.3 Spójna nawigacja

• Poziom: AA
• Wersja WCAG: 2.0
• Opis i Cel: Mechanizmy nawigacyjne, które powtarzają się na wielu stronach serwisu (np. główne menu), muszą pojawiać się w tej samej względnej kolejności za każdym razem. Spójność ułatwia naukę obsługi serwisu i orientację.
• 3.2.4 Spójna identyfikacja

• Poziom: AA
• Wersja WCAG: 2.0
• Opis i Cel: Komponenty, które mają tę samą funkcjonalność w całym serwisie, muszą być identyfikowane w spójny sposób (np. ta sama ikona i tekst dla koszyka na zakupy na każdej stronie). Zwiększa to przewidywalność i zmniejsza obciążenie poznawcze.
• 3.2.5 Zmiana na żądanie

• Poziom: AAA
• Wersja WCAG: 2.0
• Opis i Cel: Zmiany kontekstu mogą być inicjowane tylko na wyraźne żądanie użytkownika, lub musi istnieć mechanizm pozwalający je wyłączyć. Daje to użytkownikowi pełną kontrolę nad interfejsem.
• 3.2.6 Spójna pomoc

• Poziom: A
• Wersja WCAG: 2.2
• Opis i Cel: Nowe w 2.2. Jeśli na stronie dostępne są mechanizmy pomocy (np. link do FAQ, numer telefonu, czat), i powtarzają się one na wielu stronach, muszą być umieszczone w spójnym miejscu. Ułatwia to użytkownikom, zwłaszcza tym z niepełnosprawnościami poznawczymi, szybkie znalezienie pomocy, gdy jej potrzebują.

Wytyczna 3.3 Pomoc przy wprowadzaniu informacji

Pomagaj użytkownikom unikać błędów i je korygować.

• 3.3.1 Identyfikacja błędu

• Poziom: A
• Wersja WCAG: 2.0
• Opis i Cel: Jeśli system wykryje błąd wprowadzania danych w formularzu, musi zidentyfikować błędne pole i opisać błąd w formie tekstowej. Nie wystarczy pokolorować pole na czerwono. Użytkownik musi otrzymać jasny komunikat, np. „Pole 'Adres e-mail’ jest wymagane”.
• 3.3.2 Etykiety lub instrukcje

• Poziom: A
• Wersja WCAG: 2.0
• Opis i Cel: Gdy treść wymaga od użytkownika wprowadzenia danych, muszą być dostępne etykiety lub instrukcje. Każde pole formularza powinno mieć widoczną i programowo powiązaną etykietę (za pomocą znacznika <label>). Dzięki temu użytkownicy, w tym ci korzystający z czytników ekranu, wiedzą, jakie dane należy wprowadzić w danym polu.
• 3.3.3 Sugestie korekty błędów

• Poziom: AA
• Wersja WCAG: 2.0
• Opis i Cel: Jeśli błąd jest wykrywany automatycznie i znane są sugestie jego poprawy, należy je przedstawić użytkownikowi. Na przykład, przy błędnie wpisanym adresie e-mail, system może zasugerować: „Czy chodziło Ci o 'example@domain.com’?”.
• 3.3.4 Zapobieganie błędom (prawnym, finansowym, w danych)

• Poziom: AA
• Wersja WCAG: 2.0
• Opis i Cel: Dla stron, na których użytkownik podejmuje zobowiązania prawne, przeprowadza transakcje finansowe lub modyfikuje dane, musi istnieć mechanizm zapobiegania błędom. Może to być możliwość cofnięcia akcji, sprawdzenie danych przez użytkownika przed ostatecznym zatwierdzeniem, lub prośba o potwierdzenie.
• 3.3.5 Pomoc

• Poziom: AAA
• Wersja WCAG: 2.0
• Opis i Cel: Należy zapewnić pomoc kontekstową. Oznacza to dostarczanie instrukcji i wskazówek w miejscu, w którym są one potrzebne, a nie tylko na osobnej stronie pomocy.
• 3.3.6 Zapobieganie błędom (wszystkim)

• Poziom: AAA
• Wersja WCAG: 2.0
• Opis i Cel: Rozszerza kryterium 3.3.4 na wszystkie sytuacje, w których użytkownik wprowadza dane, a nie tylko te o skutkach prawnych czy finansowych.
• 3.3.7 Zbędne wprowadzanie danych

• Poziom: A
• Wersja WCAG: 2.2
• Opis i Cel: Nowe w 2.2. Informacje, które użytkownik już raz wprowadził w ramach tego samego procesu, nie powinny być wymagane ponownie. Powinny być one automatycznie uzupełniane lub dostępne do wyboru. Zmniejsza to obciążenie poznawcze i wysiłek, co jest szczególnie pomocne dla osób z problemami z pamięcią lub trudnościami motorycznymi.
• 3.3.8 Dostępne uwierzytelnianie (minimum)

• Poziom: AA
• Wersja WCAG: 2.2
• Opis i Cel: Nowe w 2.2. Proces uwierzytelniania nie może opierać się wyłącznie na teście funkcji poznawczych, takim jak zapamiętywanie hasła, transkrypcja znaków czy rozwiązywanie zagadek. Musi istnieć alternatywna, łatwiejsza metoda (np. logowanie przez e-mail, biometria) lub mechanizm pomocy (np. menedżer haseł). Wyjątki dotyczą rozpoznawania obiektów lub treści dostarczonych przez użytkownika. Ułatwia to logowanie osobom z dysleksją, problemami z pamięcią i innymi niepełnosprawnościami poznawczymi.
• 3.3.9 Dostępne uwierzytelnianie (wzmocnione)

• Poziom: AAA
• Wersja WCAG: 2.2
• Opis i Cel: Nowe w 2.2. Zaostrza poprzednie kryterium, eliminując wyjątki dotyczące rozpoznawania obiektów lub treści osobistych. Proces uwierzytelniania nie może wymagać testu funkcji poznawczych, chyba że dostępny jest mechanizm pomocy lub metoda alternatywna.

Zasada 4: Solidność (Kompatybilność)

Twórz treści solidnie, aby mogły być skutecznie interpretowane przez różne programy użytkownika, w tym technologie wspomagające.

Wytyczna 4.1 Kompatybilność

Zapewnij jak największą zgodność z aktualnymi i przyszłymi programami użytkownika, w tym z technologiami asystującymi.

• 4.1.1 Poprawność kodu (Parsing) – Usunięte w WCAG 2.2

• Poziom: A
• Wersja WCAG: 2.0
• Opis i Cel: To kryterium, obecne w wersjach 2.0 i 2.1, wymagało, aby kod HTML był poprawny składniowo (m.in. kompletne tagi, poprawne zagnieżdżanie, unikalne ID). Celem było zapewnienie, że technologie asystujące, które kiedyś same parsowały kod, będą mogły go poprawnie zinterpretować. Kryterium to zostało usunięte w WCAG 2.2, ponieważ nowoczesne przeglądarki i technologie asystujące znacznie lepiej radzą sobie z błędami w kodzie, a problemy dostępności wynikające z poważnych błędów składniowych są obecnie pokrywane przez inne kryteria, takie jak 1.3.1 i 4.1.2.
• 4.1.2 Nazwa, rola, wartość

• Poziom: A
• Wersja WCAG: 2.0
• Opis i Cel: Dla wszystkich komponentów interfejsu użytkownika (przycisków, linków, pól formularzy, widżetów) ich nazwa (etykieta), rola (czym jest dany element, np. przyciskiem) oraz stan (np. zaznaczony, rozwinięty) muszą być możliwe do określenia programowo. Umożliwia to technologiom asystującym przekazanie użytkownikowi pełnej informacji o elemencie i umożliwienie interakcji z nim. W praktyce realizuje się to za pomocą standardowych elementów HTML lub, w przypadku złożonych komponentów, za pomocą WAI-ARIA.
• 4.1.3 Komunikaty o stanie

• Poziom: AA
• Wersja WCAG: 2.1
• Opis i Cel: Nowe w 2.1. Komunikaty o stanie (np. „Produkt dodany do koszyka”, „Wyniki wyszukiwania zostały zaktualizowane”), które pojawiają się na stronie bez przeładowania jej i bez przenoszenia na nie fokusu, muszą być możliwe do określenia programowo, aby technologie asystujące mogły je ogłosić użytkownikowi. Realizuje się to najczęściej za pomocą atrybutów ARIA Live Regions (np. role=”status”). Bez tego użytkownik czytnika ekranu może nie zauważyć ważnej zmiany na stronie.

Ewolucja Standardu: Analiza Porównawcza Wersji

Standard WCAG jest dokumentem żywym, który ewoluuje wraz z rozwojem technologii internetowych i pogłębianiem się wiedzy na temat potrzeb użytkowników. Wersje 2.1 i 2.2 nie zastępują poprzednich, lecz je rozszerzają, wprowadzając nowe kryteria sukcesu, które adresują wcześniej niedostatecznie pokryte obszary.

Koncepcja Zgodności Wstecznej

Kluczową cechą architektury WCAG 2.x jest zasada zgodności wstecznej (backward compatibility). Oznacza to, że każda nowsza wersja w pełni zawiera w sobie wszystkie wymagania z wersji poprzednich. Kryteria sukcesu z WCAG 2.0 są obecne i niezmienione w WCAG 2.1, a wszystkie kryteria z WCAG 2.1 (z jednym wyjątkiem) są zawarte w WCAG 2.2. Jedynym usuniętym kryterium jest 4.1.1 Poprawność kodu (Parsing), które w WCAG 2.2 uznano za przestarzałe.

Dzięki takiemu podejściu, strona internetowa lub aplikacja, która jest zgodna z WCAG 2.2 na danym poziomie (np. AA), automatycznie jest również zgodna z WCAG 2.1 i WCAG 2.0 na tym samym poziomie. Upraszcza to proces aktualizacji polityk dostępności i pozwala organizacjom na płynne przechodzenie na nowsze standardy bez konieczności rewidowania już wdrożonych rozwiązań. W3C oficjalnie zachęca do stosowania najnowszej opublikowanej wersji WCAG w celu maksymalizacji korzyści i przygotowania się na przyszłe wymogi prawne.

Główne Kierunki Rozwoju w WCAG 2.1

Wersja WCAG 2.1, opublikowana w 2018 roku, była odpowiedzią na dynamiczne zmiany w sposobie korzystania z internetu, w szczególności na upowszechnienie się urządzeń mobilnych. Wprowadziła 17 nowych kryteriów sukcesu, koncentrując się na trzech głównych obszarach :

1. Dostępność mobilna: Wiele nowych kryteriów bezpośrednio odnosi się do wyzwań związanych z interfejsami dotykowymi i małymi ekranami. Kryteria takie jak 1.3.4 Orientacja, 2.5.1 Gesty dotykowe czy 2.5.5 Rozmiar celu dotykowego (AAA) mają na celu ułatwienie obsługi stron i aplikacji na smartfonach i tabletach, zwłaszcza osobom z ograniczeniami motorycznymi.
2. Potrzeby użytkowników słabowidzących: WCAG 2.1 wprowadziło kluczowe wymagania dla osób z wadami wzroku, które nie są niewidome. Kryterium 1.4.10 Dopasowanie do ekranu (Reflow) zrewolucjonizowało sposób projektowania responsywnego, eliminując konieczność przewijania w poziomie przy dużym powiększeniu. Z kolei 1.4.11 Kontrast elementów nietekstowych i 1.4.12 Odstępy w tekście znacząco poprawiły czytelność interfejsu i tekstu.
3. Wsparcie dla osób z niepełnosprawnościami poznawczymi i w uczeniu się: Choć jest to obszar trudny do standaryzacji, WCAG 2.1 wprowadziło ważne ułatwienia. Kryterium 1.3.5 Określenie pożądanej wartości (użycie atrybutu autocomplete) pomaga w wypełnianiu formularzy, a 2.2.6 Ostrzeżenie o limicie czasu (AAA) redukuje stres związany z presją czasu.

Główne Kierunki Rozwoju w WCAG 2.2

Wersja WCAG 2.2, opublikowana w październiku 2023 roku, kontynuuje ewolucję standardu, dodając 9 nowych kryteriów sukcesu. Koncentrują się one na dalszym usuwaniu barier, zwłaszcza dla użytkowników z niepełnosprawnościami motorycznymi, poznawczymi oraz osób słabowidzących. Główne obszary zmian to:

1. Widoczność fokusu i interaktywność: Nowe kryteria 2.4.11 Fokus niezasłonięty (minimum), 2.4.12 Fokus niezasłonięty (wzmocnione) (AAA) oraz 2.4.13 Wygląd fokusu (AAA) precyzują wymagania dotyczące wskaźnika fokusu klawiatury. Musi on być zawsze (przynajmniej częściowo) widoczny i odpowiednio wyraźny. Jest to fundamentalna poprawa dla wszystkich użytkowników nawigujących za pomocą klawiatury.
2. Ułatwienie interakcji motorycznych: Kryteria 2.5.7 Ruchy przeciągania oraz 2.5.8 Rozmiar celu (minimum) mają na celu zmniejszenie złożoności motorycznej wymaganej do obsługi interfejsu. Wymagają one zapewnienia alternatyw dla skomplikowanych gestów przeciągania oraz odpowiednio dużych celów klikalnych, co jest kluczowe na ekranach dotykowych.
3. Redukcja obciążenia poznawczego: WCAG 2.2 kładzie duży nacisk na upraszczanie procesów i zmniejszanie wymagań dotyczących pamięci i koncentracji. Kryteria 3.2.6 Spójna pomoc, 3.3.7 Zbędne wprowadzanie danych oraz 3.3.8/3.3.9 Dostępne uwierzytelnianie bezpośrednio adresują te potrzeby, czyniąc procesy takie jak szukanie pomocy, wypełnianie formularzy czy logowanie znacznie łatwiejszymi.

Tabele Podsumowujące Zmiany

Poniższe tabele syntetyzują nowe kryteria wprowadzone w wersjach 2.1 i 2.2, ułatwiając szybkie zorientowanie się w ewolucji standardu.

Tabela 1: Nowe Kryteria Sukcesu w WCAG 2.1

Źródła:

Tabela 2: Nowe i Usunięte Kryteria w WCAG 2.2

Źródła:

Wnioski i Rekomendacje Strategiczne

Analiza wytycznych WCAG w wersjach 2.0, 2.1 i 2.2, wraz z ich kontekstem prawnym i ewolucyjnym, prowadzi do szeregu wniosków o strategicznym znaczeniu dla wszystkich organizacji tworzących i zarządzających treściami cyfrowymi. Dostępność przestała być techniczną ciekawostką, a stała się fundamentalnym elementem jakości produktu, zgodności z prawem i odpowiedzialności społecznej.

Rekomendacja Główna: Przyjęcie WCAG 2.2 AA jako Celu

Zaleca się, aby wszystkie nowe i modernizowane projekty cyfrowe dążyły do osiągnięcia zgodności ze standardem WCAG 2.2 na poziomie AA. Takie podejście przynosi potrójną korzyść:

1. Zapewnia zgodność z obecnymi wymogami prawnymi: Ponieważ WCAG 2.2 jest w pełni wstecznie kompatybilny, spełnienie jego wymagań na poziomie AA automatycznie gwarantuje zgodność z polską Ustawą o dostępności cyfrowej i innymi regulacjami opartymi na WCAG 2.1 AA.
2. Przygotowuje na przyszłe regulacje: Europejski Akt o Dostępności (EAA), obowiązujący od 2025 roku, będzie wymagał dostępności od szerokiego spektrum podmiotów prywatnych. Choć formalnie opiera się na normie odwołującej się do WCAG 2.1, przyjęcie nowszej wersji 2.2 jest strategicznym krokiem, który zabezpiecza organizację przed przyszłymi nowelizacjami prawa i pozycjonuje ją jako lidera w dziedzinie inkluzywności.
3. Implementuje najnowsze najlepsze praktyki: WCAG 2.2 adresuje realne problemy użytkowników, zwłaszcza w kontekście interakcji mobilnych i obciążenia poznawczego. Wdrożenie tych kryteriów prowadzi do stworzenia produktów, które są po prostu lepsze, bardziej użyteczne i przyjazne dla wszystkich użytkowników, nie tylko tych z niepełnosprawnościami.

Dostępność jako Proces Ciągły

Osiągnięcie zgodności z WCAG nie jest jednorazowym projektem, który można „zakończyć i zapomnieć”. Jest to ciągły proces, który musi być zintegrowany z całym cyklem życia produktu cyfrowego. Wymaga to wdrożenia stałych praktyk, takich jak regularne audyty dostępności (zarówno automatyczne, jak i manualne), szkolenia dla deweloperów, projektantów i redaktorów treści, a także włączenie kryteriów dostępności do procesów projektowych (DesignOps) i deweloperskich (DevOps). Utworzenie pętli zwrotnej z użytkownikami, w tym z osobami z niepełnosprawnościami, jest nieocenionym źródłem informacji do ciągłego doskonalenia.

Poza Zgodnością: Selektywne Wdrażanie Poziomu AAA

Chociaż osiągnięcie pełnej zgodności z poziomem AAA dla całej witryny jest często niepraktyczne i nie jest zalecane jako wymóg prawny, całkowite ignorowanie tych kryteriów jest błędem strategicznym. Organizacje powinny traktować kryteria AAA jako katalog zaawansowanych ulepszeń. Zamiast odrzucać je a priori, należy przeprowadzić analizę, które z nich przyniosą największą korzyść dla kluczowych grup docelowych i wdrożyć je tam, gdzie jest to zasadne i możliwe. Na przykład, dla serwisu z treściami edukacyjnymi dla dzieci, wdrożenie kryterium 3.1.5 Poziom umiejętności czytania może być kluczowe. Dla serwisu bankowego, kryterium 2.2.5 Ponowne potwierdzenie autentyczności znacząco poprawi doświadczenie użytkownika.

Spojrzenie w Przyszłość

Ewolucja standardu WCAG odzwierciedla szerszą zmianę paradygmatu w projektowaniu technologii – od koncentracji na technicznym „działaniu” do koncentracji na ludzkim „doświadczeniu”. WCAG 2.0 ustanowiło solidne, techniczne fundamenty. WCAG 2.1 rozszerzyło je na nowe konteksty użytkowania, takie jak urządzenia mobilne. WCAG 2.2 idzie jeszcze dalej, zagłębiając się w niuanse interakcji motorycznych i złożoność poznawczą. Ta trajektoria pokazuje, że pytanie „czy technologia asystująca może to odczytać?” jest zastępowane przez pytanie „czy człowiek może to łatwo, bez frustracji i efektywnie obsłużyć i zrozumieć?”.

Trwające prace nad kolejną dużą wersją, WCAG 3.0 (nazwa robocza „Silver”), zapowiadają dalsze pogłębienie tego trendu. Planuje się odejście od binarnego modelu „spełnia/nie spełnia” na rzecz bardziej elastycznego systemu oceny, uwzględniającego kontekst i rzeczywiste wyniki dla użytkowników. To dodatkowo podkreśla, jak ważne jest, aby organizacje już dziś skupiły się na zrozumieniu i wdrożeniu zasad dostępności, a nie tylko na mechanicznym spełnianiu reguł.

Inwestycja w dostępność cyfrową, oparta na solidnym zrozumieniu WCAG, jest dziś nierozerwalnie związana z inwestycją w ogólną jakość doświadczenia użytkownika (UX), innowacyjność i budowanie zaufania. W dobie rosnącej świadomości społecznej i zacieśniających się regulacji prawnych, staje się ona nie tylko obowiązkiem, ale i kluczowym elementem przewagi konkurencyjnej na cyfrowym rynku.

Źródła

1. Web Content Accessibility Guidelines – Wikipedia, https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines 2. WCAG 2 Overview | Web Accessibility Initiative (WAI) | W3C, https://www.w3.org/WAI/standards-guidelines/wcag/ 3. Background: What is WAI? The Web Accessibility Initiative – The A11Y Project, https://www.a11yproject.com/posts/what-is-wai/ 4. Web Content Accessibility Guidelines (WCAG) 2.1 – W3C, https://www.w3.org/TR/WCAG21/ 5. Introduction to the Web Content Accessibility Guidelines (WCAG), https://digitalaccess.missouri.edu/introduction-to-the-web-content-accessibility-guidelines-wcag/ 6. Home | Web Accessibility Initiative (WAI) | W3C, https://www.w3.org/WAI/ 7. Web Accessibility Initiative (WAI) Explained – EqualWeb, https://www.equalweb.com/a/43600/43600/web_accessibility_initiative 8. What is the difference between the W3C guidelines and the Section 508 standards for web accessibility? | AccessComputing – University of Washington, https://www.washington.edu/accesscomputing/what-difference-between-w3c-guidelines-and-section-508-standards-web-accessibility 9. Web Content Accessibility Guidelines (WCAG), https://accessibility.fiu.edu/resources/wcag/ 10. Polski Akt o Dostępności a WCAG – jak dostosować stronę do nowych wymogów?, https://www.sempire.pl/polski-akt-o-dostepnosci-a-wcag-jak-dostosowac-strone-do-nowych-wymogow.html 11. WCAG 2.2 – co musisz wiedzieć o standardzie dostępności cyfrowej? – SARE, https://sare.pl/blog/poradniki/wcag-2-2-co-musisz-wiedziec-o-standardzie-dostepnosci-cyfrowej/ 12. Co to są dyrektywy WCAG 2.2 i kto musi ich przestrzegać? – Sun Group, https://sungroup.pl/wiedza/optymalizacja-stron-www/co-to-sa-dyrektywy-wcag-20-i-kto-musi-ich-przestrzegac 13. WCAG 2.1 w skrócie – Dostępność cyfrowa – Portal Gov.pl, https://www.gov.pl/web/dostepnosc-cyfrowa/wcag-21-w-skrocie 14. Wytyczne WCAG 2.1 — dostępność stron internetowych – Semcore, https://semcore.pl/wytyczne-wcag-2-1-dostepnosc-stron-internetowych/ 15. WCAG A, AA, i AAA — Jakie poziomy dostępności oferują? – Artur Figurski, https://www.figurski.pl/wcag-a-aa-i-aaa-jakie-poziomy-dostepnosci-oferuja/ 16. WCAG – czym jest i dla kogo? – Control, https://www.control.net.pl/aktualnosci/wcag-czym-jest-i-dla-kogo 17. WCAG Overview – Usability & Web Accessibility – Yale University, https://usability.yale.edu/web-accessibility/articles/wcag-overview 18. Wytyczne dla dostępności internetowej (WCAG) 2.1 | Pracownia Dostępności Cyfrowej LepszyWeb.pl, https://testy.lepszyweb.pl/wcag21 19. Dostępność cyfrowa stron internetowych i aplikacji mobilnych …, https://sip.lex.pl/akty-prawne/dzu-dziennik-ustaw/dostepnosc-cyfrowa-stron-internetowych-i-aplikacji-mobilnych-podmiotow-18850316 20. Ustawa o dostępności cyfrowej w pytaniach i odpowiedziach – Fundacja Widzialni, https://widzialni.org/ustawa-o-dostepnosci-cyfrowej-w-pytaniach-i-odpowiedziach,new,mg,6,362 21. Dostępność stron internetowych i mobilnych aplikacji sektora publicznego – EUR-Lex, https://eur-lex.europa.eu/PL/legal-content/summary/accessibility-of-public-sector-websites-and-mobile-apps.html?fromSummary=17 22. Ustawa o dostępności cyfrowej stron internetowych i aplikacji mobilnych – Komentarz ekspercki – Krakweb, https://www.krakweb.pl/ustawa-o-dostepnosci-cyfrowej-stron-internetowych-i-aplikacji-mobilnych-komentarz-ekspercki 23. Nowe przepisy ustawy o dostępności cyfrowej – Dostępność cyfrowa – Portal Gov.pl, https://www.gov.pl/web/dostepnosc-cyfrowa/nowe-przepisy-ustawy-o-dostepnosci-cyfrowej 24. The European Accessibility Act (EAA) | Deque – Deque Systems, https://www.deque.com/european-accessibility-act-eaa-compliance/ 25. Understanding the European Accessibility Act and WCAG 2.2 | Blog – OneTrust, https://www.onetrust.com/blog/understanding-the-european-accessibility-act-and-wcag-22/ 26. Wymogi dostępności cyfrowej w UE: dyrektywa EAA – Diuna Group, https://diuna.biz/wymogi-dostepnosci-cyfrowej-dyrektywa-eaa/ 27. Europejski Akt o Dostępności w praktyce – co musisz wiedzieć jako przedsiębiorca działający w sieci? » Shoper Learn, https://www.shoper.pl/learn/artykul/europejski-akt-o-dostepnosci-co-musisz-wiedziec-jako-przedsiebiorca-dzialajacy-w-sieci 28. A guide to the EU directives on digital accessibility – Siteimprove, https://www.siteimprove.com/glossary/eu-web-accessibility-directive/ 29. EAA vs. WCAG: Key Differences in Accessibility Standards – AudioEye, https://www.audioeye.com/post/differences-between-eaa-and-wcag/ 30. WCAG Vs EAA – What are the differences? – Recite Me, https://reciteme.com/news/wcag-vs-eaa/ 31. Jak spełnić WCAG (Krótki przewodnik), https://wcag.lepszyweb.pl/ 32. What’s New in WCAG 2.1 – Illinois Department of Innovation & Technology, https://doit.illinois.gov/initiatives/accessibility/iitaa/iitaa-updates/new-in-wcag.html 33. Accessibility: What’s New in WCAG 2.1? – Message Agency, https://www.messageagency.org/blog/accessibility-whats-new-wcag-21 34. WCAG 2.1 | Web Accessibility Standards and Checklist, https://www.levelaccess.com/blog/wcag-2-1-exploring-new-success-criteria/ 35. New Success Criteria in WCAG 2.1 | Accessibility Resources and Code Examples, https://dequeuniversity.com/resources/wcag2.1/ 36. What’s new in WCAG 2.1? – Intopia, https://intopia.digital/articles/whats-new-in-wcag-2-1/ 37. What’s New in WCAG 2.2: Changes and Updates from WCAG 2.1 – AudioEye, https://www.audioeye.com/post/wcag-22/ 38. What’s new in WCAG 2.2 – TetraLogical, https://tetralogical.com/blog/2023/10/05/whats-new-wcag-2.2/ 39. What’s New in WCAG 2.2 | Web Accessibility Initiative (WAI) | W3C, https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/ 40. WCAG 2.2: New Success Criteria, More Inclusive Content, https://www.wcag.com/blog/wcag-2-2-aa-summary-and-checklist-for-website-owners/ 41. What’s Changed in WCAG 2.2: Quick Reference Guide – AudioEye, https://www.audioeye.com/post/what-s-changed-in-wcag-2-2/ 42. Understanding Success Criterion 4.1.1: Parsing (Obsolete and removed) | WAI – W3C, https://www.w3.org/WAI/WCAG22/Understanding/parsing.html 43. The 411 on 4.1.1 – Adrian Roselli, https://adrianroselli.com/2022/12/the-411-on-4-1-1.html 44. WCAG 4.1.1: Parsing (Retired in WCAG 2.2) – Silktide, https://silktide.com/accessibility-guide/the-wcag-standard/4-1/compatible/4-1-1-parsing/ 45. www.w3.org, https://www.w3.org/TR/WCAG22/#:~:text=the%20following%20additions.-,New%20Features%20in%20WCAG%202.2,also%20conform%20to%20WCAG%202.1. 46. What’s New in WCAG 2.1 | Web Accessibility Initiative (WAI) | W3C, https://www.w3.org/WAI/standards-guidelines/wcag/new-in-21/