Dostępne.info

Testowanie stron czytnikami ekranu

WebAIM — 2006-10-01T09:57:27Z

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.

Jakie są korzyści testowania stron internetowych 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.

Czy powinienem zawsze testować dostępność strony za pomocą czytnika ekranu?

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.

Co więc jeśli wcale nie umiem używać czytnika ekranu, nie powinienem nawet próbować?

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.

Jakie sa podstawowe różnice w tym jak widzący użytkownicy przeglądają strony a jak to robią użytkownicy czytników ekranu?

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.

W jaki więc sposób użytkownicy czytników ekranu doświadczają stron?

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.

To skąd mam wiedzieć, z jakich metod będą korzystać użytkownicy ekranu przeglądając moją stronę?

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.

Co stanowi w takim przypadku utrudnienie?

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.

Jak mogę nauczyć się skrótów klawiszowych czytników ekranu?

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".

Chwila, chwila! Jak wielu czytników ekranu powinienem się nauczyć?

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.

Jak duże są te "nieznaczne różnice" i czy twórcy mają brać owe różnice pod uwagę realizując strony?

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.

Czy naprawdę oczekujesz, że twórcy stron będą na bieżąco z tymi wszystkimi różnicami?

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.

To w końcu powinienem testować strony z tymi wszytkimi czytnikami czy nie?

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ć.

"W jednym/dwóch" – czyli w których?

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.

Czy nie byłoby prostsze, jeśli niewidomy użytkownik przetestowałby moją stronę, żebym nie musiał uczyć się tego całego softu?

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.

Czy to dużo pracy, aby zebrać opinię różnych użytkowników?

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.

Jak drogie są czytniki ekranu?

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.

Czyli będę musiał wydać masę pieniędzy, tak?

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.

Standardy niezmiennie ważne

Roger Johansson — 2006-09-23T00:34:29Z

Przez ostatnie kilka lat, mogliśmy zaobserwować wciąż zwiększający się poziom zainteresowania i działań związanych ze standardami sieciowymi. Jak się jednak okazuje, wiedza nie przeniknęła zbyt głęboko...

Podczas mojej kariery twórcy stron internetowych, szukając rozwiązań różnych problemów znalazłem niezliczoną ilość wartościowej pomocy oraz niesamowitych zasobów. Przez ostatnie kilka lat informacje, które znalazłem były publikowane na blogach i forach poświęcających uwagę standardom sieciowym i dostępności. To niesamowite, że tak wiele osób ma ochotę spędzać tak dużo czasu, dzieląc się wiedzą z innymi i pomagać czynić internet lepszym miejscem.

Z drugiej strony – i tutaj wracam do głównego tematu niniejszego tekstu – zdarza się, że słychać pomruki osób, którym wydaje się, że dosyć już powiedziano na temat dobrych technik i w gruncie rzeczy należałoby zająć się czymś ciekawszym. Niektórzy twierdzą, że standardy nie są już ważne, bo większość twórców stron już pracuje wg nich. Inni mówią, że nudne jest czytanie kolejnych artykułów, wpisów do blogów i książek na temat CSS, HTML, dostępności i użyteczności. Może nie widzą celu w publikowaniu kolejnych tekstów, bo niewiele się z nich nauczyli ?

To na pewno jakiś żart...

Zorientowani to drobna mniejszość

Jeśli naprawdę sądzisz, że większość tworzących strony dobrze sobie radzi ze standardami, dostępnością i użytecznością i stara się pracować wg zestawu najlepszych zaleceń, powiedz mi na jakiej żyjesz planecie. Na planecie Ziemia, twórcy stron internetowych świadomi standardów są mikroskopijną mniejszością. Mikroskopijną. Może i jesteśmy głośni i może jako jedyni piszemy artykuły i książki ale naprawdę jest nas niewielu.

Każdego, kto myśli, że nie ma potrzeby pisania kolejnego artykułu lub książki na temat standardów, CSS, dostępności, łagodnej degradacji, stopniowej komplikacji interfejsów, lub czegokolwiek co związane z dobrą robotą, zachęcam do rzucenia okiem wokół siebie.

No dalej, przetestuj niektóre produkty tworzone przez agencje w Twoim mieście, Państwie. Spójrz na efekty pracy Twoich kolegów i konkurencji. Czy naprawdę powiedziałbyś, że nie ma już nic czego mogliby się nauczyć? Czy uważasz, że nie skorzystaliby na przeczytaniu artykułu, który pokazuje jak zmienić przestarzałe techniki na nowoczesne, dostępne i przyjazne wyszukiwarkom? Czy strony, które właśnie przetestowałeś mają poprawny kod, semantyczną strukturę i nie występują w nich problemy dostępnościowe? Poważnie? O rety! Musisz żyć w naprawdę małej społeczności, w której w branży usług internetowych istnieje tylko jedna firma – Twoja.

Osoby, które nie chcą czytać więcej artykułów na temat dobrej praktyki, zdają się nie rozumieć, że tylko niewielka mniejszość twórców, którzy pracują-żeby-żyć czyta blogi. Jeszcze mniej czyta blogi publikujące na temat tworzenia stron, odwiedzaja strony takie jak ta (Vitamin przyp.tł) i czytaja książki na temat nowoczesnych technik tworzenia stron internetowych. Większość (czytaj: więcej niż 50%) osób, które tworzą strony robi to przede wszystkim, żeby zarobić na życie a nie dlatego, że ich pasją jest tworzenie stron albo propagowanie idei równego dostępu do informacji dla każdego. Tak długo jak mogą się z tego utrzymać, ta branża jest dla nich dobra. Jeśli techniki, których nauczyli się wiele lat temu zdają się działać i nikt nie narzeka – to im wystarczy.

Na temat standardów, CSS, dostępności i semantycznej budowy kodu napisano wiele artykułów i niezły stos książek. Zapewniam Cię, że nawet Ci, którzy na codzień pracują zgodnie ze standardami i zajmują się ich promocją nie słyszeli o wszystkich. Wszystko o czym słyszeliśmy może się często powtarzać. Ale standardy i problematyka dostępności nie są “martwe” ani “nudne”, nie są też tematami, o których ktokolwiek wiedziałby wszystko. Nie sądzę, żeby istniał ktokolwiek, kto wie naprawdę wszystko w tej dziedzinie. Jeśli uważasz, że dany temat jest nudny lub myślisz, że posiadłeś już całą wiedzę o nim – nie ma problemu. Nikt Cię nie zmusza do czytania wszystkiego co jest publikowane.

Mam niezwykle mocne przeświadczenie, że standardy sieciowe są ważne dziś tak samo jak pięć lat temu. Komunikat musi być powtarzany wciąż i od nowa, tak długo jak ogromna większość twórców stron nie zacznie tworzyć zgodnie ze standardami.

Problem w tym, jak dostarczyć ten komunikat wszystkim tym, którzy powinni się go otrzymać.

Docieranie do tych, do których trzeba dotrzeć

Tak jak powiedziałem, większość ludzi, do których chcemy dotrzeć nie czyta naszych blogów. Nigdy nie słyszeli o A List Apart, Zeldmanie ani CSS Zen Garden. Musimy więc znaleźć sposób na propagowanie informacji na zewnątrz małych grup partyzantów standardów. Poniżej kilka propozycji dla tych, którzy chcą się tym zająć:

Fora dyskusyjne i listy dyskusyjne. Być może odwiedzasz forum, na którym podstawową tematyką jest PHP, ASP.Net, design, flash, albo tematy niekoniecznie związane ze standardami i dostępnością. Rób co tylko możesz aby rozsiewać ziarno informacji, kiedy tylko zaistnieje taka możliwość.
Lokalne spotkania. Zorganizuj kameralne spotkania lokalnych twórców stron. Nie zdradzaj nic na temat standardów przed spotkaniem. Twoim celem jest zebranie jakiejś grupy ludzi i rozmowa na temat standardów. Jest prawdopodobne, że kilka osób będzie zainteresowanych rozmową na temat dobrych technik. Później to oni będą mówić o tym znajomym z branży i rozsiewać informację.
Prasa drukowana. Z mojego doświadczenia wynika, że wielu ludzi z branży woli czytać magazyny drukowane niż publikacje sieciowe. Skontaktuj się z lokalną ( ogólnokrajową) prasą tematyczną i zaproponuj napisanie tekstu. To nie muszą być nie wiadomo jakie artykuły. Zacznij od przesyłania krótkich informacji do opublikowania w dziale z poradami jeśli taki mają. Może nawet zostaniesz opłacony.
Edukacja. To jest kawał roboty. Tak wiele szkół uczy studentów projektowania stron wg starych wzorców. Jeśli istnieje sposób w jaki możesz wpłynąć na nauczycieli, aby zaktualizowali i udoskonalili wiedzę, którą przekazują, wiele może być dokonane. WaSP Education Task Force robi wiele na tym gruncie i jeśli możesz wspomóc tego rodzaju działania – zrób to.

