Tworzenie dostępnych interfejsów aplikacji w systemach i na platformach okienkowych

 

Wersja 0.3 z dnia 8 grudnia 2009 r.

Dokument jest zestawem wskazówek dla programistów tworzących aplikacje komputerowe, którzy chcą, by ich produkty były dostępne dla użytkowników z niepełnosprawnością wzroku.


Wprowadzenie

W Polsce niemal 30% ludzi dotkniętych jest wadami wzroku. Od 500 do 700 tysięcy to osoby z poważnymi ubytkami widzenia, a ponad 100 tysięcy to osoby niewidome. Dzięki nowoczesnym technologiom i odpowiedniemu oprogramowaniu mogą efektywnie korzystać z komputerów i standardowego oprogramowania – systemu operacyjnego, aplikacji biurowych, aplikacji internetowych i innych narzędzi. Oprogramowanie specjalistyczne to czytniki ekranu (ang. Screen reader) i powiększalniki ekranu (ang. Magnifiers), które przetwarzają informację graficzną interfejsu na – odpowiednio – mowę syntetyczną, alfabet brajla lub powiększony obraz.

Oprogramowanie specjalistyczne (ang. Adaptive technology) przetwarza informacje dostarczane przez interfejs (graficzny) użytkownika i dlatego bardzo dużo zależy od sposobu jego przygotowania przez programistę. Prawidłowo zaprojektowany pozwoli na bezproblemową pracę z aplikacją, a wadliwy utrudni ją lub uniemożliwi.

Definicje

W dokumencie posługujemy się pewnymi pojęciami, które należy zdefiniować. Ilekroć zatem użyjemy pojęcia, będziemy pod nim rozumieć:

Osoba niewidoma – osoba posługująca się komputerem i oprogramowaniem metodami bezwzrokowymi, dla której interfejsem wyjściowym jest mowa syntetyczna lub alfabet brajla;

Osoba słabowidząca – osoba posługująca się komputerem i oprogramowaniem za pomocą wzroku po zastosowaniu odpowiednich rozwiązań wspomagających, na przykład powiększenia obrazu lub zmiany kolorów;

Interfejs użytkownika – wszelka informacja przekazywana użytkownikowi przez aplikację;

Graficzny interfejs użytkownika – wszelka informacja przekazywana użytkownikowi przez kanał wzrokowy, najczęściej przez wyświetlenie jej na ekranie komputera lub innego urządzenia.

Metody pracy

Sposób pracy osoby niewidomej i słabowidzącej różni się od pracy osoby dobrze widzącej. Najważniejsze różnice, o których należy pamiętać to:

  1. Osoby niewidome i spora część słabowidzących nie korzysta z myszki i posługuje się wyłącznie klawiaturą. Oznacza to, że elementy interfejsu, do których nie da się dotrzeć za jej pomocą mogą pozostać nie zauważone lub niedostępne.
  2. Osoby słabowidzące stosują zmienioną kolorystykę w używanych aplikacjach, na przykład białe litery na czarnym tle. Wynika to z dość często występującego światłowstrętu, który ogranicza widzenie na jasnym tle. Stosowanie odpowiednich schematów kolorów ułatwia pracę także innym osobom słabowidzącym.
  3. Osoby słabowidzące często wykorzystują wbudowane w system operacyjny możliwości dostosowania: powiększenie czcionek, powiększenie kursora myszy, podwyższone kontrasty lub wręcz specjalne narzędzia, na przykład Lupa w systemie Windows lub Orca w Gnome.

Testowanie

Testowanie interfejsu aplikacji pod kątem jej dostępności dla osób niewidomych może odbyć się poprzez próbę jej użycia za pomocą czytnika ekranu. W tym celu należy:

  • ·uruchomić czytnik ekranu, na przykład NVDA;
  • wyłączyć monitor;
  • wykonać kilka podstawowych czynności w danej aplikacji za pomocą klawiatury.

Czytniki ekranu najczęściej używane w Polsce, to:

Czytniki ekranu
Nazwa Strona domowa producenta Polski głos w wersji demo Ograniczenia wersji demo
NVDA http://www.nvda-project.org Tak brak. Licencja GPL
JAWS for Windows www.freedomscientific.com Tak Działa 40 minut po każdym uruchomieniu systemu
Window-Eyes www.gwmicro.com Tak Działa 30 minut po każdym uruchomieniu systemu
HAL www.dolphinuk.co.uk Tak Działa przez 30 dni po instalacji.

