Uwagi dotyczące dostępności narzędzi IT

Uwagi dotyczące dostępności narzędzi IT implementujących deliberatywny model konsultacji
publicznych
Jacek Zadrożny
Przygotowanie konsultacji publicznych:
1. Formularz rejestracji dla mieszkańca:
 Każdy element formularza (pole edycyjne, pole wyboru, pole opcji itd.) powinien mieć
semantycznie przypisaną etykietę (LABEL);
 W wypadku bardziej rozbudowanych formularzy można, a czasem wręcz należy podzielić je na
logiczne części, korzystając ze znaczników FIELDSET i LEGEND do ich opisania;
 Stosując grafiki, należy zawsze pamiętać o ich funkcjonalnym opisie alternatywnym (atrybut ALT),
a same grafiki muszą znajdować się w warstwie treściowej, a nie layoutu;
 Wszystkie elementy muszą być dostępne z poziomu klawiatury;
 W przypadku dynamicznie zmieniających się treści pod wpływem wybrania jakiegoś elementu lub
zmiany jego wartości należy zapewnić odpowiedni sposób interakcji z oprogramowaniem
użytkownika, szczególnie z oprogramowaniem asystującym;
 Zdecydowanie zalecamy stosowanie standardowych kontrolek HTML, a tylko wyjątkowo i po
przetestowaniu – rozwiązań bardziej skomplikowanych;
 Przy haśle użytkownika nie wolno użyć kodu zabezpieczającego CAPTCHA wymagającego
przepisania kodu z obrazka lub nagrania.
2. W przypadku wyboru sal na spotkanie należy w formularzu ogłoszenia o konsultacjach dodać
elementy informacyjne na temat ich dostępności, wizualizowane zestandaryzowanymi ikonami:

Dostęp dla osób poruszających się na wózkach inwalidzkich,

Winda lub inne urządzenie do przemieszczania się pomiędzy poziomami,

Pętla indukcyjna dla osób z aparatami słuchowymi.
Te pola muszą być obowiązkowe do zaznaczenia dla urzędnika. Brak zaznaczenia powinien być
sygnalizowany ikoną z przekreśleniem, co będzie miało za zadanie zmotywować do szukania
odpowiedniej sali.
3. Zgłoszenie do udziału w konsultacjach powinno zawierać listę koniecznych udogodnień do wyboru:

Tłumacz języka migowego;

Dostępność architektoniczna;

Pętla indukcyjna;

Materiały w brajlu;

Materiały w druku powiększonym.
System powinien sprawdzać konflikty oczekiwań z wybraną salą i zaplanowanymi udogodnieniami.
Błąd powinien być zgłaszany organizatorowi.
4. Materiały informacyjne:
Dyspozycje do ich przygotowania powinny zawierać listę kontrolną sprawdzającą dostępność.
Tekst:
1

Sprawdź, czy w pliku znajduje się tekst z możliwością skopiowania fragmentu w inne miejsce
(dotyczy przede wszystkim PDF);

Sprawdź, czy tabele są odpowiednio przygotowane, a treść podzielona jest na mniejsze części za
pomocą nagłówków;

Sprawdź, czy elementy graficzne mają prawidłowe opisy alternatywne;

Sprawdź, czy dodano tłumaczenie na język migowy.
Wideo:

Sprawdź, czy dołączone są napisy dla osób niesłyszących;

Sprawdź, czy dołączone jest tłumaczenie na język migowy;

Sprawdź, czy dołączona jest audiodeskrypcja lub transkrypcja tekstowa;

Sprawdź, czy nagrana mowa jest dobrze słyszalna na tle innych dźwięków.
Wideo może składać się tylko z obrazu bez dźwięku (animacja). Warto dodać taki typ materiału,
wówczas lista będzie miała kształt:

Sprawdź, czy dołączona jest audiodeskrypcja lub transkrypcja tekstowa.
Nagranie dźwiękowe:

Sprawdź, czy dodano transkrypcję tekstową materiału;

Sprawdź, czy dodano tłumaczenie na język migowy;

Sprawdź, czy mowa jest dobrze słyszalna na tle innych dźwięków.
Fotografia, mapa, plan, schemat, infografika:

Sprawdź, czy dodany jest prawidłowy tekst alternatywny.
Tutaj niezbędne będzie dodanie rozbudowanego podręcznika, w jaki sposób tworzyć tekst
alternatywny.
5. Spotkania dyskusyjne:
Przy ich planowaniu należy wziąć pod uwagę m.in. to, że w przypadku uczestniczenia osoby
niesłyszącej w dyskusji dodatkową osobą musi być tłumacz języka migowego. Jego zadaniem jest
słuchanie wypowiedzi, tłumaczenie ich na język migowy i przekazywanie wypowiedzi osoby
niesłyszącej. O dostosowaniu narzędzi IT do potrzeb uczestnictwa w debatach i ankiecie osób z
niepełnosprawnościami więcej mowa w opisie realizacji konsultacji.
Realizacja konsultacji publicznych:
1. Materiały informacyjne:
 Broszura drukowana nie jest dostępna dla osób niewidomych, może być częściowo niedostępna
dla osób słabowidzących, dyslektycznych, niepełnosprawnych intelektualnie i głuchych. Część
problemów rozwiązuje forma elektroniczna, przygotowana w zgodzie z zasadami dostępności.
Treść powinna być zaadaptowana – to znaczy przetłumaczona na język migowy, a tekst powinien
być łatwy do czytania;
 Materiał zdjęciowy musi być uzupełniony o prawidłowe teksty alternatywne;
 Mapa jest kłopotliwa do udostępnienia dla osób niewidomych i słabowidzących. Rozwiązaniami
