Projektowanie stron WWW uwzględniając osoby niewidome i niedowidzące

Dzisiejszy wpis dedykuję twórcom aplikacji webowych, którzy chcą zaznajomić się z kwestią postrzegania stron internetowych przez osoby niedowidzące i niewidome. Ostatnio zainteresowałem się tematyką osób niewidomych i tym jak oni odbierają przekaz idący z internetu. W celu uzyskania informacji musiałem poznać kilka osób znających tematykę i dowiedzieć się u samego źródła jak to wygląda. Na początku przeszukałem indeks sieciowy pod kątem stron prowadzonych przez osoby niewidome. W ten sposób znalazłem kilku ochotników i kilku kolejnych przy pomocy listy dyskusyjnej Typhlos. Po wymianie korespondencji z ochotnikami dostałem kilka ciekawych materiałów, które zaprezentuje poniżej. Wszystkie kwestie rozbijają się o accessibility, usability, WCAG oraz WAI. Przeglądanie stron WWW przez ta grupę jest możliwe przy użyciu screen readerów. Przeglądanie stron internetowych przez osoby niewidome można przyrównać do używania np. przeglądarki Lynx. Mówiąc wprost liczy się treść statyczna czyli HTML. Wygląd czyli CSS jest całkowicie pomijany no bo i po co on właściwie potrzebny, prawda? Sprawa z JavaScriptem jest bardziej skomplikowana. Jeżeli skrypty są dobrze napisane to jest szansa, że czytnik ekranu odczyta. Ogólnie są duże utrudnienia w dynamicznym ładowaniu treści przy pomocy np. AJAX'u i różnorakich animacjach. Dlatego tak ważną kwestią jest to, aby strona była w pełni funkcjonalna bez żadnych dodatków (czytane JavaScript). Trzeba pamiętać, że JavaScript jest tylko dodatkiem. Korzystając z okazji powiem, aby niedoświadczeni nie mylili Javy z JavaScript'em, bo to są rożne języki. Apropo Javy to z tego, co wiem to ona jest praktycznie niedostępna dla osób niewidomych. Idąc dalej tym tokiem myślenia ważną kwestią jest poprawnie napisana strona, spełniająca standardy. Pomijam zdeprecjonowane elementy, o których każdy wie, że nie należy ich stosować. Prawidłowe zamykanie tagów, to ważna sprawa i warto o niej pamiętać. Przez jakieś dziwne niedopatrzenia strona może stać się niedostępna, bo zostanie źle sparsowana. Pamiętajmy, że tworzenie stron internetowych to poezja. Żeby zobaczyć i poczuć jak to wygląda w rzeczywistości powinniście ściągnąć jakiś czytnik ekranu, wyłączyć monitor i sprawdzić na ile Wasza strona jest czytelna i dostępna. Lista polecanych czytników ekranu wygląda następująco:

• Windows
  
  • NVDA
  • SuperNova
  • Jaws
  • Window-Eyes
• Linux
  
  • Orca (Gnome)
• Mac OS
  
  • VoiceOver

Pamiętam, że zadałem dość istotne pytanie dotyczące HTML5. Jak wiece nie został on jeszcze uwolniony mimo, że część korporacji go promuje (np. Google). Ponadto część webmasterów przerobiła strony tak aby były "zgodne" z wyżej wymienionym standardem. I tutaj pojawia się problem. Bo czytniki nie są jeszcze dostosowane do tych zmian co powoduje problemy z odczytywaniem stron. Oczywiście każdy rozumie, że HTML5 poprawi możliwości odnośnie poruszania się po stronie, ale jest na to IMO za wcześnie. Moim zdaniem powinno się poczekać aż dokumentacja będzie w pełni gotowa w wersji "finalnej". Myślę, że do tego czasu twórcy czytników ekranowych dostosują swoje programy, aby uwzględniały tą technologie.

Jak wiemy w dobie dzisiejszej informatyzacji, gdyby społeczeństwo odciąć od internetu to dostałoby jakiegoś amoku. Łatwo zauważyć, że z roku na rok coraz częściej na stronach widać multimedia wszelkiego typu. Jeżeli strony są zrobione przez niefachowe osoby, które nie maja pojęcia o temacie to nietrudno dojść do wniosku, że takie strony staną się niedostępne dla konkretnych grup ludzi.

Podstawowe wytyczne

Poniżej przedstawiam listę podstawowych wytycznych, jakimi powinno się kierować przy budowaniu strony.