Docieranie do tych, którzy nie chcą by do nich dotrzeć

Czytanie artykułów i słuchanie prezentacji niekoniecznie zmieni metody pracy. Mimo to, wiele osób będzie zainteresowanych polepszeniem jakości produktów jakie oferują. Są jednak dwie grupy ludzi, którzy wg mnie są bardzo oporni (wybacz proszę uogólnianie):

twórcy o skłonnościach czysto graficznych i designerskich, którym nie zależy by internet opierał się na jakichkolwiek logicznych zasadach. Chcą by internet był czysto wizualnym medium i traktują sieć jakby była zbiorem drukowanych ulotek, grą komputerową i telewizją.
programiści tworzący systemy informatyczne, których nie interesuje oprogramowanie od strony klienta.

Prawdę mówiąc nie mam pomysłu jak dotrzeć do tych dwóch grup. Może Ty wiesz jak można ich zainteresować?

Przed nami wciąż długa droga

Jeśli uważasz się za adwokata standardów i dobrej roboty, nie przestawaj pomagać, wyjaśniać i czynić łatwiejszym zrozumienie i stosowanie przez rzesze twórców nowoczesnych technik projektowania i budowania stron.

Nie przestawajmy walczyć zbyt wcześnie. Bitwa, jeśli też widzisz to jako bitwę, nie została wygrana. Powiem więcej. To dopiero początek.

Artykuł opublikowany zaledwie dwa dni temu w magazynie ThinkVitamin. Autorem jest propagator standardów Roger Johansson, autor bardzo dobrego bloga 456 Berea Street.

Link do oryginalnego tekstu w jęz. angielskim.

Myśl elastycznie

Peter-Paul Koch — 2006-09-21T20:47:36Z

Czasy zmieniły się na lepsze od kiedy nadeszła era standardów sieciowych. Teraz można napisać skrypt albo deklarację CSS i być pewnym, że Mozilla, Explorer i Opera zinterpretują go z grubsza w podobny sposób. Pewność ta jest niewymownym luksusem, jeśli porównać do sytuacji, którą musieliśmy znosić kilka lat temu.

Co prawda, nie wszystkie niekompatybilności pomiędzy przeglądarkami zniknęły, powinniśmy też zwracać uwagę na kilka przestarzałych przeglądarek. Co więc powinniśmy robić? Stosować hacki do problemów, które niedługo przestaną istnieć? Stosować detekcję niepożądanego oprogramowania oraz ignorować jego użytkowników?

... a może zapewniać obejścia problemów dla mniej popularnych przeglądarek?

Trudna decyzja.

Rok temu pisałem kod strony, która wyglądała znacznie gorzej w Netscape 4 niż w nowszych narzędziach. Robiłem to celowo. Chciałem korzystać z nowoczesnego CSSa nie martwiąc się o bardziewne przeglądarki.

Niemniej jednak, była to trudna decyzja. Zostałem nauczony tego, aby każdy layout wyglądał tak samo, co do piksela, w każdej ważniejszej przeglądarce, i tego, że lekceważenie Netscape'a 4 jest nie do zaakceptowania.

Oglądałem się nerwowo, spodziewając się nieprzyjemnych uwag, że źle wdrożyłem taki czy inny layout, i że w gruncie rzeczy nie wiem co robię. Szczęśliwie nikt się nie spostrzegł, bo nikt nie testował w Netscape 4.

Później zrozumiałem, że nawet jeśli ktokolwiek zweryfikowałby kompatybilność nie przejąłbym się szczególnie. Sumiennie pracowałem nad wszystkimi problemami, do czego przecież zostałem wynajęty: strona była czytelna i nawigowalna. Ładnie się degradowała.

Łagodna degradacja.

Pomijając fakt, że jest to najśliczniejszy termin w deweloperskim słowniku, “łagodna degradacja”, jest ona także prostą ale potężną techniką. Pierwszym krokiem do skutecznego stosowania tej techniki jest elastyczne myślenie. Oznacza ono akceptację nieprzewidywalnych zasad rządzących narzędziami, które stosuje użytkownik do przeglądania sieci.

Łagodna degradacja oznacza, że Twoja strona działa jeśli jest przeglądana w narzędziach gorzej niż akceptowalnych, w których zaawansowane efekty nie działają (brak CSS w Netscape, brak obrazków w przegądarkach głosowych). Zasada jest prosta. Dodaj do strony wszystkie efekty, które pragniesz dodać ale upewnij się, że bez nich strona dobrze funkcjonuje.

Łagodna degradacja opiera się na dwóch elementarnych zasadach:

Każda przeglądarka musi być zdolna do zinterpretowania treści strony.
Każda przeglądarka musi pozwolić na skuteczną nawigację na stronie.

Zobacz jak wygląda Twój HTML bez CSS i JavaScript. Czy cały tekst jest czytelny? Czy kolejność elementów jest logiczna? Czy wszystkie link działają w odpowiedniej kolejności? Jeśli tak jest, zbudowałeś elastyczną, prostą podwalinę dla Twojej strony.

Teraz możesz dodać kolejne warstwy z bajerami, pamiętając o elastyczności. Jak strona będzie wyglądać w innych rozdzielczościach niż najpopularniejsze? Czy strona będzie dostępna bez nawigacji DHTML? A co z niepewnymi atrybutami CSS? Co będzie gdy niektóre efekty nie będą działać? A co jeśli wszystkie cudeńka zawiodą? Na całej linii?

Nie martw się o odpowiedzi, stawianie pytań jest ważniejsze. Dorzuć jeden dzień do procesu tworzenia następnej strony, pół dnia do kolejnej. Rozważaj cały czas te pytania. Zanim zajmiejsz się trzecią stroną odpowiedzi pojawią się same.

Ucieczka ze sztywnych ram

Myślenie elastyczne pomoże Ci przejść obronną ręką przez rozliczne bagna pomniejszych błędów. Jako przykład weźmy problem box model, zapewne jeden z nabardziej skomplikowanych poroblemów kompatybilności w layoutach opartych na CSS.

w box modelu W3C szerokość bloku określa szerokość zawartości co wyklucza z tego pola padding i border;
implementacja Microsoftu uznaje szerokość od border do border, czyli włącza padding i border.

Mozilla i Opera trzymają się standardu W3C ale Explorer korzysta z modelu Microsoftu, przez co my, biedni twórcy stron mamy o jedną zgryzotę więcej.

Możliwe jest przełączenie Explorera 6 w tryb standardu W3C przez sprytne użycie deklaracji doctype i na odwrót można przełączyć Mozillę w tryb Microsoftu. Dostępny jest także odpowiedni hack CSS.

Mamy zatem mnóstwo sposobów na złożone wyminięcie problemu ... ale czy utrzymujemy zgodność z zasadą prostoty?

Najprostszym sposobem na uniknięcie problemu box model jest takie projektowanie, że nie przeszkadza on bardzo. Jeśli Twój blok ma stałą szerokość, padding na 5px a border na 1px, Explorer pokaże ten blok o 12px mniejszy niż inne przeglądarki. Jeśli layout jest wystarczająco elastyczny, żeby poradzić sobie z tą różnicą – nie musisz się martwić.

Niekiedy nie ma wiele miejsca na tego rodzaju elastyczność. Możesz sobie wówczas zadać pytanie, czy layout nie jest zbyt skomplikowany? Początkujący twórcy stron mają skłonność do zbyt dużej sztywności myślenia i zakładają, że strona będzie wyglądać identycznie z tym jak ją zaprojektowali. W takich przypadkach szybka lekcja elastycznego projektownia jest wystarczającym remedium.

Wnioski

W moim mniemaniu łagodna degradacja i elastyczny design są podzbiorem elastycznego myślenia. Pierwsze pomaga rozwiązać problemy z różnicami w przeglądarkach, drugie pomaga odpuścić sobie precyzję co do piksela w trakcie wdrażania projektu graficznego.

Myśl elastycznie. Strona internetowa nie jest sztywnym medium. Jest nieprzewidywalna. Z Twoją stroną mogą się stać rzeczy, których nie przewidzisz i najlepsze co możesz zrobić jest popłynąć z prądem.

Projektuj wg zasady prostoty. Elastyczność stron nie jest problemem, jest rozwiązaniem. Jeśli jesteś w stanie zaakceptować, że twoja strona nigdy nie będzie widziana dokładnie jak chcesz, zrozumiesz ducha sieci i jej standardy.

Atrykuł publikuję za zgodą Petera-Paula. Ukazał się w magazynie Digital Web 2 października 2002 roku. URL: http://www.digital-web.com/articles/fluid_thinking/

Siłą rzeczy część komentarzy odnoszących się do przeglądarek jest nieco zdezaktualizowana ale najważniejszy - i wciąż aktualny - jest kluczowy przekaz.

Manifest Accessibility Task Force

The Web Standards Project — 2006-09-19T05:32:21Z

Internet może być prawdziwie demokratycznym medium, które czyni życie osób niepełnosprawnych lepszym. Osoby niewidome i z zaburzeniami wzroku mogą kupować przez internet. Ci, którzy mają problemy poznawcze mogą uczyć się przez internet we własnym tempie. Użytkownicy, z zaburzeniami słuchu mają dostęp do treści multimedialnych. Ludzie mogą spotykać się przez internet, uczestniczyć i socjalizować bez uprzedzeń i potencjalnie bez żadnych barier.

W wielu przypadkach ta idea stała się rzeczywistością. Jednak nie wszędzie. Wierzymy, że każdy ma prawo do korzystania z możliwości jakie daje internet.

Problem

Tworzenie stron intrnetowych, które są zgodne ze standardami jest podstawą. Dzięki temu treść jest dostępna w najszerszej gamie programów, urządzeń i środowiskach systemowych.

Standardy tworzenia stron proponują wiele specjalnych elementów i atrybutów kodu, które służą dostępności, poprzez jasno zdefiniowane relacje strukutralne, zapewnienie alternatywnej treści oraz nadają bogatsze znaczenie temu, co w normalnych warunkach byłoby jedynie niepoukładanym tekstem.

Od początku istnienia (1998), Web Standards Project (WaSP) prowadził kampanię na rzecz tworzenia stron zgodnie ze standardami. Widzieliśmy ogromny postęp świadomości tego, jakie korzyści płyną ze stosowania standardów zarówno wśród producentów przeglądarek jak i twórców stron internetowych oraz narzędzi do ich tworzenia. Jednak to wciąż za mało. Elementarne zasady równouprawnienia w internecie wciąż muszą być przypominane.

Technologie wspomagające (takie jak czytniki ekranu), których używają osoby z zaburzeniami wzroku konsekwentnie nie wykorzystują całego potencjału jaki tkwi w zgodnym ze standardami kodzie.

Przekombinowane i drogie narzędzia do zarządzania treścią generują niskiej jakości, niesemantyczny i niedostępny kod.

Narzędza redakcyjne (włączając w to systemy zarządzania treścią (CMS) i narzędzia do prowadzenia blogów) są trudne w obsłudze dla osób niepełnosprawnych, ponieważ nie są zgodne z Authoring Tool Accessibility Guidelines (ATAG) – rekomendacją w3c dla narzędzi redakcyjnych.

Korporacje i twórcy ich stron internetowych wciąż błędnie sądzą, że dostępna strona pozostaje w sprzeczności z jakością wizualną.

Ci, którzy znają się na tworzeniu dostępnych stron, często sprzedają drogie i błędne rozwiązania a to zjawisko nazywamy sprzedawaniem magicznej mikstury. Niektóre firmy utrzymują, że rozumieją dostępność dogłębnie i obiecują cudowną kurację za pomocą systemów, które automatycznie dokonają cudów, ale to co dostarczają, to nic innego jak zwyczajna dostępność.

Szybkie zyskanie popularności DOM scripting i AJAXa wprowadza kolejne problemy związane z ich funkcjonowaniem w technologiach wspomagających.

Accessibility Task Force uznaje, że właśnie teraz nadszedł moment, w którym należy się zająć tymi problemami. Chcemy wyróżnić codzienne problemy z jakim spotykają się graficy i programiści, które sprawiają, że wciąż produkowane są niedostępne treści i pracować na rzecz szybkiego usunięcia tych problemów. Chcemy także zmienić fokus z automatycznego badania dostępności na solidne uświadomienie sobie jakie problemy spotykają użytkownicy mający różne możliwości.

Propozycja

Niech wszystkie technologie wspomagające używane jako pomoc przy korzystaniu ze stron internetowych rozumieją w pełni zalecenia HTML, XHTML, DOM i CSS.
Niech wszyscy producenci technologii wspomagających przejrzyście dokumentują możliwości i działanie swoich produktów w kwestiach wsparcia standardów i skryptów.
Niech wszystkie Systemy Zarządzania Treścią, w podstawowej wersji, generują semantyczny, dostępny, walidujący się i czysty kod.
Niech wszyscy sprzedawcy CMSów doprowadzą do tego, aby osoby niepełnosprawne mogły łatwo korzystać z ich narzędzi do tworzenia treści internetowych.
Niech programiści tworzą strony zgodnie ze standardami oraz kiedy tylko możliwe testują je w technologiach wspomagających oraz z osobami niepełnosprawnymi aby uzyskać pewność, że ich strony są dostępne oraz użyteczne.
Niech społeczność pamięta, że Web Content Accessibility Guidelines (WCAG) to tylko część układanki, bowiem Authoring Tool Accessibility Guidelines (ATAG), User Agent Accessibility Guidelines (UAAG) i w gruncie rzeczy także Document Object Model (DOM) to także elementy standardów sieciowych.

Obietnica

Będziemy nieprzerwanie pracować w celu pokazania, że dostępność i dobrze pisany kod mogą iść łeb w łeb ze skuteczną interaktywnością, promocją marki oraz estetyką.
Będziemy więcej wymagać od narzędzi. Wszystkich. Będziemy działać w sprawie przeglądarek, odtwarzaczy mediów oraz technologii wspomagających aby te wspierały UAAG a w sprawie edytorów WYSIWYG, CMSów, narzędzi do blogowania, konwerterów oraz narzędzi do zarządzania mediami aby wspierały ATAG.
Będziemy bezstronnie próbować wciągnąć wszystkich producentów do konstruktywnego dialogu aby pomóc im wspierać standardy sieciowe aby w ten sposób zwiększyć dostępność.
Będziemy uczyć przedsiębiorstwa oraz ich twórców stron internetowych aby podejmowali rozsądne decyzje nie ulegając wpływowi sprzedawców magicznych mikstur.
Będziemy ściśle współpracować z innymi inicjatywami WaSP Task Force oraz odpowiednimi grupami roboczymi, takimi jak WCAG WG aby stworzyć wiarygodne wzorce i metodologie realizowania stron zgodnych ze standardami, interaktywnych i dostępnych, które działają właściwie dla użytkowników niepełnosprawnych.
Wreszcie jeśli dany sprzedawca będzie niechętnie współpracował i uparcie kontynuował działalność dyskryminującą, użyjemy wszelkich możliwych środków aby zmusić go do współpracy.

Oryginalny Manifest ATF (Accessibility Task Force) ukazał się na stronie The Webstandards Project.

URL: http://www.webstandards.org/action/atf/manifesto/.

Web Developer toolbar

Dominik Paszkiewicz — 2006-09-19T00:53:00Z

Przydatne ? Nie, niezbędne narzędzie webdevelopera. Jeśli wydaje Ci się, że tworzenie zgodnych ze standardami i dostępnych serwisów internetowych to ciężki kawałek chleba, ze względu na wielość aspektów, specyfikacji i narzędzi w tej dziedzinie, jesteś w błędzie.

Dzięki temu rozszerzeniu najlepszej przeglądarki internetowej ;) - Firefoxa, będziesz miał pod ręką wszystko czego potrzebujesz aby tworzyć strony całkowicie zgodne ze standardami i zaleceniami dostępności.

Pasek narzędzi Web developera dla Firefoxa

Ze strony MozillaPL.org możesz pobrać roszerzenie Web developer. W przeglądarce instalowany jest pasek narzędzi, który zawiera mnóstwo ciekawych i użytecznych narzędzi wspomagających pracę developera.

Za jego tego rozszerzenia będziesz mógł testować tworzoną przez Ciebie stronę na wiele sposobów. Wraz z paskiem narzędzi instaluje się kilkanaście skrótów klawiszowych (weszły mi w krew równie szybko jak Ctrl+S)

Najczęściej używam:

Ctrl+Shift+H: Poprawność kodu (strony on-line) z Jego Wysokością Validatorem
Ctrl+Shift+A: Poprawność kodu (strony off-line)
Ctrl+Shift+Y: Po przeniesieniu kursora nad jakikolwiek element strony w pasku statusu widzimy za pomocą jakich deklaracji jest sformatowany w CSS. Pomaga odnaleźć błędy gdy mamy kilometrowy plik CSS.

Poza tym, korzystam z paska narzędzi do wyłączania JS, obrazków i wielu innych funkcji.

Ach! Zapomniałbym. Mój ulubiony skrót Firefoxa wzbogaconego o Web Developer toolbar to wyłączanie CSS: Ctrl+Shift+S. Może to zakrawa na manię, ale kiedy wchodzę na większość stron, zanim cokolwiek przeczytam, używam powyższego skrótu, aby sprawdzić czy strona się ładnie zlinearyzuje czy brzydko rozchrzani na archaicznym szkielecie tabeli albo czy na stronie zastosowano h1...hn Cóż, taki bzik.

Siedem błędów dostępności (część pierwsza)

Christian Heilmann — 2006-09-10T06:40:29Z

Niedostępne strony są publikowane z wielu powodów. Jednym z nich jest ten, o którym mówiliśmy w moim ostatnim artykule: niektórych klientów dostępność nie obchodzi. Ich motywacje mogą nabrać więcej sensu jeśli wejdziesz w ich skórę. Innym powodem są błędy wykonawców stron. Popełnianie błędów to naturalna kolej rzeczy. Ponoszenie konsekwencji oraz uczenie się na błędach czyni nas lepszymi twórcami stron internetowych i lepszymi ludźmi.

Oto kilka podstawowych błędów z jakimi spotkałem się przez lata pracy jako zawodowy twórca stron internetowych. Jeśli będziemy mieli oczy szeroko otwarte w przyszłości, będzie bardziej prawdopodobne, że będziemy tworzyć piękne produkty bez większych kłopotów, czyniąc klientów i odwiedzających zadowolonymi.

Wielu twórców stron wierzy w mity dotyczące czytników ekranu. Przetestuj jakiś lub zapytaj osobę zależną od technologii wspomagających jak go używa i co tak naprawdę potrzebuje i chce.

Na końcu każdego opisu radzę jak uniknąć danego błędu. Kierowanie się tymi poradami może być utrudnione w zależności od dysponowanego budżetu lub wymagają bardziej dojrzałej relacji z klientem, ale pamiętanie o nich nie boli. Żadne działanie przy tworzeniu stron z myślą o użytkowniku końcowym, biorące jednocześnie pod uwagę pomysły klienta nie jest stratą czasu.

Siedem błędów dostępności 1-3

Błąd #1: Ocena

Wiele edytorów, środowisk programistycznych i systemów zarządzania treścią reklamuje się tym, że generują strony zgodne ze standardami i AAA. Zwykle polega to na tym, że edytory WYSIWYG zamykają tagi, używają nazw elementów pisanych małymi literami i wymuszają uzupełnianie atrybutu alt w obrazkach. Wszystko to jest fajne ale nie wystarczy.

Walidujący się HTML nie musi być wcale poprawny semantycznie i logiczny. Czy tak rzeczywiście jest potrafi stwierdzić tylko człowiek. Nie zrozum mnie źle. Jest sporo niezwykłych narzędzi w tej dziedzinie. Jednak są to tylko narzędzia. Maszyna nie jest w stanie przeniknąć złożoności procesów ludzkiej komunikacji. Maszyna nie może ocenić czy dany wynik/rezultat jest sensowny, niezależnie od tego jak skomplikowana byłaby to maszyna. W połowie drogi realizacji jakiegoś projektu możesz się obudzić i zrozumieć, że dany CMS ma jakąś poważną skazę, czego nie mogłeś zauważyć w jego demo – wypolerowanym na błysk (mam na myśli np. zgodność z UTF-8 dla stron wielojęzycznych).

Co to oznacza w praktyce ?

Oszczędza się wiele czasu samych twórców badających dany produkt (w przypadku IDE jest to inwestycja jednorazowa);
Dokument podsumowujący wady i sposoby ich naprawienia. Uczyń ten dokument obowiąkowym elementem projektu, który jest przekazywany w ręce tych, którzy będą dokonywać prac konserwacyjnych oraz nowym członków zespołu developerów;
Wprowadź testy z ludźmi w trakcie procesu. W ostateczności może to być wyszkolony redaktor jeśli nie ma czasu na pełny cykl testów.

Błąd #2: Hiperodpowiedzialność.

Spójrzmy prawdzie w oczy. Strona nie będzie zawsze zgodna z produktem początkowym, nie będzie zamkniętym tworem. Strony mają skłonność do naturalnego rozbudowywania się, co zresztą czyni je tym ciekawszymi. Jeśli nie chcesz być jedyną osobą odpowiedzialną za wszystkie zmiany (chyba, że masz zaufanego i bogatego klienta, którego stać na płacenie za twój czas) – musisz być pewien, że klient zna wszystkie wejścia i wyjścia twojego/swojego produktu.

Przedstawianie się klientowi jako superbohater dostępności, który nocą walczy ze zbrodnią niedostępności odziany w seksowne ubranko jest prostą drogą do niepowodzenia. Problem nie tkwi w tym, że klient Ci nie ufa – otóż będzie on szczęśliwy, jeśli pozbędzie się odpowiedzialności. Problem w tym, że będziesz zamieszany w wewnętrzne nieporozumienia przedsiębiorstwa i weźmiesz na siebie całą odpowiedzialność za jakość.

Typowy scenariusz: dział marketingu przygotowuje teksty, które są potencjalnie niedostepne ponieważ zawarte w nich są ilustracje (prawdopodobnie wycięte z innych kampanii reklamowych, innych mediów). Zarządzający projektem przesyła materiały do Ciebie. Wyjaśniasz problemy a on potwierdza, że właśnie takiej pomocy oczekuje dział marketingu. Wyjaśniasz ponownie, ale on zapomina o tym kiedy kontaktuje się z działem marketingu. Bawisz się w dziecinną zabawę w głuchy telefon i kończy się na tym, że spędzasz mnóstwo czasu na powtarzaniu oczywistości i w rezultacie projekt nie idzie od przodu.

Fakty

klient chce mieć produkt;
klient chce mieć zadowolonych klientów, czytelników, słuchaczy, odwiedzających;
jest bardzo prawdopodobne, że klient jest reformowalny, bowiem ma określone cele;

Logicznym rozwiązaniem jest wytrenować klienta najwcześniej jak to możliwe i pokazać mu dostępnościowe pułapki. Możesz też obiecać, że w granicach rozsądku będziesz wspierał klienta w trakcie prac konserwacyjnych, aktualizacyjnych.

Chronisz wówczas swój tyłek w przypadku jeśli zostaniesz pozwany do sądu. Twoją mantrą powinno być: “Pomagamy Ci zapewnić dostępność strony” nie “Zrobimy Ci dostępną stronę”. Co to oznacza w praktyce ?

Zaplanuj warsztaty i szkolenie z dostępności zanim zaczniesz prace nad stroną.
Znajdź prowadzącego wewnątrz firmy klienta, który weźmie odpowiedzialność za standardy dostepności. W każdej firmie jest ktoś, kto chce się wyróżnić a tutaj będzie miał okazję, zwłaszcza, że dostępność jest regulowana prawnie.
bPrzekaż klientowi odpowiednie materiały dotyczące dostęności i tego jak utrzymywać jej dobry poziom w trakcie zmian i rozbudowy stron.
Jasno i wyraźnie zapisz w umowie, że odpowiedzialność za dostępność treści po dostarczeniu produktu klientowi (czyli w dniu kiedy idziesz na drinka świętować zakończenie projektu) jest po jego stronie. Każde dodatkowe zamówienie powinno być oddzielnie płatne. Groźba dodatkowych kosztów powinna pomóc klientowi podjąć działania, które sprawią, że pracownicy będą poważniej traktować Twoje szkolenia. Używaj żargonu prawniczego – to potężna broń.
Upewnij się, że pracujez zgodnie z własnymi kazaniami. To co przekazujesz klientowi na początku, zarówno kod jak i treść powinno być nieskazitelne. Twoje błędy będą powielane, a trudniej jest wytłumaczyć klientowi, że popełniłeś błąd “ale teraz już będzie jak trzeba”.

Błąd #3: Bierz pod uwagę tylko najgorszy scenariusz

Może się zdarzyć, że webdeveloperzy, choć pełni dobrej woli wobec niepełnosprawnych stracą całościową perspektywę postrzegania projektu. A dostęność dotyczy każdego, niezależnie od zdolności czy geograficznego położenia. Dla wielu z nas, dostęp za pomocą klawiatury, rozpoznawanie głosu czy nawet użytkownicy czytników ekranu to coś z czym spotykamy się po raz pierwszy. Teraz zaczynasz mieć poczucie winy i chcesz gwałtownie znieść wszystkie przeszkody, które utrudniają użytkownikom czytników ekranu używanie strony.

Oto zdradzę Ci mały sekret: czytnik ekranu jest narzędziem, które działa wg zbioru zasad. Wielu webdeveloperów postrzega czytnik ekranu w oparciu o mityczne historyjki. Przetestuj jakiś lub zapytaj osobę, która jest zależna od technologii wspomagających jak go używa i czego potrzebuje najbardziej.

Nie ma takiej możliwości, żebyś przewidział każdy możliwy układ możliwości użytkownika, zestawu sprzętowego oraz wiedzy istniejącej po drugiej stronie ekranu i dokonując wyrównania statystycznego zrobisz dostępną, użyteczną i przyjemną w odbiorze stronę dla większości użytkowników. Może wciąż jeszcze sądzisz, że strony dostępne są przestarzałe i brzydkie.

Minimalne wymagania dostępnej strony to:

Poprawny semantycznie, logiczny i walidujący się HTML;
Treść, która ma sens jeśli jest czytana i słyszana;
Teksty alternatywne dla każdej treści wizualnej;
Nagłówki oraz linki, które mają sens poza kontekstem.

Te podstawy są fundamentem twojej strony. Jeśli do tej listy dorzucisz jakieś priorytety, które nie zmniejszają funkcjonalności i respektują powyższe punkty – wygrałeś.

Należy unikać:

słabego konstrastu grafiki i CSS;
kombinacji kolorów, które utrudniają rozróżnianie daltonistom;
mała czcionka, której wielkość nie może być zmieniana;
zachodzenie na siebie elementów przy zmianie wielkości czcionki.

Jeśli chcesz dodać jakieś sensowne skrypty JavaScript, np. udostępnić użytkownikowi funkcję przenieś-i-upuść albo rozwijane menu, to cudownie. Upewnij się jednak czy każdy użytkownik niezależnie od środowiska może korzystać z interfejsu. Możesz nawet zaproponować opcję wyłączania takiej funkcjonalności aby uprościć interfejs.

Co to oznacza w praktyce ?

Najpierw upewnij się, że Twój produkt realizuje ten zestaw zasad i pokaż klientowi jak dobrze strona funkcjonuje w każdego rodzaju środowiskach;
Postaraj się wprowadzić ideę postępującej jakości. Nie zaczynaj od spraw wizualnych ale od nieostylowanych szkieletów;
Używaj narzędzi, które pozwalają redaktorom edytować treści poza środowiskami wizualnymi. Możesz skorzystać z Worda albo prostego narzędzi publikacji takiego jak Wordpress;
Pokaż klientowi jak – zapewniając podstawy dostępności – sprawiasz, że można stronę przeglądać za pomocą telefonu komórkowego lub palmtopa;
Nie zapomnij o małym wykładzie na temat pisania treści przyjaznej wyszukiwarkom;
Nie zapominaj o mocy CSS oraz JavaScript jako narzędziu usability; Jako użytkownik z włączonym JS wolę się dowiedzieć, że coś źle wpisałem bez przeładowania strony.
Projektuj z ideą użyteczności w zanadrzu. Dobry design nie tylko jest ładny ale sprawia, że użytkownik łatwiej znajduje informacje istotne dla niego bez zbędnego myślenia.
Projektuj elastycznie. Strona powinna powiększać się zarówno jeśli chodzi o układ informacji jak i ekranowe punkty odniesienia. Unikaj wypełniania przestrzeni co do ostatniego okruszka. Pewnego dnia, strona zostanie rozbudowana o nowe elementy w menu albo przetłumaczona na język w którym słowa są dłuższe.

W następnym tygodniu pomówimy na temat czterech innych błędów dostępności, z którymi się spotkałem:

dzielenie problemów z odwiedzającymi;
próba rozwiązania problemów wykraczających poza strefę własnych doświadczeń;
ukrywanie lub zastępowanie rozszerzeń dostępności/użyteczności;
obsługa niewłaściwych klientów;

Tekst oryginalny ukazał się w magazynie Digital Web pod tytułem: Seven Accessibility Mistakes (Part 1). (Wkrótce druga część)

Wprowadzenie do dostępności stron internetowych

World Wide Web Consortium (w3c) — 2006-08-27T06:58:49Z

Dostępność stron internetowych oznacza, że osoby upośledzone mogą z nich korzystać. Precyzyjniej, dostępność oznacza takie projektowanie stron internetowych, aby osoby upośledzone mogły je poznać zmysłowo, zrozumieć, przemieszczać się po nich oraz skutecznie wchodzić w interakcje a także móc tworzyć i brać udział w tworzeniu treści internetu.

Są miliony osób upośledzonych. Upośledzenie wpływa na używanie przez nie internetu. W chwili obecnej dostęp do większości stron internetowych jest trudny lub niemożliwy dla wielu osób upośledzonych. Gdyby strony internetowe oraz oprogramowanie sieciowe było tworzone z uwzględnieniem dostępności, wiele osób upośledzonych mogłoby skuteczniej korzystać z internetu.

Dostępność stron internetowych dotyczy wszystkich upośledzeń, włączając w to upośledzenia wzroku, słuchu, fizyczne, mowy, poznawcze i neurologiczne. Aby dowiedzieć się więcej przeczytaj "How People with Disabilities Use the Web", dokument, który opisuje jak określone upośledzenia wpływają na używanie internetu oraz scenariusze korzystania z internetu przez osoby upośledzone.

Dostępność jest także korzystna dla osób nieupośledzonych. Kluczową zasadą dostępności jest między innymi elastyczne spełnianie potrzeb. Zyskują wszyscy, którzy używają internetu, włączając w to osoby bez upośledzeń, będące w różnych sytuacjach (takich jak wolne połączenie z internetem), ludzie z tymczasowymi upośledzeniami (złamana ręka), oraz osoby starsze. Aby dowiedzieć się więcej na ten temat zobacz "Developing a Web Accessibility Business Case for Your Organization".

Dlaczego dostępność sieci jest ważna

Internet odgrywa coraz większą rolę w edukacji, rekrutacji, handlu, sprawowaniu władzy oraz rozrywce. Dostępny internet, umożliwiający osobom upośledzonym aktywny udział w społeczeństwie jest podstawą wyrównywania szans w wielu dziedzinach życia.

Internet zapewnia niespotykany do tej pory dostęp do informacji oraz możliwość wchodzenia w interakcje dla ludzi z upośledzeniami. Aby uzyskać więcej informacji na ten temat przeczytaj: Web Accessibility is a Social Issue rozdział tekstu "Developing a Web Accessibility Business Case for Your Organization: Social Factors".

Dostępność internetu w wielu wypadkach jest także wymagana przez prawo. Zobacz listę ustaw prawnych i strategii z całego świata: "Policies Relating to Web Accessibility".

Czynienie stron internetowych dostępnymi

Dostępność jest uzależniona od wielu współgrających ze sobą składowych, między innymi odpowiedniego oprogramowania internetowego (narzędzia) oraz twórców stron internetowych (ludzie). Głównymi przyczynami tego, że strony internetowe nie są dostępne jest to, że narzędzia internetowe nie wspierają wystarczająco dostępności a twórcy stron internetowych są nieświadomi istnienia lub nie rozumieją podstawowych aspektów dostępności.

Aby pomóc rozjaśnić aspekty dostępności oraz zdefiniować rozwiązania, Web Accessibility Initiative (WAI) tworzy wytyczne, które są międzynarodowym standardem dostępności stron internetowych.

Tworzenie dostępnej strony internetowej

Wysiłek niezbędny do stworzenia dostępnej strony zależy od wielu czynników: od rodzaju treści, rozmiarów i złożoności strony internetowej oraz narzędzi i środowiska pracy.

Wiele elementów dostępności jest łatwe w zastosowaniu jeśli są planowane od początku rozwijanego projektu lub projektu przebudowy. Jednak, wzbogacenie istniejących stron może wymagać znacznego wysiłku, szczególnie jeśli nie są napisane zgodnie ze standardami znaczników XHTML a także w przypadku stron internetowych z niektórymi rodzajami treści, jak np. multimedialne.

"Implementation Plan for Web Accessibility" wypunktowuje podstawowe kroki, potrzebne do tego by uczynić stronę bardziej dostępną.

Ewaluacja dostępności

W trakcie tworzenia lub przebudowy strony internetowej wczesne oszacowanie dostępności może pomóc uwzględnić wszelkie jej aspekty oraz zapobiec problemom, co jest skuteczniejsze niż oszacowanie dostępności pod koniec realizacji projektu.

Aby sprawdzić czy strona spełnia niektóre zalecenia dostępności można zastosować proste techniki, takie jak zmiana ustawień w popularnej przeglądarce. Pełna ewaluacja zgodności z wszystkimi zaleceniami dostępności jest o wiele bardziej złożona.

Artykuł "Evaluating Web Sites for Accessibility" zawiera dział na temat wstępnej analizy oraz technik służących sprawnej ocenie niektórych aspektów dostępności w odniesieniu do strony oraz dział na temat oszacowania zgodności z ogólnymi procedurami oraz wskazówkami do ewaluacji zgodności z zaleceniami dostępności.

Istnieją automatyczne narzędzia, które pomagają dokonać ewaluacji, jednak żadne narzędzie nie wystarczy do tego aby uzyskać pewność czy strona jest zgodna z zaleceniami dostępności.

Więcej informacji

Stronga internetowa WAI zawiera zalecenia i szereg wskazówek, które pomogą zastosować zalecenia, m.in.: "Rady do tworzenia stron www z ułatwionym dostępem". Inne organizacje także publikują materiały pomagające tworzyć dostępne strony.

Notatki na temat terminologii

"Treści" internetowe zwykle odnoszą się do informacji znajdujących się na stronie internetowej albo w aplikacji sieciowej włączając w to tekst, obrazki, formularze, dźwięki i inne. Dokładniejsze definicje znajdują się w dokumentach WCAG, których linki można znaleźć w artykule Web Content Accessibility Guidelines (WCAG) Overview.

Oprogramowanie internetowe to:

przegądarki internetowe, odtwarzacze plików multimedialnych oraz inne programy (“user agents”); więcej informacji w User Agent Accessibility Guidelines (UAAG) Overview.
Narzędzia do tworzenia stron internetowych; więcej informacji w Authoring Tool Accessibility Guidelines (ATAG) Overview.
Narzędzia ewaluacji, które sprawdzają czy dana strona internetowa spełnia standardy i stosuje się do zaleceń; lista narzędzi ewaluacji: Evaluation, Rapair, and Transformation Tools for Web Content Accessibility.

Informacja o dokumencie

Wersja 1.1 (zostanie uaktualniona w kwietniu 2005) Mile widziane komentarze: wai-eo-editors@w3.org.

Redaktor: Shawn Lawton Henry. Stworzone przez Education and Outreach Working Group (EOWG).
Ostatnia aktualizacja pliku $Data: 2005/03/29 16:00:56 $ przez $Autor: shawn $

Copyright © 1994-2005 W3C ® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.

Nawyki przeglądania stron

Peter Krantz — 2006-08-27T06:56:02Z

Przed chwilą przeczyczytałem artykuł "Observing Users Who Listen to Web Sites". Autorzy tekstu wykazali, że użytkownicy z zaburzeniami wzroku zamiast czytać strony internetowe od góry do dołu skanują je. Być może nie jest to dla Ciebie zaskoczenie jeśli czytałeś artykuł Jakoba Nielsena "How Users Read on the Web" z 1997 roku. Ostatnio miałem możliwość pracować z kilkoma czytnikami ekranu i moje obserwacje są podobne.

Strony są skanowane, a nie czytane słowo po słowie

Dlaczego skanujemy zamiast czytać? Steve Krug, autor książki o użyteczności Don't Make Me Think mówi o pośpiechu użytkowników i o tym, czym użytkownicy zadowalają się kiedy przeglądają informacje. Oznacza to, że szukamy i wybieramy szybko pierwszą sensowną opcję, która nie zawsze jest najlepszą.

Jeśli zatrudniasz solidnego grafika, są szanse, że operuje typografią, kolorami tła i obrazków aby uczynić informacje łatwymi do odnalezienia dla widzących użytkowników. Używają oni bowiem układu strony aby zlokalizować najistotniejsze punkty i w ten sposób podejmują nieświadome decyzje o skierowniu swojej uwagi na określone elementy.

Jak skanujesz słuchem ?

Prawie wszystkie wczesne czytniki ekranu tworzyły linearną wersję strony internetowej. Wyobraź sobie, że musisz szybko przejrzeć kasetę wideo, ale twój magnetowid nie ma funkcji cofania i przewijania do przodu. Powoduje to, że nie masz możliwości jak tylko obejrzeć film od początku do końca. Szczęśliwie, współczesne czytniki ekranu posiadają funkcje, które mogą podzielić długą, linearną wersję na kilka sposobów wyświetlania, w oparciu o informacje poukładane za pomocą semantycznie zorganizowanych znaczników. Użytkownicy, których obserwowałem, kiedy skanują strony internetowe, używają przede wszystkim następujących funkcji czytnika ekranu (Jaws).

Lista tytułów. Kiedy Jaws ładuje stronę, przeprowadza analizę składniową uwzględniając wszystkie tytuły i wyświetla je jako listę.

Tytuły są przedstawiane w porządku tabulacji, wskazany jest też poziom tytułu (heading level). Słuchający tego użytkownik dowiaduje się czego strona dotyczy. Użytkownik może także ustawić tytuły alfabetycznie i przefiltrować wszystkie wg określonego poziomu. To jest pierwsza czynność wykonywana przez użytkowników jaką zaobserwowałem.

Lista odnośników. Podobnie jak lista tytułów, ta lista przedstawia wszystkie odnośniki w dokumencie.

Poprzez odsłuchiwanie list linków, użytkownik zdobywa inny jeszcz pogląd o tym czego dotyczy strona a szczególnie o tym gdzie może się udać nawigując.

Obie wymienione funkcje są używane wraz z linearnym przedstawieniem strony. Zatem typowy scenariusz mógłby wyglądać następująco:

Otwarcie strony. Wysluchanie tytułu strony z jej linearnego przedstawienia.
Otwarcie listy tytułów. Wysłuchanie tytułów poziomu pierwszego.
Zamknięcie listy tytułów. Przejście do pierwszego nagłówka. Wysłuchanie fragmentu tekstu.
Otwarcie listy odnośników oraz wysłuchanie części elementów.
Powrót do linearnego przedstawienia.
Otwarcie listy tytułu, wysłuchanie większej ilości tytułu strony.
.. itd.

Zaawansowani użytkownicy przyspieszają głos aby skanować stronę szybciej.

Konsekwencje dla programisty html

Zapewne widzisz jakie są tytuły. Wyobraź sobie jednak, że strona internetowa nie miałaby znaczników tytułów. W takim przypadku lista nagłówków będzie pusta i użytkownik musi się zdać na linearne przedstawienie strony. Podobnie jest z odnośników. Jeśli tekst odnośnika jest słabo napisany, trudne jest wydobyć jakiekolwiek informacje z listy ondnośników. "Ale - powiesz używam przecież atrybut 'title' aby przedstawić we właściwy sposób tekst odnośnika". Niestety Jaws z domyślnymi ustawieniami nie bierze pod uwagę atrybutu "title". Podobnie jak w przypadku tradycyjnych przeglądarek, wielu użytkowników nie wie jak zmienić te ustawienia.

Oto kilka sugestii jak ułatwić czynność przeglądania stron przez użytkowników z zaburzeniami wzroku:

używaj do licha tytułów!
używaj poziomów tytułów aby wskazać hierachię jeśli taka istnieje. Nie przeskakuj z h1 do h3. W innym przypadku lista tytułów może być myląca.
uważaj aby tekst odnośników miał określone znaczenie. Niekiedy wystarczy rozszerzyć zasięg odnośnika do kilku słów więcej. Zamiast tworzyć odnośnik "książka" w zdaniu "nowa książka Douglasa Adamsa" możesz stworzyć odnośnik "książka Douglasa Adamsa" aby powstał odpowiedni kontekst. Nie przesadź...
Używaj raczej atrybutu alt dla obrazka niż atrybutu title dla odnośnika, jeśli używasz odnośników obrazkowych. To sprawi, że tekst odnośnika będzie czytelny dla użytkowników Jawsa, którzy nie zmienili ustawień programu, aby ten odczytywał atrybut title. Jeśli nie używasz ani atrybutu alt ani title, Jaws przeczyta(nic nie mówiącą) nazwę pliku obrazka. Pomyśl tylko: "slash www slash img slash p underscore small".
Pisz z myślą o internecie.

Jak sprawdzić stronę za pomocą Fangsa

Oczywiście najlepszym rozwiązaniem jest zdobycie Jawsa i posłuchanie jak strona brzmi. Ale to zabiera sporo czasu. Jeśli nie zainstalowałeś jeszcze Fangsa, emulatora czytnika ekranu, sugeruję Ci abyś zrobił to zaraz. Versja 0.80 posiada w podstawowe funkcje pokazywania listy odnośników i listy tytułów. Czy Twoja strona działa? Wiem, wiem, muszę jeszcze nad tym popracować.

Referencje

Don't Make Me Think, Steven Krug
Observing Users Who Listen to Web Sites, Janice (Ginny) Redish i Mary Frances Theofanos.
How Users Read on the Web, Jakob Nielsen

Autorem artykułu jest Peter Krantz, twórca rozszerzenia do Firefoxa - Fangs i właściciel strony Standards Schmandards.

Oryginalny artykuł w jęz. angielskim.

Tekstowa wersja strony

Dominik Paszkiewicz — 2006-08-27T06:53:37Z

Pojęcie tekstowej wersji strony fukncjonuje do dziś wśród twórców stron internetowych oraz ich klientów. Wydawałoby się, że takie podejście jest bardzo poprawne (zwłaszcza politycznie), jednak postaram się wykazać, że tak nie jest.

Tekstowa wersja strony w zamierzeniu ma być przeznaczona dla osób, które z takich czy innych przyczyn nie mają dostępu do pełnej informacji zamieszczonej we właściwym serwisie.

Największą ironią może być (i jest często) fakt, że wersja tekstowa strony nie musi być wcale dostępna per se. Tekstowe wersje strony zawierają nierzadko elementy źle zaprojektowane pod względem dostępności. Mogą to być słabo dostępne formularze lub linki w rodzaju: "kliknij tutaj" albo "więcej". Spotyka się także tekstowe wersje stron, które korzystają z tabel do rozplanowania zawartości, a nie danych tabularycznych. Zatem, tekstowa wersja strony nie jest automatycznie wersją dostępną.

Weźmy pierwszy z brzegu, aczkolwiek zupełnie sensowny w tym kontekście przykład. Serwis internetowy Państwowego Funduszu Rehabilitacji Osób Niepełnosprawnych. Strona główna serwisu charakteryzuje m.in. się:

brakiem deklaracji DOCTYPE
jest niezgodna z aż 6 punktami kontrolnymi (eng. checkpoint) WAI (w mojej karierze kodera html nie udało mi się osiągnąć tak wysokiego wyniku dla żadnej ze stron mimo najszczerszego zapału ...)
zawiera magiczną formułkę: "Rekomendowana przeglądarka: MS IE 5.0+"
przy wyłączonym Java Script nie jest możliwe przejście do dalszej części serwisu, ani do jej wersji graficznej ani tekstowej!

Dobrze, przyznaję, zagalopowałem się, nie czas i miejsce na szczegółową analizę dostępności serwisu internetowego PFRON. Wróćmy do wersji tekstowych. Po wejściu na stronę główną serwisu, widzimy/słyszymy/czujemy możliwość skorzystania z dwóch wersji: graficznej i tekstowej. Wersja tekstowa, której a priori nie powinno nic brakować w aspekcie dostępności niemiło mnie zaskakuje. Brak deklaracji DOCTYPE, 24 błędy w kodzie, nie posiada zdefiniowanego języka. Nie brnijmy w to dalej. Widać zatem na takim przykładzie, że tekstowa wersja strony nie jest wystarczającym rozwiązaniem na zapewnienie dostępności informacji publikowanych w serwisie.

Można ale po co ?

Tekstowa wersja strony, która wielu wydaje się jedynym lub wystarczającym remedium na dostępność informacji serwisu internetowego jest wg mnie zbędna w większości przypadków. W przypadku strony internetowej zbudowanej w oparciu o statyczne bądź generowane dokumenty xhtml, wystarczy nieco wysiłku w trakcie procesu realizacji aby uczynić serwis dostępnym. Nie ma wówczas konieczności tworzenia specjalnych wersji tekstowych. Jest jednak sytuacja, która wg mnie całkowicie uzasadnia stosowanie wersji tekstowej (ja bym ją raczej nazwał wersją xhtml). W przypadku gdy cały serwis i wszystkie zawarte w nim informacje opublikowane są z wykorzystaniem technologii flash, wówczas niezależna tekstowa wersja strony jest uzasadniona.

Dlaczego wersji tekstowej mówimy nie

zawierają często mniej informacji niż ich właściwe wersje
wbrew pozorom nie musi być bardziej dostępna
jest to marnotrastwo inwestowanych pieniędzy, które mogłby być zamiast tego spożytkowane na pracę nad dostępnością właściwego serwisu. To naprawde nie jest trudne.
aby przejść do tekstowej wersji strony często trzeba przebić się przez Bardzo Niedostępną Wersję (cytowany wyżej przykład PFRON-u).
tworzenie tekstowej wersji strony stanowi potencjalną przystań dla leniwych webmasterów. Tworzą oni tekstową wersję strony, po to aby nie pracować dostępnością właściwego serwisu

Posłuchajmy specjalistów

11.4 Jeśli, mimo największych wysiłków nie udało ci się stworzyć dostępnej strony, zaproponuj llink do alternatywnej wersji strony, która respektuje technologie W3C, jest dostępna, zawiera te same informacje (lub funkcje) oraz jest uaktualniana równie często co jej niedostępna (oryginalna) wersja. [Priority 1] (Checkpoint 11.4).

Użycie sformułowania: mimo największych wysiłków, mówi samo za siebie. Aby stworzyć porządną tekstową wersję strony trzeba się napracować. Dlaczego tego czasu nie przeznaczyć na stworzenie jednego, dostępnego serwisu?

Śmiem twierdzić, że serwis spełniający wszystkie zalecenia WAI jest idee fixe. Jednak z pewnością nie da się zastąpić dostępności właściwego serwisu jego tekstową wersją. Jak pisze Mike Pilgrim w swoim artykule na temat tekstowych wersji (One page to rule them all), dostępność - podobnie do bezpieczeństwa sieciowego - jest procesem. Najistotniejsze jest aby projektować i publikować w sieci pamiętając o dostępności.

Wysoka dostępność oznacza skuteczną optymalizację dla wyszukiwarek.

Andy Hagans — 2006-08-27T06:49:21Z

Wielu twórców stron internetowych postrzega optymalizację dla wszyszukiwarek (SEO) jako "świństwo" i mają słuszne powody. Specjaliści od optymalizacji często zaśmiecają wyniki wyszukiwania spamem, czyniąc trudniejszym odnalezienie istotnych informacji. Jednak w rzeczywistości istnieje więcej niż jeden sposób optymalizacji. Z jednej strony czarne SEO posiłkuje się wszelkimi dostępnymi środkami aby uzyskać wysoką pozycję w wyszukiwarkach, podczas gdy białe SEO tworzy przyjazny wyszukiwarkom kod stron internetowych.

W artykule Using XHTML/CSS for an Effective SEO Camaign Brandon Olejniczak wyjaśnia, że wiele dobrych praktyk tworzenia stron internetowych pokrywa się z białym SEO. Powód jest prosty. Praktyki takie jak oddzielanie formy od treści, rozdądne stosowanie JavaScript i redukcja kodu pozwalają wyszukiwarkom lepiej przeszukiwać, indeksować i zmieniać pozycję stron internetowych.

Po dwóch latach od opublikowania tekstu, zamierzam popchnąć konkluzje Brandona krok dalej. Byłem specjalistą od optymalizacji przez wiele lat i ostatnio zakochałem się w problematyce dostępności stron. Po tygodniach lektury i drobiazgowych modyfikacji mojej własnej strony aby stała się zgodna z większością zaleceń W3C dotyczących dostępności treści, doszedłem do zadziwiających wniosków: wysoka dostępność strony jest równoznaczna z większością działań białego SEO.

Dostępność dla wszystkich użytkowników, nawet dla wyszukiwarek

Kolejny wniosek jest taki, że to pokrywanie się zakresów naprawdę ma sens. Celem dostępności jest uczynienie treści internetu dostępnymi dla tak wielu ludzi jak to możliwe włączając w to osoby, dla które mają techniczne, fizyczne lub inne utrudnienia. Myślenie o wyszukiwarkach jako użytkownikach ze znacznymi utrudnieniami w dostępie do treści może być przydatne: nie mogą czytać tekstu w obrazkach, nie mogą korzystać z JavaScript ani apletów, nie mogą także "widzieć" wielu innych rodzajów mediów. Dostępność ma za zadanie rozwiązywać na pierwszym miejscu tego rodzaju problemy.

Przegląd kilku punktów kontrolnych

Teraz, kiedy omówiłem już to dlaczego wysoka dostępność pokrywa się ze skuteczną optymalizacją, pokażę jak to się robi. W tym celu zajmę się każdym punktem kontrolnym Priorytetu nr 1 z W3C Web Content Accessibility Guidelines, które wpływają na optymalizację dla wyszukiwarek.

1.1 Zapewnij ekwiwalent tekstowy dla każdego nietekstowego elementu )np. używając "alt", "longdesc", lub za pomocą elementu treściowego)...

Wyszukiwarki nie tylko nie są w stanie zrozumieć obrazka albo pliku wideo, ale także nie potrafią zinterpretować żadnej tekstowej zawartości, która bazuje na postrzeganiu wzrokowym (takich jak ASCII art). Dlatego atrybuty alt i longdesc pomogą im zrozumieć sens każdego z elementów treści.

Wyszukiwarki są także "głuche" względem plików dźwiękowych. I tu także, zapewnienie tekstowego opisu takiego pliku pozwala wyszukiwarkom lepiej zinterpretować i upozycjonować zawartość, której nie mogą "słyszeć".

1.2 Zapewnij zastępcze linki tekstowe dla każdego aktywnego pola mapy obrazkowej.

Linki tekstowe są bardzo ważne dla wyszukiwarek, zwłaszcza jeśli zwięźle kwalifikują zawartość strony, do której link prowadzi. Rzeczywiście, wiele specjalistów od optymalizacji uznają link za jeden z najważniejszych czynników dla współczesnych algorytmów wyszukiwawczych. Jeśli strona zawiera mapę obrazkową zamiast tekstowego menu jako podstawową metodę nawigacji, powtórzone menu tekstowe w innym miejscu strony dostarczy wyszukiwarce dodatkową informację na temat zawartości każdej ze zlinkowanych stron.

4.1 Wyraźnie odznacz zmiany naturalnego języka w tekście dokumentu i tekstowych ekwiwalentach (np. captions).

Główne wyszukiwarki wspierają indeksowanie dla odpowiednich krajów i języków. Precyzując język dokumentu (lub tekstu wewnątrz dokumentu) pomaga się wyszukiwarce zdecydować w jakim miejscu zaindeksować dokument.

6.3 Upewnij się, że strony są zdatne do użytku nawet jeśli skrypty, aplety oraz inne obiekty programistyczne są wyłączone [...]

Niektórzy użytkownicy wyłączają JavaScript i aplety w ustawieniach przeglądarki, a przeglądarki niektórych użytkowników wcale z tych technologii korzystają. Podobnie "przeglądarki" wyszukiwarek - nie czytają takich skryptów. Użyteczność stron nie powinna być gorsza ze względu na wyłączone skrypty. Może to spowodować, że wyszukiwarka nie będzie mogła takiej strony zaindeksować.

Używaj najbardziej zrozumiałego i najprostszego języka adekwatnego do zawartości strony.

Trochę mniej oczywiste jest jak poszczególne punkty kontrolne wpływają na SEO. Jednak jeśli serwis używa "najbardziej zrozumiałego i najprostszego języka adekwatnego do zawartości strony" jest prawdopodobne, że zawiera te słowa kluczowe, których będą używać szukający. Szukający skłaniają się ku używaniu zwięzłych wyrażeń zawierających elementy języka potocznego. Zatem, aby uzyskać jak największy ruch na stronie dzięki wysokiej pozycji w wyszukiwarkach, najlepiej aby strona internetowa zwierała te same słowa, których będą używać szukający.

Korzyści nie kończą się na Priorytecie 1, wiele elementów punktów kontrolnych Priorytetu 2 i 3 jest równie istotnych z punktu widzenia SEO. Na przykład, punkty kontrolne 6.2 i 6.5 odnoszą się do dostępności treści dynamicznych. Rzeczywiście, uczynienie dynamicznych treści przyjaznymi wyszukiwarkom jest jednym z najbardziej beznadziejnych zadań jakie spotyka w swojej drodze ekspert od pozycjonowania w swojej pracy ze sklepami internetowymi i serwisami opartymi na bazach danych. Jednak podążanie za wskazówkami W3C pomaga uniknąć problemów z indeksowaniem i rankingiem związanych z dynamiczną treścią.

Porady nie do zlekceważenia

Jeśli wątpisz w jakieś z powyższych twierdzeń możesz odwiedzić Google's Webmaster Guidelines i przekonasz się, że Google nagradza wysoką dostępność. Na tej stronie znajdziesz wyszczególnienie dobrych praktyk, które pomagają Google "odnaleźć, zaindeksować, i upozycjonować twój serwis".

Wskazówki dotyczące formy i treści

Twórz stronę z czytelną hierarchią i linkami tekstowymi. Do każdej strony powinien prowadzić co najmniej jeden statyczny link tekstowy.
Zaproponuj użytkownikom mapę strony prowadzącą do najistotniejszych części Twojego serwisu. Jeśli mapa strony zawiera 100 i więcej linków, dobrze jest ją rozbić na kilka podstron.
Twórz stronę użyteczną, pełną informacji. Pisz strony w taki sposób, który w sposób przejrzysty przedstawiaja treść.
Pamiętaj o słowach, które użytkownicy mogą wpisywać aby odnaleźć Twoje strony, i bądź pewien, że Twoja strona zawiera te słowa.
Staraj się używać tekst zamiast obrazków do wyświetlania ważnych nazw, treści czy linków. Google nie rozpoznaje tekstu w obrazkach.
Upewnij się czy tytuł i tagi alt opisują w sposób adekwatny.

Wskazówki techniczne

Używaj tekstowej przeglądarki takiej jak Lynx aby zbadać swoją stronę, pownieważ większość wyszukiwarek widzi stronę podobnie do Lynxa. Jeśli bajeranckie usprawnienia takie jak JavaScript, cookies, sesje ID, ramki, DHTML lub Flash nie pozwalają zobaczyć zawartości strony w przeglądarce tekstowej, wówczas podobne problemy z Twoją stroną mogą mieć wyszukiwarki.

Zauważ, że każda ze wskazówek Google tak naprawdę zbiega się z zaleceniami W3C dotyczącymi dostępności treści stron internetowych. (Dziwna sprawa, że słowo dostępność nie pojawia się w Google's Webmaster Guidelines. Być może martwią się o to aby nie przerazić niektórych webmasterów zbyt technicznym żargonem ? Jedno jest pewne, że Google lobbuje na rzecz wysokiej dostępności.)

SEO: czubek góry lodowej w dostępności

Punkty kontrolne, które wyróżniłem powyżej to jedynie kilka spośród wielu sposobów, które pomagają uzyskać wysoką dostępność strony i zoptymalizować ją na potrzeby wyszukiwarek. Wiele innych punktów kontrolnych W3C Web Content Accessibility Guidelines wspomaga SEO równie dobrze. Oczywiście, dla większości twórców stron internetowych podstawowym celem dostępności jest (i powinno być) oczynienie stron dostępnymi dla wszystkich ludzi, niezależnie od platformy sprzętowej oraz upośledzeń, które mają. A jeśli dodatkowo dostępność sprawia, że strona ma więcej odwiedzin z Google, tym lepiej!

Dobrą nowiną jest to, że twórca stron internetowych, który tworzy strony z myślą o dostępności praktykuje także solidne białe SEO. Nie ma co się obawiać wyszukiwarek. W razie jakichkolwiek wątpliwości, twórz stronę tak aby była dostępna dla niewidomych i niesłyszących użytkowników oraz dla tych, którzy oglądają stronę za pomocą przeglądarki tekstowej a SEO przyjdzie samo.

O autorze

Andy Hagans jest założycielem Andy Hagans Link Building firmy konsultingowej SEO. When he isn't building links for clients, you can find him working on his pet projects: Mobile Search Marketing and the Uganda Conflict Action Network.

Napisał: Andy Hagans
URL: http://alistapart.com/articles/accessibilityseo
Data tłum: 2005-12-17 08:06:53