Do testów można użyć dowolnego z powyższych programów, jednak użycie NVDA da najbardziej prawdziwe wyniki, ponieważ program ten nie posiada zaawansowanych mechanizmów analizy, na przykład przechwytywania sterowników graficznych. Korzysta zatem tylko z informacji dostarczanych bezpośrednio przez elementy interfejsu graficznego użytkownika.

Dostępność dla osób słabowidzących

Osoby słabowidzące niekiedy używają programów powiększających lub powiększająco-mówiących. Najprostszym testem dostępności dla tej grupy odbiorców będzie przełączenie schematu kolorów systemowych na Duży kontrast nr 2 (w systemie Windows XP) i sprawdzenie, czy aplikacja stosuje się do ogólnego wyglądu systemu. Jeżeli tak nie jest, to należy uwzględnić to w projektowanym interfejsie użytkownika.

Duża część słabowidzących użytkowników nie zmienia schematu kolorów, lecz używa niskich rozdzielczości, Warto więc przełączyć tryb graficzny na rozdzielczość 800×600 i sprawdzić, czy aplikacja mieści się na ekranie, skaluje się, a jeżeli nie – to przynajmniej pojawiają się suwaki do jej przewijania.

Wskazówki

API i frameworki

Sprawdź frameworki, których zamierzasz użyć. Z podstawowym API Windows nie ma problemu. Komponenty używane w bibliotekach: VBRUN, MFC, VCL, .NET też nie sprawiają problemów, ale już z GTK sprawa ma się znacznie gorzej. API i frameworki rozwijają się, więc warto ściągnąć świeżą przykładową aplikację i sprawdzić aktualny stan.

UWAGA! Jeśli nawet na frameworku widnieje informacja, że wspiera dostępność (z j. ang. Accessibility), to nie zawsze oznacza, że napisane w nim aplikacje będą dostępne. Wszystko zależy od umiejętnego wykorzystania jego elementów.

Projektowanie GUI

Rady zamieszczone poniżej przypomną niektórym pierwszy podręcznik do programowania okienkowego. Właściwie sprawa sprowadza się do przestrzegania standardów. Stosowanie tych samych rad, które świadczą o dobrym wychowaniu programisty pomaga osobom niesprawnym wzrokowo w używaniu aplikacji.

Okna

Trzy pierwsze punkty są szczególnie często ignorowane, przy implementacji skórek w aplikacji.

Menu systemowe. Lewy ALT+SPACE powinien uaktywniać menu systemowe. To z przenoszeniem, minimalizacją, maksymalizacją i zamykaniem okna. To jedyny sposób, w jaki można przenieść okno za pomocą klawiatury, gdy zasłania ono inny ważny element lub wychodzi poza ekran.

Lewy ALT – menu główne. Jeśli okno ma menu główne, to lewy ALT winien przenieść focus do niego. Potem strzałki w prawo i lewo winny umożliwić poruszanie się po nim.

Niebezpieczne AlwaysOnTop i dokowanie. Programy , które po instalacji domyślnie są zawsze na wierzchu, często zasłaniają elementy innych programów, powodując trudne do zlokalizowania problemy. Podobnie dokowanie, które zabiera część aktywnej przestrzeni ekranu powodując, że okna, które kiedyś mieściły się całe na nim, nagle się nie mieszczą. Dobrym pomysłem jest umieszczanie tych dwóch opcji w menu systemowym.

Pasek stanu. Używaj standardowego paska stanu. Etykieta umieszczona na dole okna, choć może wyglądać tak samo, nie zostanie rozpoznana jako pasek stanu przez czytnik ekranu.

Menu

HotKey dla wszystkich pozycji. Każda pozycja menu powinna mieć ustawiony klawisz skrótu. Czyli podkreśloną literkę umożliwiającą dostęp do tej pozycji kombinacją ALT+Litera. Np.: ALT+P – plik, ALT+E – edycja itd.

ShortCut dla głównych funkcji. Główne, lub często używane funkcje, zwykle dostępne dla myszki z poziomu pasków narzędzi powinny mieć przypisaną kombinacje klawiszy. Np. CTRL+O – Otwórz plik, CTRL+P – Drukuj itd.