są starannie przygotowane teksty alternatywne opisujące najważniejsze elementy mapy oraz
mapy dotykowe (ang. Tactile graphics);
 Materiał wideo odtwarzany na żywo musi mieć przynajmniej audiodeskrypcję i napisy dla osób
2
niesłyszących. Dobrze jest, gdy zaopatrzony jest także w tłumaczenia na język migowy;
 Kolorowanie informacji jest akceptowalnym rozwiązaniem, ale pod warunkiem, że zapewniony
będzie także inny sposób oznaczania (np. symbole, litery i inne elementy).
2. Podczas przesłuchania ekspertów w przypadku osób niesłyszących niezbędna jest obecność
tłumacza języka migowego. Przesłuchanie powinno odbywać się w pomieszczeniu wyposażonym w
pętlę indukcyjną.
 Do pliku dźwiękowego koniecznie należy dodać pełną transkrypcję tekstową;
 Do wideo należy dodać przynajmniej napisy i audiodeskrypcję, a dodatkowo także uzupełnić o
tłumaczenia na język migowy.
3. Debaty:

W przypadku uczestniczenia osoby niesłyszącej w dyskusji do materiału głosowego i wideo
powinny być dodane odpowiednio: transkrypcja lub napisy i audiodeskrypcja oraz tłumaczenia
na język migowy.

Zadaniem tłumacza języka migowego jest słuchanie wypowiedzi, tłumaczenie ich na język
migowy i przekazywanie wypowiedzi osoby niesłyszącej. Oznacza to też konieczność dodania
funkcjonalności polegającej na wyświetlaniu okna z tłumaczem. Tłumacz może być usługą
zewnętrzną (www.wideotłumacz.pl, TokTuTok itp.), więc warto przemyśleć sposób łatwego
osadzania takich elementów w systemie.

Wszystkie elementy sterujące, to znaczy przyciski do łączenia się z pokojem, włączania i
wyłączania mikrofonu, zgłaszania chęci zabrania głosu, regulacji głośności mikrofonu i głośników
muszą być dostępne z poziomu klawiatury oraz muszą mieć prawidłowe etykiety.

Do sygnalizowania chęci zabrania głosu należy wykorzystać technologię ARIA, żeby użytkownicy
czytników ekranu nie tracili tej informacji.

Jeżeli zawartość tablicy będzie się zmieniać w trakcie debaty, trzeba wykorzystać w niej
odpowiednie rozwiązania z technologii ARIA (aria-live). W ten sposób informacje nie umkną
użytkownikom technologii asystujących.

W przypadku zegara odmierzającego długość wypowiedzi można wykorzystać rozwiązanie, które
zastosowano w Sejmie – na kilkanaście sekund przed końcem udzielonego czasu odzywa się
sygnał dźwiękowy. Jeżeli takie rozwiązanie będzie wprowadzone, to trzeba zadbać także o
alternatywny komunikat dla osób niesłyszących.

Narzędzia speech-to-text (przekładanie zapisu głosowego na tekst) dla języka polskiego już
istnieją, ale są rozwiązaniami komercyjnymi. W narzędziu można uwzględnić jakieś API, które
pozwalałoby na łatwe podpięcie takiego narzędzia (np. Dragon).

Chat jest dosyć kłopotliwą formą uczestnictwa dla osób niepełnosprawnych. Osoby niewidome
często spotykają się z niedostępnymi rozwiązaniami, a reakcja jest dosyć wolna, więc wypowiedzi
mogą być opóźnione. Podobny problem jest w wypadku osób niesłyszących, które słabo znają
język polski i osób z niepełnosprawnością intelektualną. Część problemów może rozwiązać
wątkowanie, jednak nie wszystkie. Wydaje się, że dla osób niesłyszących niezbędny będzie
tłumacz języka migowego, a zatem – analogicznie jak w innych sytuacjach – trzeba przewidzieć
API do osadzania tłumaczenia w interfejsie aplikacji. Sam chat musi spełniać wymagania
dostępności WCAG 2.0, w tym w szczególności – dostępność z poziomu klawiatury.
4. Grafy:
Samodzielne wypełnienie grafu przez osobę niewidomą lub osobę z niepełnosprawnością
3
intelektualną może być trudne lub wręcz niemożliwe. W tym momencie, bez poznania kompletnej
koncepcji grafu, trudno jest zaproponować konkretne rozwiązania. Automatyzacja procesu tworzenia
grafu daje możliwość zaprojektowania także jego wersji tekstowej.
Graf jest szczególnie trudnym do transkrypcji elementem graficznym. Jeżeli system będzie wspierał
tworzenie takiego grafu, to powinien mieć też zautomatyzowane metody transkrypcyjne.
5. Ankieta:
Musi istnieć możliwość dostępu do obu rodzajów ankiety: papierowej i elektronicznej. Papierowej
wersji nie wypełni osoba niewidoma i bardzo słabowidząca, a elektronicznej – osoba niekorzystająca
z technologii informacyjno-komunikacyjnych.
W przypadku ankiet elektronicznych:

każdy element ma swoją dowiązaną semantycznie etykietę;

duże formularze podzielone na mniejsze części z ułatwioną nawigacją;

obowiązkowe grupowanie elementów jednokrotnego wyboru (radio).
W wypadku ankiet papierowych (o ile będzie edytor):

czcionka przynajmniej 14 pt, optymalnie – 16 pt;

czcionka bezszeryfowa, przynajmniej średniej grubości (nie używać czcionek thin), unikać
czcionek pochylonych.
Dla obu rodzajów:

jasna instrukcja, co należy zrobić (wpisać, wstawić krzyżyk, skreślić itp.);

instrukcja zgodnie z zasadami tekstu łatwego do czytania (można dodać przykłady).
4