1. Tytuł strony, czyli słynne title powinno odzwierciedlać jej zawartość. Ta kwestia rozbija się o SEO i jego efekty czyli pozycjonowanie strony. Przykładowo: mamy stronę główną firmy, to dajemy Strona główna - Nazwa firmy. Im krótszy tytuł tym lepiej.
2. Jedną z najistotniejszych kwestii jest struktura strony. To właśnie od niej zależy czy strona będzie czytelna. Rozchodzi się o używanie nagłówków, list, tabel (do danych tabelarycznych) i ramek. Te ramki to oczywiście żart i nieaktualna informacja, która dostałem, bo kto w dzisiejszych czasach używa ramek?!?
3. Jeżeli na stronie pojawiają się cytaty, akronimy i skróty to powinny one być ujęte w odpowiedni znacznik. Czytnik ekranu rozróżnią takie elementy i informuje czytelnika o nich. Ponadto, jeżeli strona jest wielojęzyczna, należy używać atrybutu języka, bo mówi to screen readerowi aby przełączył język. Jeżeli taka informacja znajduje się na stronie, to podczas kolejnych wizyt program będzie wiedział jak się dostosować.
4. Kolejnym ważnym aspektem jest udostępnianie odnośników pomiędzy poprzednia i następna stroną, a stroną aktualnie przeglądaną. W ten sposób osoby słabo orientujące się w stronie mogą bez przeszkód przemieszczać się po niej.
5. Jest taka wytyczna, że jeżeli struktura strony oparta jest o tabelki (sic!) to należy dla treści użyć jednej tabelki, a dla menu drugiej. Oczywiście jest to najgorsze z możliwych rozwiązań, bo jak wiemy strony budujemy na blokach, czyli div'ach. Tabele służą tylko i wyłącznie do przedstawienia danych tabelarycznych.
6. Kolejną ważną sugestią jest to, aby w źródle strony content był przed menu, co umożliwi łatwiejsze przemieszczanie się po stronie, bo najpierw użytkownik dostanie się do treści, a dopiero potem do menu. Jest to bardzo banalne do realizacji, bo do dyspozycji mamy CSS. Jest taka sugestia, aby udostępniać link na początku strony o treści "pomiń nawigacje", który bezpośrednio przenosi czytelnika do treści. Link taki można ustawić w stylach CSS, jest on niewidoczny dla normalnego odbiorcy korzystającego z przeglądarek graficznych, ale programy odczytu ekranu go zauważą i osoby niewidome będą mogły z niego skorzystać. W tradycyjnym rozwiązaniu po załadowaniu strony syntezatory najpierw odczytują obszar menu tak, więc chcąc przejść do właściwej treści trzeba za każdym razem wysłuchiwać linki tworzące menu strony. Przy bardzo rozbudowanych stronach bardzo wydłuża to czas jej odbioru. Powyżej opisana metoda pozwala pominąć obszar nawigacji.
7. Często źle rozgrywaną sprawą jest atrybut alt dla obrazków. Jeżeli macie menu graficzne to koniecznością jest opisanie dokładnie każdego graficznego linku. W przypadku skomplikowanej grafiki warto dla dokładniejszego opisu zastosować atrybut longdesc. Ponadto dla lepszej identyfikacji hiperłączy można użyć atrybutu title. Programy odczytujące zawartość ekranu bezproblemowo potrafią odczytywać takie rzeczy. Jeżeli nie dajesz odpowiedniego alt'u bądź dajesz go na odwal się, aby validator nie przywalał się to nie zasługujesz na miano webmastera. Drobnym szczegółem dla longdesc jest to, że może on być zastosowany dla obrazków, które nie są hiperłączami.
8. W kwestii formularzy sprawa wygląda bardzo prosto. Powinno się używać fieldset, label i accesskey tam gdzie istnieje taka możliwość. Oprogramowanie do poruszania się na stronie informuje osobę niewidoma o takich rozwiązaniu i w ten sposób pomaga w nawigacji po niej. Ze względu na to, że jest możliwość dublowania klawiszy sugeruje się aby wykorzystywać raczej cyfry niż litery. Trzeba także pamiętać, aby nie używać skrótów klawiszowych przeglądarki.
9. Gdy piszemy stronę w trybie strict musimy się liczyć z większą czułością na niektóre błędy. Rozchodzi się miedzy innymi o tzw. target blank, który odpowiedzialny jest za otwieranie nowego okna lub zakładki. Ogólnie zamyśl jest taki, że to użytkownik ma decydować o tym czy chce otworzyć stronę w nowej karcie czy w tej samej. Dla osób niewidomych jest to tylko utrudnienie, jeżeli strona otwiera się w nowej zakładce. Jednym z argumentów jest fakt, że nie wszystkie programy informują o zaistniałej sytuacji. Często właśnie w takiej sytuacji osoby niewidome są zagubione i nie wiedzą, co się dzieje. W związku z tym musza sprawdzić, jakie mają otwarte zakładki i w ten sposób trącą czas. Jeszcze gorszą sytuacją może się przydarzyć, gdy obie zakładki posiadają taki sam title. Przykładową wymówką do otwarcia nowego okna jest np. poinformowanie czytelników o tym, że w dniu tym i tym praca instytutu została skrócona do tej i tej godziny.
10. Istotna kwestia są nagłówki. Nie jest to tylko zagadnienie z punktu widzenia usability, ale także z punktu widzenia SEO oraz accessibility. Wiadomo, że nagłówki mają większą moc pozycjonerską na wybrane frazy. Przy użyciu odpowiednich skrótów klawiszowych osoba niewidoma może przeskoczyć bezpośrednio do h1 albo h2 jeżeli taki istnieje.
11. Jeżeli mamy jakiś wykaz to warto go wsadzić w listy numerowane bądź też tzw. unordered. Program analizujący treść witryny od razu będzie wiedział, że istnieją listy i w ten sposób osoba niewidoma może bezpośrednio do nich przeskoczyć. Ta sytuacja tyczy się także menu, które powinno być na lisice zbudowane! Trzeba pamiętać, że nie powinno się robić zbyt rozbudowanych zagnieżdżanych list. Zaleca się maksymalnie, aby nie przekraczać trzeciego poziomu zagnieżdżenia. Po prostu mocno rozbudowane listy wielopoziomowe są trudne do wyobrażenia przez osoby niewidome. Zwracajcie uwagę, aby elementy listy nie były puste, bo mogą być mylące dla nieprzeciętnych gości odwiedzających Waszą stronę.
12. Wcześniej mówiłem o tym, aby stosować nagłówki tam gdzie trzeba. Jedna z trafniejszych uwag jest fakt, że często w szablonach rożnych CMS'ów stosowane są one obok menu np. h4 dla menu w WordPress'ie. Należy tego unikać, bo nagłówki służą do poruszania się po treści strony, a nie po menu!
13. Jeżeli przedstawiamy jakieś dane w tabeli to zaleca się wykorzystanie znacznika caption, który jest pomocny do przemieszczania czytelnika do wybranej tabeli i przy okazji jeżeli taka sytuacja ma miejsce to odczytywany jest tytuł tabeli jeżeli został on zdefiniowany. Jeżeli nie macie potrzeby wyświetlania nagłówka tabeli to możecie ją schować z poziomu CSS natomiast, jeżeli screen readear napotka taką rzecz na swojej drodze to poinformuje o niej czytelnika.
14. Wszystkie tabele, które prezentują jakieś dane powinny być tworzenie w jak najbardziej przejrzysty sposób. Zaleca się nie tworzenie tabel, które nie posiadają widocznych granic, a także unikanie prezentowania informacji w tabelach o złożonej zagnieżdżonej strukturze. Takie sprawy komplikują bardzo orientowanie się w strukturze, hierarchii i zaznaczaniu prezentowanej informacji. Gdy doszło już do sytuacji, w której struktura tabeli jest bardzo złożona to należy zastosować streszczenia dla całej zawartości oraz dla poszczególnych rzędów bądź komórek. Streszczenia nie są wyświetlane przez przeglądarki natomiast ułatwiają osobom niewidomych poruszanie się po takim obiekcie.
15. Niedopuszczalne jest używanie elementów graficznych, których celem pozycjonowania innych elementów. Mam tutaj na myśli słynne cięcie, layoutów przez "specjalistów wysokiej klasy" w Photoshopie. Jeżeli w formularzu przycisk jest graficzny to nie należy pomijać jego opisu!
16. Jeżeli wypunktowanie na liście jest obrazkiem to należy odpowiednio zaznaczyć ten fakt przybliżona zawartość dla atrybutu alt.
17. Wszelkie inne obrazki używane na stronie takie jak np. emotikony powinny być zaopatrzone w atrybut alt, w którego treści powinien być zawarty zwięzły opis wyglądu lub znaczenia obrazka.
18. Stanowczo nie zalecane jest stosowanie tzw. map graficznych. Jeżeli już koniecznie musicie takową mapę zastosować to nie zapomnijcie o alt'cie dla poszczególnych fragmentów jak i całości.
19. Kiedy coś takiego jak ramka miało prawo istnieć zalecało się oznaczanie tytułami poszczególnych elementów przy pomocy atrybutu name. Na szczęście minęły już lata, w których używa się ramek co nas nowoczesnych webmasterów bardzo cieszy. Można powiedzieć, że języki skryptowe wyparły wyżej wymienione rozwiązanie.
20. Jedna z wytycznych, jakie przeczytałem jest informacja o tym, aby tworzyć kilka osobnych definicji kolorów tła i czcionek, dzięki którym osoby słabowidzące mogłyby je dopasowywać dzięki specjalnemu mechanizmowi. Osobiście uważam, że większość przeglądarek posiada coś takiego jak "zastosowanie autorskiego arkuszu stylów", co rozwiązuje ten problem.
21. W celu lepszego wyróżnienia hiperlinków zaleca się ustawianie im innego koloru i cech czcionki. Chodzi tutaj, aby linki zawarte w treści były np. innego koloru i dodatkowo były podkreślone. W ten sposób człowiek przez przypadek nie będzie musiał odkrywać, że gdzieś jest "ukryty" link.
22. To, co już wczesnej wspomniałem, czyli korzystanie z JavaScript'u. Powtórzę się i powiem, że strona powinna być tak samo funkcjonalna z jak i bez JS'u. Starajcie się unikać zdarzeń typu onMouseOver i podobnych, które czytniki ekranu bardzo słabo interpretują i mogą wprowadzić w błąd niewidomych obserwatorów.
23. Pola formularzy powinny być bezwzględnie odpowiednio oznaczone. Mam tutaj na myśli używanie etykiet, które są bardzo pomocne w nawigacji. Właśnie, dlatego tak często o to prowadzimy batalie na rożnego rodzaju forach. Labele powinny być jak najbliżej wybranych elementów formularza. Owe etykiety informują czytelnika o przeznaczeniu poszczególnego elementu formularza. W przypadku, kiedy nie zostanie znaleziona etykieta program odczytujący zawartość ekranu przedstawi niewidomemu zawartość atrybutu name. Takie zjawisko może być bardzo mylące szczególnie, jeżeli nazwy pól są "niedostatecznie" ludzkie. Ponadto połączenie etykiety z polem formularza znacznie ułatwia korzystanie ze strony przez osoby słabowidzące, które dzięki temu zabiegowi mają do dyspozycji większy obszar, w który mogą "kliknąć".
24. Przy tworzeniu formularzy należy pamiętać o tym, aby pola, które muszą być wypełnione, zostały zaopatrzone w dodatkową tekstową informację o konieczności ich wypełnienia. Taka informacja może być umieszczona jako etykieta danego pola lub tekst znajdujący się w jego bezpośrednim pobliżu.
25. W formularzach należy unikać stosowania tzw. "dzielonych pól edycyjnych", których działanie polega na tym, że po wpisaniu pierwszej części treści kursor jest automatycznie przenoszony do kolejnej. Takie działanie uniemożliwia użytkownikowi niewidomemu dokonywanie poprawek we wpisywanej treści przy pomocy klawiatury.
26. Coraz częściej stosuje się technologie AJAX do wyświetlania podpowiedzi w tzw. "dymkach". Może i dla przeciętnego zjadacza chleba jest ona łatwa do zlokalizowania jednak dla osoby niewidomej jest problematyczna w odnalezieniu, dlatego odradza się jej stosowanie. Często można zauważyć te zjawisko na rożnego rodzaju forach, które poprzez zalinkowanie rożnych fraz reklamują je. Przykładem takich akcji są firmy udostępniające reklamę kontekstową (np. adkontekst.pl).
27. Komunikaty o błędnym wypełnieniu pól formularza powinny być przekazywane w formie komunikatów bądź okien dialogowych wyrzucanych przez przeglądarkę. Sugeruje się, aby nie były one wyróżniane w miejscu gdzie normalnie znajduje się treść strony. Informacja taka może być trudna do znalezienia przez użytkownika niewidomego bądź słabowidzącego.
28. Należy unikać sytuacji, w których zmieniana jest zawartość listy bez przeładowania przy pomocy innej listy. Efektem takich zabiegów jest sytuacja, w której czytnik ekranu może zgubić się!
29. Należy unikać stosowania przycisków graficznych. Jeżeli jest taka konieczność to obowiązkiem jest odpowiednie opisanie go atrybutem alt.
30. Jedna z kluczowych spraw jest unikanie mechanizmu autoryzacji polegającym na poproszeniu użytkownika o przepisanie kodu z obrazka (tzw. captcha, token).
31. I jeszcze jedna ważna uwaga. Jeżeli zmieniamy mechanizm adresowania podstron, to należy pamiętać o kompatybilności wstecznej, czyli aby poprzednie linki były redirectowane na nowe adresy.
32. marquee jest totalnie złym pomysłem, ze względu na to, że po napotkaniu takiego elementu na stronie czytnik zapętla się i odczytuje cały czas ten sam tekst
33. Pusty div to zbędny div! Zamiast robić zbędne elementy po prostu zagnieżdżaj jeden w drugim!
34. Nie należy stosować linków, których anchorem jest słowo "więcej". Lepiej po prostu napisać "więcej o standardach kodowania".
35. Pamiętajcie, aby zachować hierarchie nagłówków. Czyli najpierw używamy h1, a dopiero potem h2 i tak dalej.
36. Jeżeli prowadzimy duży serwis to konsekwentnie powinniśmy pilnować struktury strony. Oznacza to, że na poszczególnych podstronach nie zmieniamy ułożenia na stronie.
37. Nigdy nie wrzucaj na stronę muzyki, która włącza się automatycznie w momencie załadowania. Jeżeli już koniecznie chcecie udostępnić taką rzecz to należy udostępnić dostępny "panel sterowania”, aby można było włączyć, wyłączyć, podgłaśniać i ściszać.
38. Nie należy także używać animacji bądź gifów, które wykorzystują technikę tzw. kalejdoskopu.

Kwestia captchy

W ostatnim jednym z ostatnich punktów listy wspomniałem o tym, aby nie stosować tego typu rozwiązań. Jest masa artykułów odnośnie tego niekorzystnego zjawiska i pozwolę sobie podlinkować tylko jeden wpis - Captcha - nie używaj!. Liczę na inwencje Was, webdeveloperów ażebyście doczytali w tej kwestii na rożnych blogach i vortalach webmasterskich. Wiem, że do niektórych przeglądarek istnieją odpowiednie wtyczki służące do "łamania captchy" na rożne sposoby. Zazwyczaj te wtyczki obsługują najpopularniejsze serwisy i ich nieznośne tokeny. Takie rozwiązanie nie jest skuteczne w 100% i może być wykorzystywane także przez spamerów. Chce zauważyć, że nie powinniśmy przerzucać odpowiedzialności sprawdzania kto jest botem, a kto zwykłym człowiekiem na naszego czytelnika. Jest kilka alternatywnych rozwiązań, które wykazują się dużą skutecznością. Mam na myśli np. Sblam! lub słynny Akismet znany z m.in. WordPress'a.

Wszystko rozbija się o ekonomie i możliwości personalne. Jeżeli prowadzimy bloga albo serwis, w którym istnieje możliwość dodawania komentarzy, to mamy do wybory dwie drogi. Pierwszą opcją jest używanie mechanizmu typu rechaptcha, który jednak dla niektórych może być problematyczny. Trzeba mieć na uwadze, że ten mechanizm jest bardzo popularny i upodobali sobie go spamerzy, dlatego według mnie nie warto go stosować. Z kolei drugą opcją jest po prostu używanie filtrów antyspamowych oraz manualne akceptowanie komentarzy. Ten sposób jest skuteczniejszy, ale wymaga zaprzęgnięcia pewnych zasobów personalnych, aby osiągnąć cel.

Korzystając z okazji opowiem trochę o mechanizmie recaptcha. Z tego, co pamiętam to wystarczy wpisać poprawnie jedno z dwóch słów, które faktycznie jest istotne i "autoryzacja" zostanie dokonana. Czasami zdarza się, że kod z obrazka jest mocno niewyraźny i trzeba go odświeżyć. Jak będę miał trochę czasum, to w komentarzu pokaże Wam co mi się wyświetliło. Ponadto w polu tego mechanizmu istnieje informacja o mniej więcej takiej treści "Type the two words". Sugeruje to jakoby trzeba było wpisać dwa słowa. Wszystko się zgadza natomiast, jeżeli odsłuchujemy informacji dźwiękowej to część użytkowników wprowadza to w błąd, bo faktycznie trzeba przepisać wszystkie puszczane liczby. Pamiętam, że gdzieś w necie natknąłem się na program łamiący głosową captche, który był wyjątkowo skuteczny.

Wnioski dla mnie są proste. Skoro i tak da się to złamać to narzuca się pytanie, dlaczego tego używać? Z doświadczenia wiem, że odnośnie głosowej captchy to około 50% ścieżek dźwiękowych daje się bezbłędnie odsłuchać i przepisać.

Kilka słów o WAI

Na początku artykułu wspomniałem o inicjatywie WAI. Teraz pozwolę sobie to trochę rozwinąć. Została ona podjęta w celu opracowania standardów, metod, narzędzi oraz działań edukacyjnych i badawczych, aby zapewnić dostępność stron internetowych dla osób z różnymi typami niepełnosprawności. W prace konsorcjum zaangażowane jest wiele organizacji reprezentowanych przez osoby niepełnosprawne. Organizacja jest podzielona na pewne grupy robocze, które zajmują się poszczególnymi aspektami projektowania stron internetowych. Głównymi celami poszczególnych grup są:

• Wpływanie na to aby nowo powstałe technologie internetowe w pełni umożliwiały dostępność stron internetowych dla osób z rożnymi typami niepełnosprawności.
• Rozpowszechnianie materiałów szkoleniowych dotyczących tworzenia "praktycznych" witryn WWW.
• Tworzenie i rozpowszechnianie narzędzi pozwalających na budowanie dostępnych stron internetowych.
• Współpraca ze środowiskami badawczymi celem opracowania nowych technologii, które będą spójne z ideologią konsorcjum.

Kilka slow o technologii Flash

Wbrew powszechnej opinii obiekty Flash mogą być dostępne dla osób niewidomych i niedowidzących, jeżeli tylko zostaną dobrze przygotowane. Zazwyczaj komponenty flashowe są mocno nasycone rożnego rodzaju elementami graficznymi i dźwiękowymi. Ponadto poszczególne elementy tych animacji są niedostępne dla osób niewidomych i częściowo dla osób słabowidzących.

Dlatego właśnie firma Adobe udostępniła narzędzie, aby interaktywne obiekty były dostępna dla wszystkich. Z informacji, które posiadam zaleca się używanie Flash Playera w wersji minimum 10 do takich celów. Korporacja udostępniła poradnik instruujący grafików jak powinno się tworzyć dostępne aplikacje. Gorąco polecam przewertowanie tego dokumentu oraz ich oficjalnego bloga!

Osobiście uważam, że technologia Flash wymrze w ciągu kilku lat. W większości przypadków śluzy ona do wyświetlania nachalnych reklam i nic poza tym. Oczywiście można je zablokować za pomocą wtyczek typu Adblock Plus, ale to inna bajka.

Dlaczego twierdze, ze to upadnie? Flash co najwyżej może przydaje się jako jakiś player (choć niekoniecznie dźwiękowy). Mowa o filmach na YT. Oczywiście w technologii HTML5 nie jest on konieczny. Jedyne, co mi przychodzi do głowy to wyrafinowane prezentacje. Ponadto z Flashem wiążą się dodatkowe koszta. Jeżeli posiadamy stronę w tej technologii to powinniśmy także zadbać o to, aby była wersja "alternatywna", czyli HTML'owska. Dla mnie jest to oczywistość, konieczność i wymóg. Nawet, jeżeli webcrawler Google potrafi indeksować, analizować i czytać obiekty Adobe to nic nie zastąpi czystej treści przedstawionej za pomocy HTML'a! Pozwolę sobie w tym momencie zacytować pewien dokument:

Cytat:

Aby udostępnić elementy prezentacji flash dla osób niewidomych i słabowidzących, należy zastosować się do następujących zaleceń:

1. Zaopatrzenie elementów graficznych w alternatywne opisy tekstowe. W tworzonej prezentacji należy dodać takie elementy jak: nazwy dla ikon, opisy dla animacji oraz opisy tekstowe dla wyróżnionych fragmentów tekstu lub grup grafik, które przekazują jakąś wspólną ideę.
2. Udostępnienie ruchomych animacji. Użycie animacji, w których teksty poruszają się w krótkim czasie w nieskończonych przebiegach wprowadza w błąd programy odczytujące zawartość ekranu. Próbują one bowiem odczytywać ciągle od nowa całą stronę, przez co ich głos się jąka lub zawiesza. Aby uniknąć takiego efektu, należy dostosować te animacje w odpowiedni sposób. Problem ten można rozwiązać na przykład poprzez dodanie przycisków umożliwiających zatrzymanie animacji oraz krokowe wyświetlanie kolejnych napisów animacji.
3. Zastosowanie komponentów dostępności. Aplikacja Flash CS4 została wyposażona w szereg komponentów, które można dodać do tworzonej prezentacji flash w celu jej udostępnienia. Umożliwiają one dodanie etykiet tekstowych, przycisków nawigacyjnych, skrótów klawiszowych i innych elementów ułatwiających użytkowanie prezentacji przez osoby niewidome i słabowidzące. Udostępnianie komponentów tworzonej prezentacji polega zwykle na wykonaniu polecenia programu, które powoduje dodanie do komponentu prezentacji dodatkowego obiektu udostępniającego ten obiekt. Umożliwia on między innymi obsługiwanie przez użytkownika przycisków przy pomocy klawiatury oraz dodanie alternatywnych opisów i etykiet do poszczególnych elementów slajdu.
4. Zapewnienie odpowiedniej kolejności odczytywania elementów prezentacji. Wizualne rozmieszczenie poszczególnych elementów prezentacji nie musi być identyczne z logiczną kolejnością, która byłaby odpowiednia dla użytkowników programów odczytujących ekran. Taką kolejność odczytywania można ustalić na trzy sposoby: Pierwszym jest ograniczenie rozmiaru poszczególnych stron prezentacji i w ten sposób uproszczenie jej struktury. Drugi sposób polega na dodaniu do prezentacji dodatkowych elementów, które w bardziej linearny sposób opisują pozostałe elementy. Trzecim sposobem zapewnienia odpowiedniej kolejności odczytywania jest użycie tzw. skryptów akcji, które przenoszą użytkownika do odpowiednich miejsc prezentacji w zależności od tego, gdzie się on aktualnie znajduje. W ten sposób można kontrolować to, w jakim porządku prezentacja będzie odczytywana przez program mówiący.
5. Dodanie skrótów klawiszowych do prezentacji[/b]. Dodanie przycisków nawigacyjnych do wszystkich elementów prezentacji powoduje, że można poruszać się pomiędzy nimi przy pomocy klawiatury. Należy jednak pamiętać o tym, aby definicje skrótów klawiszowych umieszczać w każdym slajdzie zamiast określania ich osobno dla pojedynczych obiektów. Bardzo ważne jest, aby unikać używania pustych animacji jako przycisków. Nie są one rozpoznawane przez programy odczytujące ekran i w związku z tym nie mogą być odczytane.
6. Dodanie etykiet i opisów tekstowych. Z myślą o potrzebach osób z innymi niesprawnościami (np. niesłyszących), program Flash CS4 Professional został zaopatrzony w specjalne komponenty, które umożliwiają dodawanie opisów tekstowych do zawartości audio i video, która jest umieszczana w prezentacjach. Te etykiety można także wykorzystać jako opisy tekstowe fragmentów wideo, które mogą być odczytane przez osoby niewidome. Dodawanie takich opisów polega na utworzeniu specjalnego pliku XML (DFXP), a następnie dołączeniu go do prezentacji.
7. Zapewnienie kontroli odtwarzania sekwencji wideo. Sposób odtwarzania filmów wchodzących w skład prezentacji powinien być możliwie jak najlepiej dostępny dla osób niewidomych, słabowidzących oraz innych używających wyłącznie klawiatury. Aplikacja Flash CS4 Professional posiada wbudowane specjalne schematy udostępniające filmy wideo. Pozwalają one na dodanie napisów oraz przycisków nawigacyjnych umożliwiających zatrzymanie, wznowienie czy przewinięcie filmu, które mogą być wybrane przy pomocy klawiatury.
8. Zapewnienie kontroli odtwarzania dźwięków. Strumienie audio, które są odtwarzane bezpośrednio na stronach internetowych sprawiają kłopoty programom odczytującym ekran. Zawartość dźwiękowa, czyli np. odtwarzana muzyka miesza się z głosem syntetycznym, który jest generowany przez program mówiący. Jest to efekt bardzo nieprzyjemny dla użytkownika gdyż rozprasza jego uwagę. Najważniejszym sposobem zapewnienia kontroli odtwarzania dźwięku jest dodanie do okienka odtwarzania przycisków służących do wznowienia i zatrzymania odtwarzania, oraz przycisków umożliwiających nawigację poprzez jego zawartość.
9. Prawidłowe Wyeksponowanie i wyrażenie struktury prezentacji. Poszczególne slajdy (ramki) prezentacji flash mogą być bardzo złożone pod względem struktury, wyglądu, oraz sposobów nawigacji. W rezultacie są one często bardzo trudne do interpretacji dla programów odczytujących ekran. Aby rozwiązać problemy związane ze skomplikowaną strukturą prezentacji należy dodać do niej opis pozwalający na wyrażenie struktury i znaczenia poszczególnych elementów każdego slajdu. Mogą być one tworzone jako osobne okienka zawierające tekstowy opis slajdu, do których użytkownik może się przenieść w każdej chwili, gdy tego potrzebuje.
10. Opisanie stanu poszczególnych kontrolek. W prezentacjach flash występuje zwykle bardzo wiele różnego rodzaju elementów takich jak: przyciski, pola wyboru, pola edycyjne, listy wyboru itd. Są one nazywane kontrolkami. Ważnym elementem dostosowania prezentacji jest poinformowanie użytkownika o aktualnym stanie każdej kontrolki. Na przykład, jeśli użytkownik naciśnie przycisk "odtwarzaj", który po tym zdarzeniu zmieni swoją nazwę na "Wstrzymaj" należy go o tym fakcie poinformować. Ponowne naciśnięcie takiego przycisku zmienia jego nazwę na "Odtwarzaj", o czym użytkownik powinien być również powiadomiony.
11. Ostrożne używanie kolorów. W prezentacjach flash można używać bardzo wielu różnych kombinacji kolorów. Ze względu na dostępność dla osób słabowidzących, należy pamiętać o tym, aby wybierane kolory przekazywały jakąś konkretną informację i posiadały określone znaczenie dla użytkownika. Zbyt duża ilość używanych kolorów będzie utrudniała mu korzystanie z prezentacji. Dla użytkowników niewidomych nie powinno się stosować alternatywnych opisów w rodzaju "kliknij zielony przycisk" a zamiast tego powinien wystąpić komunikat "kliknij przycisk Odtwarzaj", który oczywiście może mieć zielony kolor. Z tych samych powodów należy pamiętać o zapewnieniu właściwego, wyraźnego kontrastu pomiędzy tłem a samymi elementami prezentacji.

Przygotowana prezentacja flash może być sprawdzona pod względem jej dostępności dla użytkowników posiadających problemy ze wzrokiem. Przewodnik dla osób tworzących prezentacje zawiera tylko najważniejsze zalecenia i wskazówki dotyczące udostępnienia prezentacji flash dla potrzeb użytkowników niewidomych lub słabowidzących. Rzeczywiste, najefektywniejsze i pełne sprawdzenie dostępności prezentacji może być wykonane tylko w praktyce. Firma Adobe proponuje kilka następujących metod sprawdzania dostępności prezentacji.

1. Należy uruchomić prezentację używając jednocześnie programu odczytu ekranu takiego jak Jaws czy Window Eyes i sprawdzić, czy jest ona w pełni czytelna dla użytkownika.
2. Należy sprawdzić działanie prezentacji wyłącznie z użyciem klawiatury, ale bez używania programu odczytu ekranu. Pozwoli to na wyeliminowanie błędów polegających na tym, że niektóre skróty klawiszowe w prezentacji kolidują ze skrótami klawiaturowymi programów odczytujących ekran.
3. W celu poprawienia dostępności prezentacji można użyć narzędzia pochodzącego z pochodzącego od innego producenta niż firma Adobe a służącego do sprawdzania jej dostępności.

W reszcie należy przeprowadzić test prezentacji, którego uczestnikami powinni być potencjalni niewidomi i słabowidzący użytkownicy.

Testery dostepnosci strony WWW

Oczywiście nic nie zastąpi wykwalifikowanego pracownika w celu przeprowadzania szeregu testów dostępności jednak są rozwiązania, które mogą pomoc i zasugerować nam, jakie rzeczy na swojej witrynie powinniśmy poprawić. Podstawową kwestią jest to, aby nasza witryna nie miała błędów składniowych. Takie rzeczy możemy wykryć validatorem dostarczonym przez konsorcjum W3C. Oczywiście jest to podstawa, aby przejść do dalszych etapów validacji i sprawdzania dostępności. Jednym z najpopularniejszych narzędzi jest tzw. WAVE. Ostatnio pewien znajomy przedstawił mi polski odpowiednik, który jest aktualnie w fazie testów. Zachęcam do testowania i informowania o błędach. Polski validator został wyprodukowany pod skrzydłami firmy Utilitia i znajduje się pod tym adresem. Zachęcam wszystkich do przeanalizowania ich strony ponieważ jest ciekawa. Jest to po prostu sugestia, a nie reklama.

Konkluzja

Nie można zapominać o tym, że dostęp informacji szczególnie publicznych jest ustawowo zapewniony mimo, że często niewidomi internauci natrafiają na rożnego rodzaju problemy dlatego należy zrobić wszystko aby zmienić ten stan rzeczy na lepszy. Jest to swojego rodzaju prośba do wszystkich programistów, webmasterów, webdeveloperów, grafików i tak dalej aby zaczęli zauważać problem i zastanawiać się jak go rozwiązać. To, w jakim stopniu osoby niewidome i niedowidzące będą miały dostęp do stron internetowych będzie miał wpływ na ich rozwój, a to z kolei na rozwój społeczeństwa. Przez wiele lat, osoby takie nie miały możliwości czytania gazet, śledzenia tego, co dzieje się na świecie, odsłuchiwania muzyki z internetu czy zawierania wirtualnych znajomości. Komputer był dla nich zbędną maszyną, z której korzystali inni, a oni mogli im jedynie zazdrościć. Czas mija, technika się rozwija, ale wygląda na to, że ciągle zajmujemy się sobą, zapominając o tych, którzy potrzebują kilku dosłownie udogodnień i pomysłów, by w pełni czerpać radość z tego, co nam sprawia przyjemność.

Ponadto gorąco zachęcam do przeczytania kilku materiałów szkoleniowych, które pogłębią Waszą wiedzę dotycząca dostępności aplikacji. Można je znaleźć pod tymi adresami (kolejność losowa):

• Web Accessibility Initiative
• Strona Microsoftu poświecona dostępności
• Dive Into Accessibility W głąb dostępności (znaleziony przypadkiem polska wersja dokumentu) - książka w wersji elektronicznej o tworzeniu dostępnych stron dla osób niepełnosprawnych.
• Przewodnik dla twórców prezentacji Flash
• Dostępne WWW wyprodukowane przez Fundacje Instytutu Rozwoju Regionalnego
• Kurs usability
• Baza wiedzy dotycząca usability
• Dostępność stron internetowych - korzyści w biznesie

Komentarze

• 1

Dodaj komentarz

Zezwolono używać: BBCode
Zabroniono używać: znaczników HTML

Podpis: (Wymagany)

E-mail: (Wymagany, niepublikowany)

Strona WWW: (Nie wymagana)

Token:

Treść tokena: (Przepisz tylko cyfry!)

Treść: (Wymagana)

Tagi

webmaster webmastering programowanie strony www artykul rada projektowanie stron internetowych web html witryny standardy css specyfikacja alt windows flash google usability nvda czytnik ekranow screen reader js javascript java ajax wcag wai supernova jaws eye orca voiceover wytyczne seo wordpress captcha recaptcha adobe wave validator w3c niepelnosprawni html5 css3 accessibility osoby niewidome niedowidzace blind people