Niedziela 10 września 2006 | Napisał: Christian Heilmann
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.
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 ?
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
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 ?
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:
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ć:
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 ?
W następnym tygodniu pomówimy na temat czterech innych błędów dostępności, z którymi się spotkałem:
Tekst oryginalny ukazał się w magazynie Digital Web pod tytułem: Seven Accessibility Mistakes (Part 1). (Wkrótce druga część)
Teksty własne lub tłumaczenia z angielskiego, francuskiego i niemieckiego.