Polski Związek Niewidomych

Wstęp

Niepełnosprawność jest tym obszarem, w którym bariery w dostępności są bardzo odczuwalne. Jednocześnie przyzwyczailiśmy się do nich tak bardzo, że ograniczona dostępność życia publicznego wydaje się nam tak oczywista, iż nie zauważamy, co należy zmienić. W krajach zachodnich można spotkać się z opinią, że bariery w dostępności dla osób niepełnosprawnych to ostatni bastion dyskryminacji. Warto aby “Virtualna Warszawa” była interesująca dla wszystkich.

W swoim opracowaniu piszę wyłącznie o technologicznych rozwiązaniach zwiększających dostępność miasta, poświęcając szczególną uwagę IT. Jednak obok rozwiązań informatycznych równie ważne są klasyczne tzw. ułatwienia dla osób niewidomych i słabo widzących, takie jak oznaczenia dotykowe i napisy w brajlu (np. numery na drzwiach i szafkach), oznaczenia fakturowe szlaków komunikacyjnych i przejść, kontrasty itp. Oraz właściwe przeszkolenie pracowników instytucji. Dopiero takie całościowe potraktowanie kwestii dostępności znacznie zbliży nas do sukcesu.

1. Aplikacja “Virtualna Warszawa”: Propozycje rozwoju

1.1. Najważniejsze funkcjonalności

1.1.1. Informowanie

W warstwie informacyjnej aplikacja powinna mieć co najmniej dwa poziomy przekazywania treści: podstawowy i szczegółowy. Na poziomie podstawowym podawane są najważniejsze informacje nawigacyjne, czyli nazwa miejsca i inne dane absolutnie niezbędne dla orientacji oraz informacje o zagrożeniach (np. schody, pod które można wejść i uderzyć głową). Ten poziom informowania odpowiada mniej więcej treściom komunikatów przygotowanych obecnie (grudzień 2015) dla CNK. Na poziomie szczegółowym powinny być podawane dokładniejsze opisy miejsc (np. pomieszczenia, do którego wszedł użytkownik) oraz informacje przewidziane przez gospodarzy obiektu.

Przykład1: Zwiedzając Łazienki na poziomie podstawowym niewidomy użytkownik usłyszy “Portret króla Stanisława Poniatowskiego”, a po wybraniu informacji szczegółowej usłyszy audiodeskrypcję oraz informacje udostępniane wszystkim zwiedzającym jako napisy lub audioguide.

Informacje szczegółowe powinno włączać się prosto i szybko, najlepiej bez konieczności wyjmowania telefonu z kieszeni (stuknięcie, przystanięcie, naciśnięcie przycisku na smartfonie lub słuchawce). Jeżeli informacje szczegółowe są odtwarzane automatycznie (np. podczas zwiedzania muzeum) aplikacja musi mieć możliwość szybkiego ich przerywania.

1.1.2. Aplikacje i treści kontekstowe

Menu kontekstowe VW powinno dawać dostęp do aplikacji i treści powiązanych z miejscem. Aplikacje nie mogą uruchamiać się automatycznie, o ile użytkownik sam nie ustawi aplikacji jako domyślnej dla miejsca.
Przykład1: Na przystanku autobusowym użytkownik w menu kontekstowym ma rozkład jazdy/planer podróży oraz program do kupowania biletów.
Przykład2: Użytkownik w sali teatru ma dostęp do informacji o przedstawieniu, transkryptu sztuki zawierającego tekst i opis, kanału audiodeskrypcji (jeżeli przedstawienie ma audiodeskrypcję) oraz przycisku prośby o kontakt z kimś z obsługi.

1.1.3. Szukanie pomocy

Aplikacja powinna dawać możliwość kontaktu z personelem danej instytucji lub po prostu zwrócenia na siebie uwagi kogoś z obsługi. Program mógłby komunikować się z programem na drugim urządzeniu (PC lub smartfon) albo (w dalszej przyszłości) wręcz z innym urządzeniem przypisanym do miejsca, np. dzwonkiem.
Przykład1: Użytkownik wchodzi do urzędu i nie może znaleźć recepcji. Naciska przycisk kontaktu i na komputerze w recepcji miga ikonka oznaczająca, że klient potrzebuje asysty.