…(wielokropek) dla dialogów. Jeśli opcja w menu otwiera okno dialogowe (czyli modalne względem aplikacji), to jej nazwa powinna kończyć się wielokropkiem. Np. Otwórz…, Ustawienia…, itd. To ułatwia życie nie tylko osobom niewidomym, ale im szczególnie, gdyż zmiana okna często wiąże się z załadowaniem innych plików konfiguracyjnych przez czytnik ekranu lub innymi dodatkowymi działaniami.

Unikaj kontrolek w menu. Separator jest standardowym elementem pomagającym zachować wizualny porządek. Inne elementy, na przykład comboboxy, pola tekstowe itp. są zwykle niedostrzegalne.

Paski narzędzi

ToolTip. Ta krótka informacja tekstowa jest pomocą nie tylko dla używających myszki. Czym krótsza, tym lepsza. Osoba słabowidząca nie jest w stanie przeczytać dwóch linijek tekstu zanim ToolTip zniknie.

Nie tylko na pasku. Dostęp do paska narzędzi często wymaga użycia myszki. Dobrą praktyką jest pilnowanie, aby każda opcja dostępna na pasku narzędzi miała swój odpowiednik w menu głównym. Warto także zadbać o to, by do paska narzędzi dało się dotrzeć za pomocą klawiatury, jak ma to miejsce w aplikacjach firmy MicroSoft.

Formularze i dialogi

Kolejność tabulatora. Niektóre platformy same o nią dbają, ale większość nie. Ustaw ją zgodnie z logiką opcji formularza, pamiętając, by etykieta była przed kontrolką, którą opisuje.

Unikaj kontrolki w środku zdania. Na przykładzie. Przy takim fragmencie formularza: „Po [TextBox] nieudanych próbach blokuj użytkownika”, niewidomy użytkownik będzie jedynie wiedział , że ma coś wpisać po słowie „Po”. I nawet manipulowanie kolejnością tabulatora nie zawsze tu pomoże.

Menu kontekstowe to nie prawy przycisk myszki. Gdy przewidujesz menu kontekstowe dla jakiegoś elementu, nie przypisuj go pod prawy przycisk myszki. Od tego jest osobna pozycja. Twoje menu powinno pojawić się po wciśnięciu przycisku menu kontekstowego oraz po wciśnięciu SHIFT+F10.

Używaj właściwości Text CheckBoxów i RadioButtonów. Jeśli na twojej platformie, kontrolki CheckBox i RadioButton mają właściwość Text, to nie stosuj zamiast niej osobnej etykiety. Takie działanie często skutkuje kontrolkami, które nie wiadomo do czego służą.

Nazywaj grupy RadioButtonów. Używanie kontenerów do grupowania RadioButtonów jest zwykle wymuszane przez środowisko. Ale jeśli zamiast opisu kontenera umieścimy tekstową etykietę w jego wnętrzu – utrudnimy życie osobom niewidomym.

HotKey dla ważnych etykiet. Jeśli często wchodzi się do okna, aby przestawić jedną opcję, to warto ustawić HotKey przenoszący focus do etykiety opisującej ją. Niewidomy użytkownik, zamiast naciskać kilkanaście razy TAB, będzie mógł nacisnąć ALT z podkreśloną literką.

OK, Anuluj, a HotKey dla pozostałych przycisków. W oknach dialogowych można ustawić jeden przycisk jako OK, i jeden jako Anuluj. Platforma automatycznie wiąże je wtedy z klawiszami ENTER i ESC, a czytniki ekranu też korzystają z tej informacji. Pozostałe przyciski powinniśmy zaopatrzyć w gorącą literkę.

Podsumowanie

Stosowanie powyższych wskazówek jest bardzo proste i wymaga jedynie dyscypliny i dokonania dobrego wyboru środowiska programistycznego. Stosowanie uniwersalnych elementów interfejsu ułatwi życie wszystkim użytkownikom, ponieważ nie będą musieli się zastanawiać nad ich znaczeniem. Jest to zgodne z zasadą uniwersalnego projektowania, czyli projektowania uwzględniającego potrzeby wszystkich lub niemal wszystkich użytkowników.

Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Log Out / Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Log Out / Zmień )

Facebook photo

Komentujesz korzystając z konta Facebook. Log Out / Zmień )

Google+ photo

Komentujesz korzystając z konta Google+. Log Out / Zmień )

Connecting to %s

%d bloggers like this: