Niedziela 1 października 2006 | Napisał: WebAIM
Jeśli wydaje Ci się, że testowanie stron czytnikami ekranu to jakaś abstrakcja. Jeśli mimo tego, masz dobrą wolę i chcesz oferować strony, które są przystępne dla jak najszerszej grupy odbiorców. Ten artykuł odpowiada na wiele pytań, które możesz sobie zadawać. Oto przewodnik, który pomaga ugryźć niełatwą problematykę testów z czytnikami ekranu.
Słuchanie strony zamiast oglądania jej może być doświadczeniem, które otworzy Ci oczy (wybacz grę słów) zabierając Cię poza bezpieczną i wygodną przestrzeń postrzegania wzrokowego. Pozwala widzącym użytkownikom sprawdzić stronę z całkiem innej perspektywy: z perspektywy osoby niewidomej. Niejednokrotnie odnajdziesz błędy, których dostrzeżenie wzrokiem byłoby trudne. Na przykład literówki stają się czytelniejsze, kiedy słyszysz słowa źle wymawiane przez czytnik ekranu. Czytnik ekranu jest także dobrym narzędziem do sprawdzania trafności i jakości tekstów zawartych w alt. Ostatnio, słuchając jednej ze stron internetowych zrozumiałem, że teksty wpisane w alt były do niczego. Grafika mówiła: “Szukaj” ale w tekście alt było wpisane “Opcje”. Zajęło mi chwilę zrozumienie dlaczego czytnik ekranu nie czytał tekstu alt dla przycisku “Szukaj”, w końcu skojarzyłem, że czytał, ale alt był niewłaściwy. Czytniki ekranu pomagają także zidentyfikować problem z kolejnością treści, kodem tabel, elementami formularzy oraz wieloma innymi aspektami dostępności.
Być może. Jeśli wiesz jak korzystać z czytnika ekranu, tego rodzaju testy są niezwykle wartościowe. Jeśli nie umiesz dobrze używać czytnika, testowanie z nim może być irytyujące i przynieść efekt odwrotny do zamierzonego. Mogłoby się zdarzyć, że mylnie wziąłbyś niemal wszystko co jest na stronie za niedostępne, podczas gdy podstawowym problemem byłby twój brak znajomości czytnika ekranu.
Cóż, byłby to zbyt prosty unik, bo zanim zaczniesz szukać wymówek, zacznijmy od tego czego nie wiesz. Użytkownicy czytników ekranu to podstawowi beneficjenci twoich wysiłków na rzecz dostępności, więc dobrze byłoby znać ich potrzeby. Rzecz jasna, nie powinieneś także wpadać w pułapkę myślenia, że dostępność stosuje się wyłącznie do użytkowników czytników ekranu. Zbyt wiele osób koncentruje się na użytkownikach niewidzących i wyłącza osoby z innymi typami niepełnosprawności (ruchowe, słuchowe, poznawcze, niedowidzenie, itd.), których potrzeby są równie istotne. Ale skoro zajmujemy się tutaj testowaniem za pomocą czytnika ekranu, zajmijmy się potrzebami związanymi z tym narzędziem.
Mimo tego, że czytnik ekranu nie jest "przeglądarką" tak jak Firefox, Opera, Safari, Netscape oraz Internet Explorer (w większości przypadków czytnik korzysta z tych przeglądarek), czytnik ekranu odczytuje treść strony internetowej w inny sposób niż czynią to widzący użytkownicy. Jeśli nie rozumiesz tych różnic, nie zrozumiesz jakie są wymagania dostępności związanej z użytkownikami czytników ekranu i nie będziesz w stanie tworzyć stron biorąc pod uwagę tych odbiorców.
Niewidomi użytkownicy przeglądają strony w całkowicie inny sposób, porównując do tego jak robią to widzący użytkownicy. Po pierwsze, czytnik ekranu wymaga od użytkownika znajomości serii skrótów klawiszowych. Widzący użytkownicy nawigują zwykle za pomocą myszki. Są także przyzwyczajeni do wygody skanowania strony wzrokiem praktycznie we wszystkich kierunkach na raz. Oba te przyzwyczajenia, osoba widząca, testując stronę z czytnikiem ekranu musi odłożyć na bok.
Ale nawyki i techniki nawigacji po stronach stanowią tylko część problemu. Naprawdę jest tak, że czytnik ekranu zmusza Cię do zmiany myślenia. Osoba widząca traktuje stronę jako zbiór bloków informacji zorganizowanych w układ wizualny. Większość stron ma nawigację umieszczoną na górze albo z boku. Te miejsca często zawierają grafiki, które mają przyciągnąć Twoją uwage do "ważnych" elementów jak nowa treść na stronie, promocje cenowe lub cokolwiek innego. Dobry design w czasie 1-2 sekund pozwoli Ci zrozumieć organizację strony oraz zwróci Twoją uwagę na najważniejsze elementy.
Użytkownicy czytnika ekranu nie mogą zbadać całości strony tak szybko. Treść strony jest linearna i tekstowa. Użytkownicy Ci, nie myślą w kategoriach prawej czy lewej strony albo pozycji na stronie. Jest to dla nich nieistotne czy najważniejsze elementy treści są umiejscowione na środku, zaznaczone wyraźniejszymi kolorami i bardziej efektownym designem. Pozycjonowanie i elementy designu same w sobie nie pomagają ani nie zaburzają dostępności treści dla użytkowników czytników ekranu. Te informacje są dla nich zwyczajnie bezużyteczne.
Użytkownicy ekranu słyszą tytuł strony (zakładając, że taki istnieje), a następnie każdy element tekstowy w porządku jego występowania w kodzie dokumentu. Uwaga, nie mam na myśli, że słyszą kod strony, ale wszystko co ujrzelibyście patrząc w kod i usuwając wszystkie zaczniki kodu – pozostałby tyko tekst. I to właśnie tekst oraz kolejność tekstu są najważniejsze. Dla przybliżenia takiego rodzaju linearyzacji, możesz skopiować całą stronę (nie kod, ale to co widać w przeglądarce) wciskając CTRL+A (w Windowsie) lub Apple+A (Mac OS), a następnie wkleić wszystko do edytora tekstu takiego jak Notepad albo SimpleText.
Wspomniałem, że jest to tylko i wyłącznie przybliżenie, bowiem użytkowncy czytnika ekranu mają dostęp do większej ilości informacji, niż to co ujrzysz w edytorze. Mają dostęp do różnego rodzaju sposobów nawigacji w treści. Na przykład, w bardziej nowoczesnych czytnikach ekranu można się dowiedzieć gdzie zaczyna się lista a gdzie kończy a nawet tego z ilu elementów się składa. Czytniki ekranu pozwalają użytkownikom nawigować w tabelkach z danymi komórka po komórce (zakładając, że są to dobrze napisane tabelki), informując użytkownika jaki jest nagłówek dla danej komórki. Użytkownik czytnika może także, między innymi, nawigować pomiędzy nagłówkami, otworzyć listę linków alfabetycznie ułożoną, używać klawisza tab w celu nawigacji zgodnie z kolejnością linków, oraz wyszukiwać na stronie odpowiednich słów kluczowych. Zatem, mimo że treść jest linearna, użytkownik czytnika ma sporo możliwości i różnych sposobów nawigacji w treści, a każdy z użytkowników ma swoje ulubione metody. Nigdy nie można powiedzieć, że użytkownicy czytnika "zawsze" robią "coś" w ten czy inny sposób. Jest zbyt wiele indywidualnych różnic.
Rzadkością jest aby użytkownik czytnika chciał wysłuchać całą stronę od początku do końca bez przeskakiwania pewnych części treści. Mogą to być takie treści jak linki nawigacyjne na górze strony, informacja o prawach autorskich na dole oraz inne elementy znajdujące się pomiędzy nimi.Użytkownicy są skłonni do wysłuchania całej strony jeśli są nieobeznani z serwisem albo treść jest dla nich bardzo istotna, ale w większości przypadków usiłują odnaleźć te informacje, które są im potrzebne, tak szybko jak to możliwe. Przeszukiwanie strony oraz korzystanie z listy linków (albo tabowanie z linku do linku) należą do tych sposobów, które służą do szybkiego przeszukiwania treści.
Nie masz wiedzieć. Możesz ewentualnie przypuszczać, że ktoś może użyć w pewnym momencie wszystkich dostęnych metod. Nie możesz przewidzieć i kontrolować jak użytkownicy korzystają z opublikowanej przez Ciebie treści. Jedno co możesz, to być pewnym, że Twoja strona nie utrudnia korzystania z takich czy innych sposobów przeglądania strony.
Dam Ci kilka przykładów. Nie da się nawigować skacząc pomiędzy nagłówkami strony jeśli na stronie nie ma nagłówków. Nie da się usłyszeć znaczenia grafiki zamieszczonej na stronie jeśli grafika nie ma alternatywnego tekstu. Nic nie znaczące linki, takie jak: "kliknij tu" albo "więcej" dają niewielki albo żaden punkt zaczepienia i żadnej możliwości zrozumienia gdzie użytkownik zostanie przeniesiony po kliknięciu w ten link. To właśnie kilka z przykładowych barier. Stosowanie zasad Web Content Accessibility Guidelines (WCAG) lub Section 508 guidelines pomoże Ci rozprawić się z tymi przeszkodami, choć te zalecenia nie są niezawodne. W gruncie rzeczy, żadna metoda nie jest niezastąpiona. Największe powodzenie osiągniesz stosując się do zasad oraz testując strony.
WebAIM przygotował listę skrotów klawiszowych dla JAWSa (z Freedom Scientific) oraz skrótów do Home Page Readera (z IBM). Sieciowy poradnik Window Eyes z GW Micro zawiera informacje na temat skrótów w dziale "Appendix A.1: Hot Keys - Quick Reference Guide.". Skróty klawiszowe dla HALa (z Dolphin) są dostępne w "pomocy".
Szczerze mówiąc, nie oczkiwałbym od kogokolwiek nauczenia się wszystkich wymienionych wyżej programów na poziomie zaawansowanym. Większość użytkowników czytników korzysta tylko z jednego. Problem w tym, że istnieje pewien wybór czytników i nieznaczne różnice pomiędzy nimi w interpretowaniu stron internetowych.
To dobre pytanie. Wiele jest różnic powierzchownych i nieistotnych z punktu widzenia twórcy stron internetowych. Na przykład JAWS mówi "link" przed każdym linkiem. Home Page Reader nie robi tego. Zamiast tego mówi innym głosem w przypadku linku aby skontrastować z tekstem (żeński głos dla linków, męski dla tekstu). To całkiem ciekawa różnica pomiędzy czytnikami ale nie wpływa na dostępność linków. Większość różnic pomiędzy czytnikami ekranu kwalifikuje się do kategorii "interesujących ale nie tak ważnych". Z drugiej strony, niektóre róznice między czytnikami w kwestii technologii, które wspierają albo jakie mają niedociągnięcia oraz innych różnic jakościowych są istotne. Na przykład Adobe jako pierwsze włączyło dodatki dostępnościowe do Adobe Readera a tylko kilka czytników wspierało te dodatki. Dziś są one bardziej rozpowszechnione wśród czytników ekranu.
W pewnym sensie tak, ale z drugiej strony – niekoniecznie. Jako, że wciąż pokazują się nowe technologie, ważne jest, żeby być na bieżąco z ich rozwojem. Jednym ze sposobów, żeby być na bieżąco jest odwiedzanie stron takich jak WebAIM albo zapisanie się na listy dyskusyjne związane z tematem. Solidni twórcy stron mają aktualną wiedzę na temat wersji przeglądarek, nowych technologii oraz standardów. Czytniki ekranu powinny być dodane do tej listy. Twórcy stron internetowych powinni być co najmniej świadomi istnienia różnych czytników oraz tego jakie technologie wspierają.
Z drugiej strony, lepiej żeby twórcy stron bardziej zwracali uwage na zasady i zalecenia dotyczące dostępności niż na różnice między czytnikami ekranu. Nie byłoby dobrze gdyby twórcy stron projektowali wyłącznie z myślą o jednym czytniku ekranu. Mogłoby się wtedy zdarzyć, że treść mogłaby być mniej przyjazna dla użytkowników innych czytników.
Jedno jest pewne. Mógłbyś, bowiem sporo byś się nauczył. Szczególnie w przypadku bardziej rozbudowanych stron z JavaScript, Flashem czy plikami PDF. Dobrze by było wówczas przetestować stronę w tak wielu narzędziach jak to możliwe, włączając w to szereg czytników ekranu. W przypadku stron prostszych, testy w jednym/dwóch czytnikach powinno wystarczyć.
Dwa najpopularniejsze czytniki ekranu w Stanach zjednoczonych to JAWS i Window Eyes [w polsce też, przyp.tłum.] Przetestuj swoją stronę w co najmniej jednym z nich. Innym czytnikiem ekranu godnym wypróbowania jest Home Page Reader, chociaż jest on znacznie mniej popularny wśród niewidomych użytkowników czytników ekranu. Widzący użytkownicy uważają zwykle Home Page Readera za prostszy w obsłudze niż JAWS albo Window Eyes. Wszystkie trzy mają podobne możliwości jeśli chodzi o przeględanie stron, więc można z nimi pracować. Ważne jest też, w którym najwygodniej Ci się pracuje. HAL jest mniej popularny albo godny uwagi.
To wspaniały pomysł z jednej strony ale z drugiej - niekoniecznie. Niewidomy użytkownik jest twoim odbiorcą, więc możesz się od niego nauczyć. Wielu z nich byłoby szczęśliwych dzieląc się z Tobą opinią i ekspertyzą. Szczególnie duże organizacje/firmy powinny rozważyć zatrudnienie jednego z nich. Niektórzy użytkownicy mogliby służyć konsultacjami w projektach. Kiedy tylko to możliwe zrób takie testy.
Jest także kilka gorszych stron takiego scenariusza, lub co najmniej kilka uwag do takiego rozwiązania, które powinieneś wziąć pod uwagę.
Po pierwsze nie wszyscy niewidomi są biegli w używaniu czytników ekranu. Niektórzy są, inni nie. Niedoświadczony użytkownik może zaoferować wartościową perspektywę (nowicjusza), ale może też nie mieć szerszej perspektywy na problematykę użytkowania czytników do przeglądania stron. W wielu przypadkach, niedoświadczony użytkownik może źle Ci doradzić, co może wynikać właśnie z braku doświadczenia. Z drugiej strony, sprawny użytkownik czytnika może nie umieć przedstawić Ci szerszej perspektywy biorącej pod uwagę mniej doświadczonych użytkowników. Inaczej mówiąc, tak jak w przypadku każdego rodzaju testów z użytkownikami, powinienś się upewnić, że testujesz strony z takimi użytkownikami, którzy odpowiadają twojej grupie odbiorców. Nie powinieneś wpadać w pułapkę mówiąc np.: "Tomek, niewidomy użytkownik czytnika ekranu powiedział, że powinniśmy zrobić tak czy tak". Tomek może być ale nie musi przedstawicielem szerszej grupy użytkowników ekranu. Idealnie by było, gdybyś mógł mieć kontakt z grupą użytkowników o różnym stopniu zaawansowania. To może nie być realne i praktyczne mieć zawsze dostęp do takiej grupy i mieć ją na liście płac, ale to nie byłby zły pomysł zainwestować od czasu do czasu w badania z grupą użytkowników, przede wszystkim przed uruchomieniem nowych wersji dużych serwisów.
Po drugie, niewidomi użytkownicy mogą ale nie muszą wykryć, że treść jest dla nich niedostępna. Na przykład, jeśli główna treść strony jest zawarta w złożonych i niedostęnych skryptach JavaScript, użytkownik może nawet nie wiedzieć, że tego rodzaju treść istnieje. Widzący użytkownik mógłby patrzeć na treść i słuchać jej. Taka osoba mogłaby rozpoznać, że główna treść strony nie jest czytana. Oczywiście, widzenie może być także wadą w procesie testowania. Widzący użytkownicy mogą za bardzo koncentrować się na tym co widzą i nie zdawać sobie sprawy, że nie wszystko co widzą jest czytane przez czytnik ekranu.
To co chcę Ci przekazać, to że powinieneś testować strony z różnymi ludźmi z różnymi umiejętnościami. Nie dobrze jest opierać się na opinii jednej osoby. Jednym ze sposobów włączenia osób niewidomych do testów jest poradzenie się ich na liście dyskusyjnej WebAIM albo innych forach (np. na forum dostepne.info, przyp. tłum.). Niejednokrotnie mogą poradzić za darmo. W innym wypadku będzie bardziej właściwe, żebyś wynajął ich do przeprowadzenia testów Twoich usług.
Niekiedy tak, może się to wiązać z dużym nakładem pracy. Nieraz nie będziesz dysponował czasem ani środkami, żeby przetestować gruntownie Twoją stronę. Wielu ludzi chciałoby mieć dostęp do takiej grupy na stałe, może być jednak problem ze znalezieniem osób o różnego rodzaju stopniu niepełnosprawności.
Co więcej, wdrażając duże modyfikacje do strony lub tworząc nowy interfejs, albo badając szczegółowo dostępność istniejącej strony, nawet eksperci, którzy od długiego czasu tworzą myśląć o dostępności mogą skorzystać z tego rodzaju testów. Ja także nie jestem wyjątkiem.
Z praktycznego punktu widzenia jest więcej niż jeden sposób na otrzymanie informacji tego rodzaju. Regularne testy mogą być drogie i czasochłonne. Dają jednak dogłębne wgląd w problemy. Mało prawdopodobne, byś mógł prowadzić tego rodzaju badania często, chyba, że masz dużo pieniędzy i czasu do dyspozycji. Najtańszym sposobem jest mieć kontakt z kilkoma osobami – znajomymi, które za pośrednictwem forów dyskusyjnych pomagają Ci uzyskać informacje na temat dostępności.
Drogie, z wyjątkiem Home Page Readera. JAWS jest najdroższy, a jego cena kształtuje się pomiędzy 895$ a 1495$ w zależności o zestawu funkcji. Window Eyes kosztuje niewiele mniej. Home Page Reader jest znacznie tańszy, kosztuje około 142$. Duża różnica w cenie bierze się z tego, że Home Page Reader jest przeznaczony przede wszystkim do korzystania z internetu. JAWS i Window Eyes są bardziej rozbudowane i obsługują więcej aplikacji takich jak edytory tekstu, arkusze kalkulacyjne, programy finansowe, systemy operacyjne. Powodem tego, że Home Page Reader jest mniej popularny jest to, że niewidomi lubią używać jednego czytnika do wszystkich czynności a nie przełączać się pomiędzy czytnikami.
Prawdę mówiąc nie. Jeśli masz dużo pieniędzy – kup te czytniki ekranu. Jeśli nie masz, kup Home Page Readera. Jeśli nie chcesz wydawać pieniędzy jest na to sposób: ściągnij wersje demonstracyjne JAWSa i Window Eyesa. Te wersje demonstracyjne działają 40 minut po uruchomieniu. Po 40 minutach musisz uruchomić komputer, żeby znów skorzystać z czytnika ekranu. (Tak właśnie, musisz naprawdę uruchomić ponownie komputer, nie wystarczy ponowne uruchomienie czytnika). Te ograniczone wersje są idealne dla twórców stron internetowych do testowania stron. Niejednokrotnie wystarczy te 40 minut, żebyś przetestował swoją stronę. Czasem będziesz musiał uruchomić ponownie komputer aby kontynuować testy, ale to nie jest wcale takie złe, bo nie musisz płacić za to oprogramowanie.
Jeśli uważasz, że nauka tego jak uczynić stronę dostępną dla użytkoników czytników ekranu jest niewygodna – odpowiem Ci pytaniem. Jak ważne jest dla Ciebie korzystanie z internetu? Nie wiem jak dla Ciebie ale dla mnie internet stał się ważną częścią życia. Dla mnie, prawdziwą "niewygodą" byłaby niemożność korzystania z tych dobrodziejstw, które oferuje internet. Dla użytkowników czytników ekranu tego rodzaju niewygoda jest codziennością.
Artykuł oryginalny został opublikowany na stronie WebAIM.
Jeśli masz jakiekolwiek pytania związane z korzystaniem, z któregoś z czytników ekranu, na które nie znalazłeś odpowiedzi w powyższym tekście - zapraszamy na Forum Dostepne.info. Postaramy się pomóc.
Teksty własne lub tłumaczenia z angielskiego, francuskiego i niemieckiego.