1.1.4. Nawigacja

W wersji minimum program powinien podawać w miarę dokładne informacje o lokalizacji użytkownika. Informacje powinny być podawane automatycznie w miarę przemieszczania się użytkownika. W przestrzeniach, gdzie beaconów jest dużo, użytkownik powinien mieć do dyspozycji filtry zawężające ilość podawanych informacji. Automatyczne anonsowanie miejsc powinno być wyłączalne. Oprócz informacji podawanych przez program automatycznie użytkownik musi mieć możliwość lokalizowania się na żądanie. Lokalizacja na żądanie nie powinna sprowadzać się do powtórzenia ostatniego komunikatu.

Przykład1: W centrum handlowym głodny użytkownik wyłącza informowanie o mijanych sklepach.

Przykład2: Uczestnik konferencji wraca z przerwy kawowej i w holu pyta program: “Gdzie jestem?”. “Najbliższe miejsce to barek. Idziesz w kierunku Sali konferencyjnej. Odległość 30 metrów”.

Oprócz informowania o miejscach program powinien mieć funkcje klasycznej nawigacji dla niewidomych. Użytkownik wybiera miejsce, a program opracowuje optymalną trasę i prowadzi do miejsca docelowego. Tam, gdzie beaconów jest mało lub nie ma ich w ogóle, program powinien przełączyć się na korzystanie z GPS.

1.2. Funkcjonalności dodatkowe

1.2.1. Polecenia głosowe

W przypadku rozbudowy aplikacji jej użyteczność zwiększy wprowadzenie możliwości wydawania poleceń głosem. Podczas przemieszczania się głos jest jedną z najszybszych metod komunikacji z urządzeniami. Wpisywanie tekstu na klawiaturze lub nawet używanie funkcji pisania głosowego nie jest tak wygodne jak polecenia głosowe.

1.2.2. System informacji pasażerskiej

Aplikacja powinna mieć dostęp do systemu dynamicznej informacji pasażerskiej rozbudowanego o możliwość identyfikacji numeru linii dzięki beaconom zainstalowanym w autobusach. Wtedy użytkownik będzie nie tylko wiedział, jaki autobus lub tramwaj ma wkrótce przyjechać, ale gdy pojazd podjedzie, program poda mu tę informację. Beacony nie rozwiązują problemu kilku pojazdów podjeżdżających jednocześnie (mogą tu pomóc dodatkowe beacony przy drzwiach) oraz niedbałych kierowców zapominających wprowadzić na kontrolerze systemu informacji właściwy numer linii i kierunek, ale i tak znacznie zwiększają psychiczny komfort podczas korzystania z transportu miejskiego. Niezależnie od komunikatów głosowych w pojazdach, aplikacja powinna podawać nazwy przystanków. Dodatkowo użytkownik powinien móc wybrać przystanek docelowy i uzyskać alert, gdy autobus będzie się do tego przystanku zbliżał. Poprzez aplikację użytkownik powinien móc zgłosić kierowcy, że jest pasażerem o specjalnych potrzebach, by ten zwrócił na niego uwagę.

Przykład1: Użytkownik na przystanku jest informowany przez program, że podjeżdża autobus linii 185. Naciska przycisk informacji dla kierowcy, że jest osobą niepełnosprawną. Kierowca otwiera drzwi. Gdy autobus rusza, program rozpoznaje ruch i wchodzi w tryb anonsowania przystanków.

1.2.3. Mikrochat

Komunikator umożliwiający tekstową konwersację użytkownikom aplikacji znajdującym się w jednym miejscu, np. w promieniu 50 – 100 metrów. Taki dodatek, dostępny dla wszystkich użytkowników VW, spełniałby dwie funkcje:

1. Funkcja społecznościowa. Pasażerowie jadący jednym wagonem lub klienci jednego lokalu mogą sobie niezobowiązująco pokonwersować.
2. Funkcja pomocowa. Aktualnie niezależny niewidomy poruszający się po mieście, gdy jest w sytuacji, że potrzebuje pomocy, aby zwrócić na siebie uwagę musi pokręcić się w kółko i zrobić biedną minę. Mikrochat pozwalałby wysłać do wszystkich zainteresowanych wiadomościami, informację, że potrzebna jest pomoc.

Przykład1: Uczestnicy miejskiego śpiewania kolęd dostają teksty na komórkę.
Przykład2: Niewidomy na dworcu wysyła informację: “Jestem niewidomy, nie mogę znaleźć peronu 4, czy ktoś mógłby mi pomóc?”.

1.2.4. Transmisja video do innego użytkownika

Możliwość przekazania obrazu z kamery do innej osoby bardzo przydaje się w sytuacjach, gdy nie ma kogo spytać o drogę. Przekazanie obrazu na żywo wraz z lokalizacją na mapie miasta często może rozwiązać problem. Zdalny pomocnik może opisać to co widzi kamera i ewentualnie sprawdzić lokalizację na mapie.

Przykład1: Użytkownik nie może sobie poradzić z wydostaniem się spomiędzy budynków. Kontaktuje się z kimś z rodziny, przekazuje obraz z kamery i dowiaduje się, że wszedł w podwórko i że jedyną drogą jest droga powrotna.
Przykład2: Użytkownik słyszy, że wagon jego pociągu stanie w sekcji D. Przekazuje obraz z kamery zdalnemu pomocnikowi, a ten pomaga mu odnaleźć stosowną sekcję na peronie.

1.2.5. Audiodeskrypcja zawsze dostępna

Audiodeskrypcja filmów jest coraz częściej stosowanym sposobem udostępniania filmów widzom niewidomym. Jednak seanse kinowe, podczas których audiodeskrypcja jest dostępna są rzadkie i mają charakter specjalnych wydarzeń. Raz przygotowana audiodeskrypcja filmu mogłaby być stale dostępna do pobrania w Internecie. Widz/słuchacz w sali kinowej pobiera plik na smartfon, a aplikacja VW synchronizuje czas odtworzenia audiodeskrypcji z momentem rozpoczęcia seansu w kinie. Najsłabszym punktem jest sama synchronizacja. VW musiałaby dostać sygnał oznaczający, że skończyły się reklamy i rozpoczął pokaz filmu.

1.2.6. Nawigacja do miejsca w sali

Odnalezienie swojego miejsca w sali teatralnej lub konferencyjnej jest problemem. Niewidomy nie ma możliwości samodzielnego odnalezienia numeru rzędu i miejsca. W rezultacie, gdy miejsce zostanie mu wskazane przez kogoś z obsługi, musi albo siedzieć na nim przez cały czas, albo liczyć się z koniecznością ponownego proszenia o pomoc. Przy dokładności nawigacji do około 10 cm problem ten można by rozwiązać za pomocą beaconów i oznaczeń brajlowskich. Ponieważ siedzenia w salach audytoryjnych mają zwykle tę samą szerokość, nie trzeba oznaczać każdego siedzenia beaconem. Wystarczy oznaczyć rzędy, a numer miejsca obliczać sumując szerokości siedzeń. Na siedzisku, obok numeru graficznego powinien być numer w brajlu, tak by użytkownik mógł się upewnić, że siada na właściwym miejscu.

Przykład1: Użytkownik w sali koncertowej, idąc po stopniach słyszy numery mijanych rzędów. Gdy słyszy numer swojego rzędu, upewnia się, odczytując oznaczenie brajlowskie. Po wejściu do rzędu, program podaje numery mijanych siedzeń. Gdy użytkownik słyszy swój numer, upewnia się, czytając oznaczenie i siada.
Przykład2: Uczestnik konferencji zajmuje miejsce w sali, gdzie nie ma numeracji siedzeń. Zapisuje swoją pozycję w aplikacji. Gdy wraca z przerwy kawowej, program sam przypisuje numery rzędom i informuje, w którym rzędzie jest zajmowane wcześniej miejsce. Następnie komunikatami, np. “następne”, nawiguje aż do siedzenia.