Dostępność cyfrowa poza stronami WWW – gdzie jeszcze trzeba o niej pamiętać?

Autor: Krzysztof Ścira

Dostępność cyfrowa dotyczy każdego punktu styku z technologią — aplikacje mobilne, PDF-y, wideo, kioski, IVR, dokumenty biurowe. Ustawa, EAA i praktyczne kroki.

Różne obszary zastosowania dostępności cyfrowej: aplikacje mobilne, dokumenty, materiały wideo, kioski i systemy głosowe — Dostępność cyfrowa obejmuje nie tylko strony WWW, ale także aplikacje mobilne, dokumenty PDF, interaktywne kioski, multimedia i interfejsy głosowe – wszędzie tam, gdzie użytkownicy wchodzą w kontakt z technologią.

Dostępność to nie tylko strony internetowe

Kiedy pada hasło „dostępność cyfrowa", większość osób myśli o stronach WWW i wytycznych WCAG. Tymczasem dostępność dotyczy każdego punktu styku użytkownika z technologią — od aplikacji mobilnych, przez dokumenty PDF rozsyłane mailem, po materiały wideo, kioski informacyjne i systemy IVR w centralach telefonicznych. Ustawa o dostępności cyfrowej z 4 kwietnia 2019 roku (znowelizowana w 2023 i uzupełniona aktami wykonawczymi w 2024) obejmuje podmioty publiczne, ale praktyka szybko wymusza te same standardy na sektor prywatny — choćby przez przetargi, w których wymóg WCAG AA jest warunkiem udziału.

W tym artykule omawiamy obszary, o których łatwo zapomnieć, a które dotyczą wielu projektów realizowanych przez zespoły tworzące oprogramowanie.

Aplikacje mobilne — więcej zmiennych niż na desktopie

Projektowanie dostępnej aplikacji mobilnej jest trudniejsze niż dostępnej strony WWW. Powodów jest kilka:

Rozmiar ekranu. Na smartfonie elementy interaktywne muszą mieć minimum 44×44 px (rekomendacja Apple) lub 48×48 dp (Material Design), żeby były wygodne do obsługi palcem, ale też żeby czytnik ekranu mógł je jednoznacznie zidentyfikować.
Różnorodność urządzeń. Android działa na setkach modeli z różnymi wersjami systemu. Testowanie z TalkBack na Samsungu i Xiaomi potrafi dać różne wyniki — różne implementacje nakładek producenckich wpływają na zachowanie czytnika ekranu.
Gesty i nawigacja. Czytniki ekranu (VoiceOver na iOS, TalkBack na Androidzie) zmieniają sposób obsługi gestów — przesunięcie palcem w prawo przechodzi do następnego elementu, a nie przewija stronę. Aplikacja, która opiera się wyłącznie na niestandardowych gestach (np. „przytrzymaj i przesuń"), musi oferować alternatywny sposób wywołania tej samej akcji.

Wytyczne WCAG 2.2 (od poziomu A) obejmują aplikacje mobilne — to nie jest osobny standard, choć Apple i Google publikują też własne przewodniki po dostępności dla swoich platform.

Dokumenty PDF — wygodny format, który potrafi wykluczać

PDF jest standardem w urzędach, bankach, uczelniach i firmach. Problem w tym, że większość dokumentów PDF jest tworzona bez struktury — jako „płaski" obraz tekstu, bez tagów, bez nagłówków, bez opisów alternatywnych dla grafik. Taki plik jest bezużyteczny dla czytnika ekranu.

Poprawnie przygotowany PDF powinien spełniać standard PDF/UA (ISO 14289-1), który definiuje:

Hierarchię nagłówków (H1–H6) i strukturę dokumentu (sekcje, akapity, listy).
Kolejność odczytu — czytnik ekranu musi przechodzić przez treść w logicznej kolejności, nie w kolejności warstw graficznych.
Teksty alternatywne dla grafik, wykresów i tabel.
Oznaczenie języka dokumentu (atrybut Lang).

W praktyce narzędzia takie jak Adobe Acrobat Pro pozwalają na sprawdzenie i naprawę tagów w istniejących PDF-ach. Natomiast wbudowane czytniki PDF w przeglądarkach (Chrome, Firefox, Edge) nadal mają ograniczone wsparcie dla PDF/UA — potrafią wyświetlić dokument, ale nie interpretują poprawnie jego struktury semantycznej. Dlatego instytucje publiczne powinny testować swoje PDF-y w dedykowanych narzędziach, nie tylko w podglądzie przeglądarki.

Rozwiązanie, które zyskuje popularność, to udostępnianie treści równolegle w formacie HTML (np. jako artykuł na stronie) i PDF (do pobrania). HTML jest z natury łatwiejszy do uczynienia dostępnym.

Materiały wideo i audio — napisy to minimum

Wideo bez napisów wyklucza osoby niesłyszące i słabosłyszące. Audio bez transkrypcji wyklucza osoby głuche. To oczywiste stwierdzenia, ale w praktyce napisy traktuje się jak „miły dodatek", a nie wymóg. WCAG 2.2 na poziomie A wymaga napisów (kryterium 1.2.2) i audiodeskrypcji dla nagranych materiałów wideo (kryterium 1.2.3).

Kilka praktycznych uwag z naszych doświadczeń:

Automatyczne napisy (YouTube, Teams, Zoom) to dobry punkt wyjścia, ale nie wystarczą — jakość rozpoznawania mowy w języku polskim jest wciąż niższa niż w angielskim. Nazwy własne, terminy branżowe i gwary regionalne powodują błędy. Napisy trzeba redagować ręcznie.
Transkrypcja audio (np. podcastów) powinna być dostępna jako tekst na stronie, nie tylko jako plik do pobrania. Transkrypcja w formacie HTML jest indeksowana przez wyszukiwarki i dostępna dla czytników ekranu.
Audiodeskrypcja to dodatkowa ścieżka narratorska opisująca to, co widać na ekranie (gesty, wykresy, prezentowane slajdy). Nie każdy materiał jej wymaga — ale jeśli treść wizualna jest kluczowa dla zrozumienia przekazu, audiodeskrypcja staje się obowiązkowa.

Kioski informacyjne, bankomaty i urządzenia publiczne

Kioski w urzędach, biletomaty, bankomaty, terminale płatnicze — to urządzenia, z których korzystają wszyscy, również osoby z niepełnosprawnościami. Europejski Akt o Dostępności (European Accessibility Act, dyrektywa 2019/882) wymaga, żeby od 2025 roku nowe terminale samoobsługowe spełniały wymogi dostępności.

W praktyce oznacza to:

Ekran dotykowy z obsługą głosową lub fizyczną klawiaturą jako alternatywą.
Interfejs czytelny przy różnym oświetleniu (kioski stoją w halach, na dworcach, na zewnątrz).
Oprogramowanie zgodne z WCAG — również jeśli to aplikacja webowa osadzona w przeglądarce kiosku.
Fizyczną dostępność urządzenia (wysokość ekranu, podejście wózkiem).

Jeśli Twoja firma buduje oprogramowanie dla terminali lub kiosków, wymagania dostępności dotyczą Was tak samo jak twórców stron WWW.

IVR i systemy telefoniczne

Systemy Interactive Voice Response (IVR), czyli „naciśnij 1, żeby…", to punkt styku z technologią, o którym rzadko myśli się w kategoriach dostępności. Tymczasem dla osób niedosłyszących lub osób z trudnościami w rozumieniu szybkiej mowy automatycznej, źle zaprojektowany IVR jest barierą nie do pokonania.

Podstawowe zasady dostępnego IVR:

Klarowne, wolno czytane komunikaty w języku polskim (nie syntezator generyczny).
Możliwość powtórzenia komunikatu i powrotu do menu wyższego poziomu.
Alternatywa dla IVR — np. chat, formularz kontaktowy, e-mail — wyraźnie widoczna na stronie.

Dokumenty biurowe — Word, Excel, PowerPoint

Dostępność dotyczy też plików tworzonych w pakietach biurowych. Prezentacje PowerPoint bez opisów alternatywnych dla obrazów, arkusze Excela bez nazw arkuszy i opisów kolumn, dokumenty Worda bez nagłówków i stylów — wszystko to tworzy bariery dla użytkowników czytników ekranu.

Microsoft Office od lat oferuje wbudowany audytor dostępności (Sprawdzanie ułatwień dostępu / Accessibility Checker), który wychwytuje najczęstsze problemy. Warto go uruchamiać przed każdym udostępnieniem dokumentu — szczególnie w sektorze publicznym, gdzie dokumenty biurowe podlegają tym samym wymogom co strony WWW.

Co z tym zrobić

Zidentyfikuj punkty styku. Wypisz wszystkie miejsca, w których użytkownik styka się z Twoimi treściami cyfrowymi: strona, aplikacja, PDF-y, wideo, newsletter, IVR, kioski.
Przetestuj z czytnikiem ekranu. Włącz VoiceOver (Mac/iOS) lub NVDA (Windows) i spróbuj przejść przez swój PDF, prezentację, aplikację mobilną. Pierwsze 5 minut ujawni 80% problemów.
Zacznij od niskowiszących owoców. Dodaj alt do obrazów w dokumentach, wygeneruj tagi w PDF-ach, dodaj napisy do filmów. To prace, które można zacząć od ręki.
Uwzględnij dostępność w specyfikacji. Jeśli zlecasz budowę aplikacji, kiosku lub systemu — wpisz wymogi WCAG AA do wymagań. Im później się o tym pomyśli, tym droższe są poprawki.

Dostępność cyfrowa to nie checkbox do odhaczenia przy stronach WWW. To sposób myślenia o technologii, który obejmuje każdy format i każdy kanał komunikacji. Jeśli potrzebujesz wsparcia w ocenie dostępności swoich materiałów — od stron, przez aplikacje, po dokumenty — porozmawiajmy o audycie.

Źródła

W3C WCAG 2.2 — pełna treść wytycznych dotyczących dostępności treści internetowych, stosowanych również do aplikacji mobilnych i dokumentów.
Ustawa z dnia 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych — tekst ustawy w bazie ISAP.
Dyrektywa Parlamentu Europejskiego 2019/882 (Europejski Akt o Dostępności) — wymogi dostępności produktów i usług, w tym terminali samoobsługowych.
Apple — Accessibility Developer Documentation — wytyczne dostępności dla iOS i macOS.
Android — Accessibility Guide — przewodnik po dostępności dla aplikacji Android.
PDF Association — PDF/UA in a Nutshell — wprowadzenie do standardu dostępnych dokumentów PDF.