Web Accessibility

Uwaga: wprawdzie brakuje dwóch a może trzech rozdziałów, ale nawet w takiej formie ten dokument może się przydać. Znajduje się tu objaśnienie zagadnień dostępności i zaleceń WAI.

Web Accessibility

następny rozdział: WAI (Web Accessibility Initiative)  do spisu treści strony 

Definicja

Dostępność w projektowaniu stron internetowych oznacza tworzenie takich dokumentów, które są czytelne i funkcjonalne dla wszystkich użytkowników niezależnie od ich fizycznych ograniczeń, sytuacji w jakiej się znajdują, a także używanego oprogramowania oraz sprzętu.
Podobnie jak w przypadku usuwania architektonicznych barier dostępu jest to działanie na rzecz sytuacji, w której nie ma żadnych "użytkowników drugiej kategorii". Dostępność jest miarą łatwości w uzyskaniu dostępu, odczytaniu i zrozumieniu zawartości stron WWW.

Korzyści z WA

Praktyczną korzyścią z tworzenia stron spełniających wymogi dostępności jest spełnienie podstawowej funkcji internetu - możliwie powszechnego dostępu do informacji. Różnorodność sposobów w jaki internauta może skorzystać z zawartości jest wadą tylko jeśli patrzeć z punktu widzenia nawyków przejętych z DTP. Ale WWW to nie jest "DTP w internecie", ale potężne medium przerastające możliwościami wszystko co do tej pory znaliśmy. Ta różnorodność jest zaletą, pod warunkiem, że patrzymy na zagadnienie przez pryzmat raczej możliwości niż ograniczeń. Elastyczne projektowanie nie naśladujące ścisłością DTP umożliwia tworzenie stron zawsze czytelnych, wyglądających co prawda inaczej w różnych przeglądarkach, ale jednakowo funkcjonalnych dla odbiorcy.

Jest to logiczna konsekwencja dość oczywistego poglądu, że ważniejsza jest treść od wyglądu i niezależnie od ograniczeń oprogramowania i sprzętu użytkownika należy zapewnić czytelność i funkcjonalność strony.
Pożytki z dostosowania się do tego standardu są ogromne, chodzi w gruncie rzeczy o likwidacje barier architektonicznych w cyberprzestrzeni. W USA i Wielkiej Brytani wymóg dostosowania witryn rządowych do WAI "A" wynikają z prawa przeciwdyskryminacyjnego i są częścią polityki równego dostępu do usług.
Już niedługo może to być ważne także dla stron komercyjnych, słynny był swego czasu proces wytoczony przez niewidomego organizatorom olimpiady w Sydney z powodu oficjalnej strony, z której nie mógł skorzystać. Sklep, bank, czy usługodawca może mieć takie same kłopoty z powodu niezgodnej z WAI "A" strony internetowej jak z powodu braku podjazdu dla wózka.
Ostatecznie na tym standardzie korzystamy wszyscy - nie jesteśmy zmuszani do używania konkretnej przeglądarki, zawartość jest przejrzysta, poprawnie zorganizowana, czytelna, a kod zgodny normami W3C.

Inicjatywy zwiazane z WA

WAI (Web Accessibility Initiative)

poprzedni rozdział: Web Accessibility - co to jest?  następny rozdział: Quick Tips  do spisu treści strony

Czym jest WAI?

Priorytetem W3C - organizacji tworzącej standardy internetowe - jest uczynienie internetu uniwersalnym środowiskiem wymiany informacji. Istotną częścią tej działalności jest WAI, projekt którego celem jest promocja dostępności (głównie w kontekście dostępu do zawartości WWW dla osób niepełnosprawnych). Jednym ze środków do osiągnięcia tego celu jest tworzenie specyfikacji technicznych takich jak WCAG, które umożliwiają kodyfikację praktyk i ustawodawstwa przeciwdyskryminacyjnego.

Web Content Accessibility Guidelines 1.0 (Wytyczne dotyczące dostępności treści internetowych 1.0) jest to specyfikacja techniczna określająca kryteria wykonania dostępnych stron WWW, wytyczne umożliwiające zestandaryzowanie procesu tworzenia i walidacji stron internetowych.
W maju 1999 WCAG 1.0 stala się oficjalną Rekomendacją W3C. Obecnie WCAG 2.0 jest na etapie Working Draft
Zgodność z WCAG 1.0 na poziomie A jest w Uni Europejskiej obowiązkowym wymogiem dla stron administracji rządowej i samorządowej.

Jest to standard pomyślany dla osób niepełnosprawnych: niedowidzących, niewidomych, z ograniczoną funkcją ruchu. Niejako po drodze zapewnia także inne udogodnienia, także dla deweloperów, właścicieli stron i firm, które go wdrożą.
Co najważniejsze uniezależnia dostęp do treści od rodzaju platformy sprzętowej i programowej użytkownika. Strona zgodna z przynajmniej pierwszym stopniem WAI będzie czytelna i funkcjonalna w czytniku Braila, monochromatycznym terminalu bez myszki, PDA, Macu z 21 calowym monitorem i Safari a także zawyczajnym PC, niezależnie od przeglądarki.

Specyfikacja Web Content Accessibility Guidelines 1.0 określa z jakiego rodzaju utrudnieniami dostępu należy się liczyć:

Jak widać dotyczy wielu rodzajów utrudnień dostępu, wynikających zarówno z sytuacji i predyspozycji użytkownika jak i sprzętu i oprogramowania. Specyfikacja określa szereg wymogów, począwszy od poprawności kodu i niezależnienia czytelności od rodzaju przeglądarki, aż po trudne do weryfikacji kryteria jak np. czytelność layoutu czy prostota języka.
Jednym z najlepszych przykładów możliwej sytuacji, do której należy się dostosować jest wyłączenie przez użytkownika ilustracji (np. ze względu na słabe łącze). W3C nie zaleca pozbycia się ilustracji, ale dostarczenie tekstowego odpowiednika (w atrybucie alt) - stosownego do funkcji ilustracji. Oznacza to, że opis w atrybucie alt musi być zależny od tego czy obrazek pełni funkcje wyłącznie ozdobną, czy też ilustracyjną lub nawigacyjną. Koniecznie należy dostarczyć tekstowe zamienniki dla wszystkich multimedialnych elementów.

Zalecenia

Przestrzegając zasad WAI webmasterzy mogą zachować czytelność i funkcjonalność witryny w każdej sytuacji. Istnieje kilka podstawowych zaleceń:

WAI Quick Tips

poprzedni rozdział: WAI (Web Accessibility Initiative)  następny rozdział: Trzy stopnie zgodności  do spisu treści strony

Praktycznym przybliżeniem zasad WAI może być WAI Quick Tips:

Trzy stopnie zgodności

poprzedni rozdział: Quick Tips  następny rozdział: Zalecenia  do spisu treści strony

Specyfikacja Web Content Accessibility Guidelines 1.0 zgodność definiuje trójstopniowo:

Stopnie ważności zaleceń

Określony jest dla każdego elementu specyfikacji

Stopnie zgodności dokumentu

Dzięki temu podziałowi W3C utworzyło trzy stopnie zgodności WAI:

Zalecenia WAI

poprzedni rozdział: Trzy stopnie zgodności  następny rozdział: Metody  do spisu treści strony

Poniższe zestawienie jest skrótem i może służyć tylko jako przybliżenie treści kompletnej specyfikacji.

Konwencja

Lista zaleceń

pierwsze zalecenie: 1 - Udostępnij właściwe odpowiedniki dla zawartości dźwiękowej i wizualnej  do spisu treści strony

1. Zapewnij właściwe odpowiedniki dla zawartości dźwiękowej i wizualnej

następne zalecenie: 2 - Nie przekazuj informacji samym tylko kolorem  do spisu treści rozdziału  do spisu treści strony

Zapewnij odpowiednik zawartości dźwiękowej i wizualnej, taki, żeby pełnił identyczną funkcję.

Chociaż nie wszyscy mogą w pełni korzystać z obrazów, dźwięków, apletów to nadal mogą używać stron zawierających informacje będące odpowiednikiem dla zawartości wizualnej lub dźwiękowej. Ten odpowiednik musi służyć tym samym celom. Tak więc tekstowy odpowiednik obrazu strzałki skierowanej do góry prowadzącej do spisu treści powinien brzmieć "do spisu treści". W niektórych wypadkach powinien także opisywać wygląd elementów graficznych (np. złożone wykresy, tablice lub diagramy) lub dźwięk elementów audio (np. próbki dźwiękowe używane w edukacji).

Zalecenia W3C szczególnie podkreślają rolę tekstowego odpowiednika dla nie-tekstowej zawartości (obrazy, ścieżka dźwiękowa, wideo). Jego znaczenie wynika z możliwości odtworzenia na wiele sposobów, z których mogą skorzystać praktycznie rzecz biorąc wszystkie grupy użytkowników przy użyciu rozmaitych technik. Tekst jest najbardziej uniwersalnym nośnikiem treści - może być w czytelny sposób przetworzony przez syntetyzer mowy, czytnik braila i może być przedstawiony wizualnie (w wielu rozmiarach) w wyświetlaczach komputerowych i na papierze. Dla olbrzymiej ilości ludzi tekst jest jedyną dostępną formą zawartości WWW. Dla zdecydowanej większości użytkowników internetu jest najwygodniejszy.
Syntetyzowana mowa ma krytyczne znaczenie dla ludzi niewidomych lub mających problemy z czytaniem. Braille jest niezbędny dla niewidomych.

Z kolei zapewnienie nie-tekstowych odpowiedników (np. obrazy, wideo, ścieżki audio) tekstu jest również pożyteczne dla wielu użytkowników, dla których problemem jest czytanie. Przy wizualnych prezentacjach należy zadbać by wyjaśnienia zawarte w dźwięku były jak najpełniejsze i jeśli to możliwe samodzielne.

2. Nie przekazuj informacji samym tylko kolorem

poprzednie zalecenie: 1 - Udostępnij właściwe odpowiedniki dla zawartości dźwiękowej i wizualnej  następne zalecenie: 3 - We właściwy sposób używaj znaczników i CSS  do spisu treści rozdziału  do spisu treści strony

Upewnij się, że tekst i ilustracje są zrozumiałe także kiedy są widziane bez użycia koloru

Jeśli jakaś informacja jest przekazywana wyłącznie przy pomocy koloru, nie dotrze ona do ludzi nie potrafiących go rozróżnić z powodu wady wzroku lub konstrukcji wyświetlacza. Nawet jeśli będzie widoczna to różnica w pewnego rodzaju wyświetlaczach może być zbyt mała, lub niewidoczna dla ludzi z zaburzeniami wzroku.

3. Używaj znaczników i arkuszy stylów i to we właściwy sposób

poprzednie zalecenie: 2 - Nie przekazuj informacji samym tylko kolorem  następne zalecenie: 4 - Określ użycie języków naturalnych  do spisu treści rozdziału  do spisu treści strony

Utwórz dokument przy pomocy właściwych elementów strukturalnych. Wygląd określ raczej używając arkuszy stylów niż elementów i atrybutów prezentacji.

Użycie znaczników w niewłaściwy sposób - niezgodnie ze specyfikacją - jest wbrew wymogom dostępności. Nadużywanie znaczników strukturalnych dla określenia wyglądu utrudnia wielu użytkownikom zrozumienie struktury strony oraz nawigację. Ponadto użycie znaczników prezentacji - zamiast strukturalnych - do utworzenia struktury utrudnia własciwe wyświetlenie w niektórych urządzeniach.
Istotne jest tu wyjaśnione w dokumentacji W3C rozróżnienie pomędzy zawartością, strukturą, i prezentacją.
Najczęstszym przykładem takiego postępowania jest tworzenie layoutu strony tabelą, która jest przeznaczona do prezentacji danych tabelarycznych, i na odwrót nie powinno się tworzyć tabel danych znacznikiem PRE. Błędem jest również zastosowania nagłówka do zmiany wielkości fontu.
Wprawdzie można w ten sposób zapewnić właściwy wygląd strony w starszych przeglądarkach, ale efektem takich metod są znaczne utrudnienia dostępu. Należy sobie w takim wypadku zadać pytanie czy jest to tego warte.

Z drugiej jednak strony nie powinno się rezygnować z właściwego użycia znaczników tylko dlatego, że niektóre programy nie wyświetlają ich właściwie. Np. właściwym użyciem znacznika TABLE jest prezentacja danych tabelarycznych. Nawet jeśli część przeglądarek nie jest w stanie ich prawidłowo pokazać, można w taki sposób utworzyć tabelę, że zawsze będzie czytelna.

4. Zadeklaruj użycie języków naturalnych

poprzednie zalecenie: 3 - We właściwy sposób używaj znaczników i CSS  następne zalecenie: 5 - Twórz tylko proste tabele  do spisu treści rozdziału  do spisu treści strony

Używaj znaczników, które ułatwiają wymowę lub interpretację skrótów lub obcojęzycznego tekstu.

Kiedy użyje się znaczników dla określenia zmian języka naturalnego w dokumencie syntetyzery mowy i wyświetlacze brailla mogą automatycznie przełączyć się na nowy język. W ten sposób dokument jest bardziej czytelny dla wielojęzycznych użytkowników. Należy zadeklarować główny język naturalny treści dokumentu (poprzez znaczniki lub nagłówki HTTP). Powinno się także udostępnić rozwinięcie użytych skrótów i akronimów.
Znaczniki określające naturalny język dokumentu umożliwiają wyszukiwarkom odnalezienie słów kluczowych i identyfikację dokumentów o określonym języku. Zwiększając czytelność WWW dla wszystkich ludzi.
Jeśli skróty i zmiany języka naturalnego nie są określone, mogą okazać się nieczytelne po przetworzeniu na mowę lub alfabet brailla.

5. Twórz tylko prawidłowo skonstruowane tabele

poprzednie zalecenie: 4 - Określ użycie języków naturalnych  następne zalecenie: 6 - Używając nowszych technik zadbaj o czytelność w starszych przeglądarkach  do spisu treści rozdziału  do spisu treści strony

Upewnij się, że tabele mają znaczniki niezbędne dla zachowania czytelności w nietypowym oprogramowaniu.

Tabele powinny być używane tylko do prezentacji danych tabelarycznych ("tabele danych"). Powinno się unikać używania ich do tworzenia layoutu ("tabele layoutu"). Ale nawet poprawnie użyte tabele sprawiają problemy użytkownikom np. urządzeń głośnomówiących.
Oprogramowanie czasem umożliwia użytkownikom nawigację pomiędzy komórkami tabeli oraz dostęp do nagłówka i innych komórek tabeli. Jeśli jednak tabele nie będą we właściwy sposób skonstruowane nie zapewnią wymaganych przez oprogramowanie informacji.
Te zalecenia są ważne ze względu na ludzi, którzy dostęp do tabel uzyskują drogą dźwiękową lub nietypowe urządzenia takie jak komputery pokładowe lub PDA.

6. Używając nowszych technik zadbaj o czytelność w starszych przeglądarkach

poprzednie zalecenie: 5 - Twórz tylko proste tabele  następne zalecenie: 7 - Zapewnij użytkownikowi kontrolę nad zmieniającą się w czasie zawartością  do spisu treści rozdziału  do spisu treści strony

Upewnij się, że strony są dostępne także w wypadku kiedy nowsze technologie nie są wspierane lub są wyłączone.

Pomimo wszystkich zalet i możliwości nowych technologii należy umożliwić dostęp do treści także ludziom używających starszych przeglądarek i tym, którzy je wyłaczyli lub z innych powodów nie mogą skorzystać z nowszych technik.

7. Zapewnij użytkownikowi kontrolę nad zmieniającą się w czasie zawartością

poprzednie zalecenie: 6 - Używając nowszych technik zadbaj o czytelność w starszych przeglądarkach  następne zalecenie: 8 - Zapewnij bezpośredni dostęp do zagnieżdżonych interfejsów  do spisu treści rozdziału  do spisu treści strony

Upewnij się, że obiekty, które się poruszają, migoczą, przewijają i uaktualniają się automatycznie mogą być wstrzymane lub zatrzymane.

Niektórzy ludzie mający problemy poznawcze lub wzrokowe nie są w stanie czytać tekstu poruszającego się zbyt szybko (lub w ogóle ruchomego tekstu). Ruch na stronie może ponadto powodować takie rozproszenie uwagi, ze reszta strony będzie nieczytelna dla niektórych ludzi. Urządzenia głośnomówiące nie są w stanie odtworzyć ruchomego tekstu. Niepełnosprawni mogą mieć problemy w korzystaniu z ruchomych obiektów.
Uwaga. Wszystkie poniższe zalecenia zakładają pewną odpowiedzialność webmastera dopóki oprogramowanie nie zapewni odpowiednich mechanizmów kontroli tych właściwości.

Uwaga. Elementy BLINK i MARQUEE nie są zdefiniowane w żadnej specyfikacji HTML i nie powinny być używane.

8. Zapewnij bezpośredni dostęp do osadzonych interfejsów użytkownika

poprzednie zalecenie: 7 - Zapewnij użytkownikowi kontrolę nad zmieniającą się w czasie zawartością  następne zalecenie: 9 - Projektuj niezależnie od sprzętu użytkownika  do spisu treści rozdziału  do spisu treści strony

Upewnij się, że interfejs użytkownika jest zgodny z zasadami projektowania ukierunkowanego na dostępność: zapewnia funcjonalność niezależną od użytego sprzętu, umożliwia nawigację przy pomocy klawiatury, poleceń głosowych itp.

Jeśli osadzone obiekty mają "swój własny interfejs", ten interfejs musi - tak samo jak sam interfejs przeglądarki - spełniać wymogi dostępności. Jeśli nie można tego zapewnić koniecznie należy udostępnić alternatywne rozwiązanie.
Uwaga. Informacje o interfejsach spełniających wymogi dostępności można znaleźć w User Agent Accessibility Guidelines ([WAI-USERAGENT]) oraz w Authoring Tool Accessibility Guidelines ([WAI-AUTOOL])

9. Projektuj w sposób niezależny od sprzętu

poprzednie zalecenie: 8 - Zapewnij bezpośredni dostęp do zagnieżdżonych interfejsów  następne zalecenie: 10 - Używaj przejściowych rozwiązań  do spisu treści rozdziału  do spisu treści strony

Używaj metod zapewniających aktywację elementów strony przy pomocy wielu rodzajów urządzeń wejściowych.

Dostęp niezależny od urządzenia oznacza, że użytkownik może korzystać z oprogramowania lub dokumentu poprzez wybrane przez siebie urządzenie wejściowe (lub wyjściowe) - mysz, klawiaturę, głos lub inne. Jeśli, na przykład, elementy formularza mogą być uaktywnione tylko myszą lub innym urządzeniem wskazującym, ktoś korzystający tylko z poleceń głosowych, lub tylko z klawiaturą, lub używający innego nie-wskazującego urządzenia wejściowego nie będzie mógł skorzystać z tego formularza.
Uwaga. Udostępnienie tekstowych odpowiedników dla map odsyłaczy i grafiki użytej jako odnośników umożliwi interakcję z tymi elementami bez urządzeń wskazujacych.
Ogólnie rzecz biorąc strony umożliwiające nawigację przy pomocy klawiatury są także dostępne przez wejście głosowe i intefejs linii komend.

10. Używaj przejściowych rozwiązań

poprzednie zalecenie: 9 - Projektuj niezależnie od sprzętu użytkownika  następne zalecenie: 11 - Używaj technologii i zaleceń W3C  do spisu treści rozdziału  do spisu treści strony

Używaj przejściowych rozwiązań dostępności żeby zapewnić poprawne działanie strony także w starszych przeglądarkach i urządzeniach dla niepełnosprawnych

Na przykład starsze przeglądarki nie pozwalają użytkownikom przejść do pustych pól edycyjnych. Starsze urządzenia dla niepełnosprawnych odczytują listę następujących po sobie odnośników jako jeden odnośnik. Dlatego te aktywne elementy stwarzają problemy lub są w ogóle niedostępne. Także zmiana bieżącego okna lub użycie wyskakującego okna, może być bardzo dezorientujące dla użytkowników, którzy nie mogą zobaczyć tego co się stało.
Uwaga. Poniższe punkty kontrolne są ważne dopóki oprogramowanie i urządzenia dla niepełnosprawnych nie będzie w stanie poradzić sobie z tymi problemami. Dlatego te punkty kontrolne zostały zakwalifikowane jako "przejściowe". Oznacza to, że Web Content Guidelines Working Group uznaje je za prawidłowe i istotne dla wymogów dostępności w momencie publikacji tego dokumentu. Jednakże Grupa Robocza nie oczekuje, że będą ważne w przyszłości kiedy technologie internetowe przyswoją oczekiwane właściwości lub możliwości.

11. Używaj technologii i wytycznych W3C

poprzednie zalecenie: 10 - Używaj przejściowych rozwiązań  następne zalecenie: 12 - Udostępnij informacje zapewniające kontekst i ułatwiające orientacje  do spisu treści rozdziału  do spisu treści strony

Używaj technologii W3C (zgodnie ze specyfikacją) i podążaj za zaleceniami dostępności. Tam gdzie nie jest możliwe użycie technologii W3C, albo jeśli nie zapewnia to właściwego efektu, udostępnij alternatywną wersję, która spełnia wymogi dostępności.

Poleca się technologie W3C (jak np. HTML, CSS itp.) z wielu powodów:

Wiele formatów nie pochodzących z prac W3C (np. PDF, Shockwave itp.) wymaga podglądu przy pomocy specjalnych wtyczek lub oddzielnych aplikacji. Często te formaty nie mogą być widziane lub nie zapewniają nawigacji w standardowym oprogramowaniu. Unikanie technologii nie-W3C i niestandardowych właściwości (jak własnościowe elementy, atrybuty i rozszerzenia) zapewnia, że zawartość jest dostępna dla większej ilości ludzi, za pośrednictwem szerszego asortymentu oprogramowania i sprzętu. Kiedy muszą być użyte technologie uniemożliwiające zapewnienie dostępności musi być zapewniony odpowiednik który to umożliwia.
A jeśli się używa technologii W3C trzeba to robić zgodnie z wytycznymi dostępności. W przypadku użycia nowszych technologii należy się upewnić, że nie uniemożliwia to dostępu do zawartości dla ludzi nie mogących skorzystać z tych technologii.
Uwaga: efekt konwersji dokumentów (z PDF, PostScriptu, RTF itp.) na języki znaczników W3C (HTML, XML) nie zawsze spełnia wymogi dostępności. Dlatego po dokonaniu konwersji należy sprawdzać każdą stronę pod kątem dostępności i funkcjonalności. Jeżeli strona nie została przetworzona w czytelny sposób należy poprawić źródłowy dokument tak, żeby można było dokonać poprawnej konwersji lub udostępnić wersję HTML albo czysto tekstową.

Uwaga. Utworzenie alternatywnej strony jest ostatecznością, i powinno być stosowane dopiero jeśli inne rozwiązania zawiodą, ponieważ często zdarza się, że takie strony są aktualizowane z dużo mniejszą częstotliwością lub wcale. Nieaktualna strona jest tak samo zła jak nie spełniająca wymogów dostępności, w obu przypadkach informacja prezentowana na oryginalnej stronie jest niedostępna. Automatyczne generowanie alternatywnych stron może być dobrym sposobem na zapewnienie odpowiedniej częstości aktualizacji, ale należy się upewnić czy tworzona w ten sposób strony są sensowne oraz czy użytkownicy mają możliwość nawigacji zarówno na każdej z tych stron jak i pomiędzy nimi.
Przed podjęciem decyzji o utworzeniu alternatywnej wersji strony należy jeszcze raz rozważyć przystosowanie oryginalnej wersji do wymogów dostępności; jest to korzystne dla wszystkich użytkowników.

12. Udostępnij informacje zapewniające kontekst i ułatwiające orientacje

poprzednie zalecenie: 11 - Używaj technologii i zaleceń W3C  następne zalecenie: 13 - Udostępnij przejrzyste mechanizmy nawigacji  do spisu treści rozdziału  do spisu treści strony

Udostępnij informacje dotyczące kontekstu i ułatwiające orientację aby ułatwić użytkownikom zrozumienie bardziej skomplikowanych stron lub elementów.

Grupowanie elementów oraz zapewnienie kontekstowej informacji o powiązaniach między elementami może być użyteczne dla wszystkich użytkowników. Skomplikowane powiązania pomiędzy poszczególnymi częściami strony mogą być trudne do interpretacji dla ludzi z zaburzeniami poznawczymi lub wzrokowymi.

13. Zapewnij przejrzyste mechanizmy nawigacji

poprzednie zalecenie: 12 - Udostępnij informacje zapewniające kontekst i ułatwiające orientacje  następne zalecenie: 14 - Upewnij się, że dokumenty są przejrzyste i proste  do spisu treści rozdziału  do spisu treści strony

Zapewnij przejrzysty i konsekwentny system nawigacji - informacja ułatwiająca orientację, paski nawigacyjne, mapa strony, itp. - żeby zwiększyć możliwość odnalezienia tego czego się szuka na stronie.

Przejrzyste i zwarte mechanizmy nawigacji są ważne dla ludzi niewidomych i z zaburzeniami poznawczymi, przynoszą także pożytek wszystkim użytkownikom.

14. Upewnij się, że dokumenty są przejrzyste i proste

poprzednie zalecenie: 13 - Udostępnij przejrzyste mechanizmy nawigacji  do spisu treści rozdziału  do spisu treści strony

Upewnij się, że dokumenty są przejrzyste i proste; dzięki czemu w łatwiej mogą być zrozumiane.

Konsekwentny układ strony, wyraźna i rozpoznawalna grafika i łatwy do zrozumienia język przynoszą pożytek wszystkim użytkownikom. W szczególności pomogają ludziom z zaburzeniami poznawczymi i mającym problemamy z czytaniem. (Trzeba się upewnić, że ilustracje mają tekstowe odpowiedniki dla niewidomych, słabowidzących i tych którzy nie mogą lub zdecydowali się nie korzystać z grafiki.
Używanie przejrzystego i prostego języka ułatwia efektywną komunikację. Dostęp do zapisanej informacji może być trudny dla ludzi z zaburzeniami poznawczymi lub mających trudności w uczeniu się lub słabo znających język dokumentu.

Metody

poprzedni rozdział: Zalecenia  następny rozdział: Czytelne strony  do spisu treści 

Podstawą wszystkich metod zwiększenia dostępności jest znajomość zagadnień WAI, w możliwie jak największym zakresie. Bardziej niż w innych dziedzinach związanych z tworzeniem stron internetowych, w tym przypadku webmaster jest zmuszony do samodzielnej oceny swoich działań. Wymagana jest nie tylko logiczna ścisłość i uzasadnienie podjęcia konkretnych kroków (tak samo jak i rezygnacji z pewnych metod) - często bowiem zachodzi tu konieczność samoograniczania się, nieużywania technik powodujących problemy, mniej efektowny wygląd, a wszystko to nie ma sensu jeśli nie jest konsekwentne i nie tworzy pewnego zaprojektowanego dla potrzeb odbiorców danej strony profilu dostępności.
Należy sobie przede wszystkim zadać pytanie jaka jest grupa docelowa witryny, jakiego rodzaju będzie jej zawartość - z tego wynikną zarówno minimalne wymogi dostępności jak i określenie jakie technik koniecznie należy użyć, a z czego można zrezygnować. Jeśli jednym z priorytetów projektu jest dostępność zawartości (a pomijając wyjątkowe przypadki zawsze powinno tak być) pożyteczne jest założenie jak największej możliwej prostoty wyglądu i zastosowanych technik.

Formalna poprawność

Ścisłe trzymanie się standardów

To podstawowy warunek zapewniający czysty, przejrzysty kod niezależny od oprogramowania. Standardy W3C są opracowywane z myślą o ułatwieniach dostępu, są otwarte, dostępne bez opłat, a ponadto ani do tworzenia kodu, ani do jego odczytu nie wymagają konkretnego oprogramowania.

Używanie właściwych technik do właściwych celów

Zawsze używając jakiejś techniki do innego celu, niż ten do ktorego powstała należy się zastanowić czy rzeczywiście jest to konieczne.
Java nie powstała by tworzyć menu na stronach WWW. Tabela służy do prezentacji danych tabelarycznych a nie do tworzenia layoutu.

Unikanie przestarzałych rozwiązań

W3C zaleca nieużywanie znaczników ani atrybutów określanych jako deprecated, najlepszym przykładem jest tu znacznik <font>

Rozdział warstwy zawartości od warstwy prezentacji

Jest to kamień filozoficzny współczesnej alchemii WWW. Od kilku lat jak największe rozdzielenie zawartości od opisu wyglądu jest priorytetem rozwoju standardów W3C. Zalecenia formalnej poprawności są tak istotne wlaśnie dlatego, że przestrzeganie norm i stosowanie się do aktualnie zalecanych standardów powoduje oddzielenie obu warstw. Dzięki temu zawartość (określona w kodzie HTML lub XHTML) może być samodzielną całością zawartą w wyłącznie strukturalnych znacznikach, opis wyglądu (CSS) można dołączyć, w łatwy sposób modyfikować a co więcej dostosowywać do konkretnego medium lub zastosowania.
Wiele (a być może większość) z zaleceń WAI nie byłoby możliwych do zastosowania gdyby nie ścisłe oddzielenie zawartości od opisu jej wyglądu.

Dodatkowe zalecenia

W skrócie można to ująć tak: uniezależnij kod od czytnika, użyj jak najmniejszej ilości technik, określ jak najmniej i jak najmniej dokładnie.

Niezależność od konkretnej techniki

To dość ogólnie brzmiące zalecenie można wyjaśnić tak: żaden z elementów strony nie powinien być decydujący, nawet po wyłączeniu CSS i javascriptu - ilustracje powinny być opisane, tabele skomentowane, tekst (o ile to zwiększy jego czytelność) zilustrowany, pliki audio powinny być uzupełnione o skrypt. Wymienność tych elementów powinna mieć charakter funkcjonalny: opis ilustracji powinien koncentrować się na ich znaczeniu i zależeć od ich funkcji, komentarz tabel powinien wystarczać do ich zrozumienia itd.

Niezależność od konkretnego sprzętu

Zalecenie oczywiste ze względu na specyficzny sprzęt używany przez niepełnosprawnych jak i inne mniej typowe platformy (monochromatyczne terminale bez myszek, PDA, konsole) - nie można uzależniać dostępu do treści ani od określonej ilości kolorów, rozdzielczości, wielkości ekranu, w ogóle od istnienia ekranu i klawiatury lub myszy. Służy temu zachowanie logicznego układu znaczników strukturalnych, określenie porządku tabulacji i przede wszystkim: tekstowe odpowiedniki nie-tekstowej zawartości (<alt> i <longdesc>) oraz nawigacja niezależna od urządzenia wskazującego (myszki)

Niezależność od konkretnego programu

Tutaj zdecydowaną wyższość okazują otwarte standardy W3C. Zgodny ze specyfikacją HTML jest lepszy od HTML-u "Nur für MSIE". Języki znaczników hipertekstowych są łatwiejsze w zastosowaniu i udostępnianiu od zamkniętych, licencjonowanych firmowych standardów takich jak .pdf .doc .ppt czy flash. O ile pdf czy flash są niezależne od platformy i wymagają tylko bezpłatnych w pełni funkcjonalnych czytników o tyle "standardy" Microsoftu w ogóle nie nadają się do otwartego obiegu dokumentów. W3C kładzie szczególny nacisk na konieczność udostępnienia w takim wypadku alternatywy (strona wyłącznie flashowa powinna mieć HTML-owy odpowiednik, a treść dokumentu .pdf powinna być także dostępna w formacie HTML)

Minimalizm techniczny

Im mniejszej ilości technik się użyje tym mniej problemów sprawi dostosowanie kodu. Olbrzymie wymagania pod tym względem nakładają multimedia (animacje, dźwięk, zawartość interaktywna) dlatego należy je stosować tylko w wypadku kiedy są decydujące dla treści witryny i zapewnić adekwatną i równolegle uaktualnianą alternatywę. Ale także bez multimediów niektóre elementy mogą sprawiać więcej problemów, a mogą okazać się niepotrzebne; takim kwiatkiem do kożucha są np. przyciski w javie czy flashu. Bardzo kłopotliwe mogą się okazać również ramki, nie umieszczone w osobnych dokumentach formularze czy wreszcie tabela stosowana do utworzenia layoutu. O ile jakiś tego typu element nie jest niezbędny należy go unikać, a jeśli okaże się niezbędny należy zastosować go właściwie: proste tabele i znacznik <noframes> na stronach zbudowanych w ramkach.

Adaptowalna forma

Należy zachować jak największą elatyczność wyglądu, zdecydowanie odchodząc od typowej dla DTP tradycji ścisłego wyznaczania wyglądu, w ten sposób WWW stanie się samochodem, który przestanie udawać bryczkę a będzie w pełni korzystać z własnych możliwości. Na stronie WWW zawsze znajdzie się miejsce, a jej zawartość płynie, a nie jest na sztywno umieszczana. Ostatecznego wygladu i tak nie da się przewidzieć.
Metodą jest tutaj preferowanie wielkości relatywnych (np. procentowych lub w jednostkach em) zamiast absolutnych, czasem nawet w ogóle nie określanie wielkości, każda zdefiniowana a nie-niezbędna własność to zmniejszenie elastyczności.

Udogodnienia dostępności

Wymienione poniżej zalecenia zostały podzielone według Checklist of Checkpoints for Web Content Accessibility Guidelines 1.0, w żadnym jednak razie nie mogą służyć jako zamiennik tamtego dokumentu. Posłużył on tylko za wzór dla rozdzielenia ich według stopnia ważności. Polecam jego dokładne przeczytanie.
Jest to największy skrót.

Priority 1

Dokument musi być czytelny także bez CSS i javascriptu. Trzeba używać prostego i jednoznacznego języka i określić zmiany języka naturalnego. Użytkownikowi musi mieć kontrolę nad dynamiczną zawartością. Relacje pomiędzy elementami tabeli muszą być precyzyjnie i jednoznacznie okreśone a ramki zatytułowane. Zawartość multimedialna musi mieć tekstowy odpowiednik a pliki wideo dźwiękowy.
Jeśli dostosowanie nie jest możliwe trzeba utworzyć równolegle akualizowaną alternatywną wersję.

Priority 2

Należy unikać migotania, samoodświeżania, automatycznego przekierowania, wyskakujących okien, przejrzyście opisać cel odnośnika. Powinno się zapewnić ergonomiczną, przejrzystą nawigację, konsekwentny layout, informację o zawartości i jej położeniu, zastosować przejrzyste i dobrze opisane formularze, unikać animacji i ruchomych elementów na stronie.

Priority 3

Powinno się określić główny język dokumentu, wyjaśnić akronimy i skróty, zapewnić logiczny porządek tabulacji przez odnośniki pola formularzy i objekty, wypełnić wszystkie pola formularza domyślną zawartością, zapewnić skróty klawiaturowe. Dokument powinien mieć prostą strukturę, mieć podział na sekcje i wygodna nawigacja. Jeśli są funkcje wyszukiwania powinno się je zróżnicować stosownie do potrzeb i możliwości użytkownika.

Tworzenie stron czytelnych dla wszystkich

poprzedni rozdział: Metody  następny rozdział: Testowanie  do spisu treści strony

Witryna WWW jest produktem. Obojętnie czy jest to strona-wizytówka czy amatorska strona domowa hobbysty, sklep, witryna organizacji, firmy czy portal tematyczny obowiązują te same zasady produkcji.

Przeznaczenie

Zaczyna się od treści. Obie rzeczy zawartość (content) i grupa docelowa (target) określają się wzajemnie i obie trzeba możliwie dokładnie określić. W niektórych przypadkach grupa docelowa dokładniej określa profil strony. Więc nie tylko co ale i komu mówimy.

Na tym etapie można określić:

Dokładnie określony stopień zgodności z wymogami i polityka kontroli i utrzymania tej zgodności. Dla przykładu jeśli potrzeby zostały ustalone na Conformance Level "A" trzeba podążąć za wszystkimi wskazaniami WCAG 1.0 jakie go dotyczą.

Projekt

Podział zawartości na tematy i rodzaje nie jest wbrew pozorom taką prostą sprawą. Projekt zaczynający się od dobrze określonego profilu powinien mieć wynikający z niego podział na sekcje i wyraźnie określone wymogi w zakresie wyglądu i funkcjonalności.

Funkcjonalność, nawigacja, schemat (plan witryny).

O ile poprzedni etap był tworzeniem postulatów ten polega na tworzeniu idealnej strony. Jeszcze bez brania pod uwagę ograniczeń technicznych. W wyobraźni, na papierze, w programie graficznym.

Design, styl grafiki i wzór wyglądu strony: głównej i z poszczególnych działów.

Konstrukcja

Mamy trzy elementy:

Dokument (X)HTML zbudowany tylko ze strukturalnych znaczników, liniowa sekwencja tytułów, rozdziałów i menu dokładnie w takiej kolejności w jakiej jej odczytanie będzie najbardziej funkcjonalne dla odbiorcy. Dokumentacja WAI kładzie szczególny nacisk na poprawne zbudowanie takiej liniowej formy dokumentu, która składa się z logicznego podziału elementów dokumentu i zachowuje ich optymalną kolejność.

Przykładowo może to wyglądać w ten sposób:

  1. Nagłówek z tytułem strony
  2. Menu witryny
  3. Menu strony
  4. Zawartość podzielona na sekcje
  5. Menu witryny
  6. Stopka

Każdy z tych elementów na wynikającą z charakteru konstrukcję: tytuł strony to nagłówek H1, menu to lista (UL, OL) odnośników (A), w przypadku menu witryny raczej UL a menu dokumentu raczej OL, właściwa zawartość to sekwecja nagłówków (H2, H3, H4) i paragrafów (P) z listami (OL, UL) uzupełnionymi tam gdzie jest to potrzebne ilustracjami (IMG), stopka jest po prostu specyficznym paragrafem, który optycznie zamyka dokument i przekazuje niektóre informacje, np. o prawach autorskich.
Brak jakichkolwiek znaczników określających wygląd, np. EM i STRONG pojawiają się tylko tam gdzie ma to stosowny do tych znaczników kontekst w treści.

Powstaje w ten sposób surowa wersja (X)HTML, przypominająca witryny z początku lat 90-tych zbudowana wyłącznie z podstawowych znaczników: H1-H4, OL, UL, A, P, IMG, STRONG, EM (i TABLE tam gdzie są dane tabelaryczne).
Kod posiada właściwy prolog (najlepiej XHTML 1.1) i waliduje się.

Teraz znacznikami DIV tworzy się podział na podstawowe elementy layoutu strony

Najczęściej będzie to:

Najczęściej liniowa sekwencja dokumentu jest zgodna sekwencja layoutu, tzn. cały łańcuch elementów da się podzielić po kolei na bloki layoutu. Interesującym wyzwaniem są sytuacje kiedy te podziały są ze sobą niezgodne.

Każdy element DIV ma identyfikator określający funkcję, tak samo w przypadku nazw klas jak i elementów powinno się używać znaczących określen odwołujących się do roli danego wyróżnienia: czyli raczej "menu_wewnetrzne" zamiast "dolne_menu" i "wazne" zamiast "czerwony". Przez edycję właściwości CSS tworzy się layout pamiętając o zaleceniach WAI, czyli np. stosując raczej relatywne jednostki wielkości zamiast absolutnych.
Warto unikać stosowania właściwości, które dotąd nie są realizowane przez niektóre przestarzałe i niestety dość popularne przeglądarki. Dla przykładu - MSIE 5.0 nie rozumie atrybutu float i jeśli użytkownicy także i tej przegladarki mają znaczenie nie powinno się używać tego atrybutu do budowania zasadniczego layoutu strony.
W elementach IMG pownny być umieszczone tylko te elementy graficzne, które mają znaczenie inne niż ozdobne: ilustracje, przyciski graficzne, symbole itd. Całą wyłącznie prezentacyjną część graficzną najlepiej jest umieszczać w tle elementów jako background-image.

Na tym etapie powinno się również określić wielkość i rodzaj fontów, szczególnie jeśli - co jest zalecane - używa się relatywnych jednostek wielkości.

Po utworzeniu layoutu trzeba sprawdzić czy jednakowo wygląda we wszystkich przeglądarkach uznanych za istotne oraz czy zmiana rozmiaru nie powoduje utrudnień w odczytaniu treści (uwaga: Firefox i Opera realizują tą funkcję w całkowicie odmienny sposób).

Ostatnim etapem tworzenia strony jest doprecyzowanie część prezentacyjnej (tej która nie jest bezpośrednio związana z layoutem): kolor fontów i tła, właściwości graficzne wszystkich obiektów itd.

Testowanie

poprzedni rozdział: Czytelne strony  następny rozdział: Na tej stronie  do spisu treści strony

Nie istnieje żaden sposób sprawdzenia strony, który by dawał całkowitą gwarancję poprawności w tym zakresie. Nie możemy również przetestować kodu na wszystkich programach i urządzeniach, ale jest kilka metod by sprawdzić czy zrobiliśmy wszystko co jest możliwe, żeby nie tworzyć barier w dostępie do zawartości.

Poprawność kodu (HTML i CSS)

W3C: HTML Validator oraz CSS Validator
Jest to pierwszy i niezbędny etap sprawdzania dostępności. Zapewnia dwie rzeczy:

Bez javascriptu i CSS

Wyłącz javascript i CSS. Najlepiej zrobić to bezpośrednio w ustawieniach przeglądarki zamiast manipulować kodem.
Doskonałe narzędzia do takiego testu oferuje Opera 7.x

Czy strona zachowuje czytelność? Czy działa nawigacja? Sprawdzenie tego jest ważne nie tylko ze względu na użytkowników mających tekstowe przeglądarki lub wyłączających javascript. Jeżeli nadal zachowany jest dostęp do zawartości oznacza to, że zarówno kod jest przejrzyście i logicznie ułożony jak i niezależny od specyficznych dla niektórych przeglądarek właściwości tych języków (nawet pomimo zgodności ze standardem istnieją róznice w interpretacji).

Wygląd i działanie w różnych przeglądarkach

Na tym etapie należy sprawdzić wygląd strony w jak największej ilości przeglądarek, absolutnym minium są trzy pierwsze:

Internet Explorer 5.0 lub 5.5

W zasadzie nie powinno być różnic pomiędzy nimi, a poprawne działanie w jednej z tych przeglądarek oznacza też, że nie wystąpią poważniejsze problemy z MSIE 6.0

Mozilla 1.7.x - Firefox 1.x

Podstawowym priorytetem dla twórców tego programu jest zgodność ze standardami. Posiada również pożyteczne narzędzia takie jak: Inspektor DOM, Debugger kodu js.

Opera 8.x

Ważna nie tylko ze względu na użytkowników Opery, posiada bowiem bardzo wygodne dla webmastera możliwości przełączenia na jeden z istniejących w przeglądarce styli:

Szczególnie ważne są pierwszy i trzeci

Inne mniej popularne przeglądarki:

Wprawdzie w internecie najbardziej popularną platformą jest MS Windows ale dobrze jest też sprawdzić wygląd strony dla innych systemów operacyjnych, Konqueror (Linux/KDE), Galeon (Linux/Gnome), Safari (Mac).
Na ile jest to bardzo ważne, zależy od grupy docelowej.

Przeglądarki tekstowe:

Można sprawdzić także używając Opery (View/Style/User mode - Emulate text browser), lub podglądu na Lynx View

Walidacja WAI

Nie ma możliwości automatycznego przetestowania kodu, zarówno lista pytań jak i same walidatory WAI wymagają samodzielnego sprawdzenia poprawności. Jest to czasochłonne i wymaga pewnej orientacji w zakresie wymogów WAI. Ostatecznie przydzielenie stronie jakiegoś stopnia zgodności jest wyłącznie wynikiem decyzji człowieka. Jak stwierdza W3C: umieszczenie banera WAI jest tylko oświadczeniem autora strony i nie można tego w automatyczny sposób zweryfikować.

Realizacja ułatwień dostępu w przeglądarkach

poprzedni rozdział: Testowanie  następny rozdział: Na tej stronie  do spisu treści strony

Opera

Firefox

Rozszerzenia:

Na tej stronie...

poprzedni rozdział: Realizacja ułatwień dostępu w przeglądarkach  następny rozdział: Odnośniki  do spisu treści strony

Jak skończę wszystkie rozdziały oraz nawigację opiszę wszystkie użyte tu techniki. Napisanie tego rozdziału ma sens tylko na samo zakończenie.
Wstępnie:
- kod jest całkowicie zgodny z zalecanymi aktualnie standardami W3C, bez znaczników deprecated
- wewnątrz dokumentu HTML używam wyłącznie znaczników strukturalnych (elementów div i span, nagłówków i zagnieżdżonych list), wygląd opisuję używając CSS - a i to w jak najmniejszym stopniu
- dokument jest prosty i logicznie uporządkowany, nie stosuję żadnej techniki mogącej spowodować problemy (tabele, ramki)
- utworzyłem nawigację pomiędzy poszczegolnymi sekcjami dokumentu
- staram się używać możliwie prostego języka (uuups)
- wszystkie elementy graficzne mają funkcjonalne zamienniki tekstowe
na później:
- acceskey i wiele innych rzeczy....

Odnośniki:

poprzedni rozdział: Na tej stronie...  do spisu treści strony

Wszystkie odnośniki są na dwww.pl, nowe:

1. Znamy sie na tematyce i zajmowalismy się nią już dawno, pierwsi zaczęliśmy tłumaczenie dokumentów WAI. 2. Gwarantujemy dobry kontakt ze srodowiskiem i otwarty proces tłumaczenia - produkt będzie funkcjonalny. 3. Samo tłumaczenie jest tylko częścią, pierwszym etapem naszej oferty. 4. Zachowamy licencję tekstów. 5. Mamy referencje AviaryPL, które tłmaczy Firefoksa, oraz współpracuje z Novellem a także zajmuje się developer.mozilla.org 1. Web Content Accessibility Guidelines 1.0 http://www.w3.org/TR/WCAG10/ Zasadniczy dokument WAI dotyczący Web Accessibility. Aktualnie obowiązujący standard W3C, podstawa zaleceń EU. Definiuje dostepnosc w formie listy wytycznych, ktore trzeba zrealizowac. Jest dokumentem referencyjnym dla Techniques... oraz Checklist... i dopiero razem tworza calosc. Okresla trzy poziomy dostepnosci rozniace sie stopniem zaawansowania: A - usuniecie potencjalnych barier dostepu AA - usuniecie potencjalnych trudnosci w dostepie AAA - stworzenie ulatwien w dostepie EU zaleca przynajmniej pierwszy poziom dostepnosci. 2. eAccessibility of public sector services in the European Union PDF: http://www.cabinetoffice.gov.uk/e-government/docs/eu_accessibility/pdf/eaccessibility(eu)_report.pdf HTML: http://www.cabinetoffice.gov.uk/e-government/resources/eaccessibility/content.asp Raport Prezydencji Brytyjskiej, który może być podstawą do opracowania wlasnej metodologii testów, stworzenia stalego programu walidacji, wdrozenia go i utrzymania postulowanej dostepnosci. Jest praktycznym uzupelnieniem dla Evaluating Web Sites for Accessibility. 3. Checklist of Checkpoints for Web Content Accessibility Guidelines 1.0 http://www.w3.org/TR/WCAG10/full-checklist.html Krótka tabela wyliczająco - osobno dla każdego poziomu zgodności - wszystkie wymogi niezbędne do jego zapewnienia. Techniczne narzedzie do przeprowadzanego przez czlowieka testu zgodnosci z wytycznymi WCAG 1.0. Uzywa sie jej bardzo prosto, bo odpowiedzia na pytanie jest: tak, nie, nie dotyczy. Ale do jej uzycia niezbedna jest dobra znajomosc i rozumienie WCAG 1.0. 4. Evaluating Web Sites for Accessibility http://www.w3.org/WAI/eval/Overview.html Obszerny i dokładny dokument, opisujący proces walidacji dostępnosci. Jest niezbedny do stworzenia programu wdrozenia dostepnosci. Poprzednia wersja została już usunięta z sieci a obecna ma status finalny. To co było przedtem pojedynczym dokumentem teraz zostało podzielone na osiem części: a) Preliminary Review of Web Sites for Accessibility http://www.w3.org/WAI/eval/preliminary.html b) Conformance Evaluation of Web Sites for Accessibility http://www.w3.org/WAI/eval/conformance.html c) Evaluation Approaches for Specific Contexts http://www.w3.org/WAI/eval/considerations.html e) Involving Users in Web Accessibility Evaluation http://www.w3.org/WAI/eval/users.html f) Selecting Web Accessibility Evaluation Tools http://www.w3.org/WAI/eval/selectingtools.html g) Evaluation, Repair, and Transformation Tools for Web Content Accessibility http://www.w3.org/WAI/ER/existingtools.html h) Review Teams for Evaluating Web Site Accessibility http://www.w3.org/WAI/eval/reviewteams.html i) Template for Accessibility Evaluation Reports http://www.w3.org/WAI/eval/template.html 5. Developing a Web Accessibility Business Case for Your Organization http://www.w3.org/WAI/bcase/Overview Jest to swego rodzaju PR dostępnosci obszernie wyjasniajacy roznego rodzaju korzysci z zastosowania wytycznych WCAG 1.0. Zastepuje Benefits... Podobnie jak w przypadku Evaluating... poprzednia wersja została zastąpiona nowszą, ale w tym przypadku poprzednia wciąż jest dostępna w sieci, a aktualna nie jest jeszcze ukończona. Niemniej jednak uwazamy za sensowne przetlumaczenie tego "jak jest" w obecnej postaci, zamiast zajmowania sie dokumentem, ktory niedlugo zostanie wycofany. Nowa wersja jest lepsza i kiedy osiagnie stadium finalne latwo bedzie mozna uaktualnic tlumaczenie korzystajac z changelogu. To co poprzednio bylo jednym dokumentem teraz zostalo podzielone na cztery czesci, ktore wyjasniaja korzysci z wdrozenia dostepnosci wedlug podzialu na spoleczne, techniczne, finansowe i prawne. a) Social Factors in Developing a Web Accessibility Business Case for Your Organization http://www.w3.org/WAI/bcase/soc.html b) Technical Factors in Developing a Web Accessibility Business Case for Your Organization http://www.w3.org/WAI/bcase/tech c) Financial Factors in Developing a Web Accessibility Business Case for Your Organization http://www.w3.org/WAI/bcase/fin d) Legal and Policy Factors in Developing a Web Accessibility Business Case for Your Organization http://www.w3.org/WAI/bcase/pol 6. How People with Disabilities Use the Web http://www.w3.org/WAI/EO/Drafts/WAI-access-profiles Systematyczne przedstawienie problemów jakie mogą napotkać uzytkownicy w dostepie do tresci internetowych, w formie podzialu na rodzaje problemów oraz serii scenariuszy prezentujacych typowe sytuacje zwiazane z dostepnoscia. 7. Introducing Accessibility Trzy niedlugie dokumenty w prosty sposob wyjasniajace czym jest dostepnosc i zarysowujace metody jej zapewnienia. a) Introduction to Web Accessibility http://www.w3.org/WAI/intro/accessibility.php b) Essential Components of Web Accessibility http://www.w3.org/WAI/intro/components.php c) Quick Tips to Make Accessible Web Sites http://www.w3.org/WAI/References/QuickTips/Overview.php 8. Techniques for WCAG 1.0 Obszerne zalaczniki do WCAG 1.0 szczegolowo wyjasniajace w jaki sposob spelnic wytyczne zawarte w dokumencie referencyjnym. O ile WCAG 1.0 wytycza droge to Techniques... w techniczny sposob objasniaja jak spelnic wytyczne. a) Techniques for Web Content Accessibility Guidelines 1.0 http://www.w3.org/TR/WCAG10-TECHS/ b) Core Techniques for Web Content Accessibility Guidelines 1.0 http://www.w3.org/TR/WCAG10-CORE-TECHS/ c) HTML Techniques for Web Content Accessibility Guidelines 1.0 http://www.w3.org/TR/WCAG10-HTML-TECHS/ d) CSS Techniques for Web Content Accessibility Guidelines 1.0 http://www.w3.org/TR/WCAG10-CSS-TECHS/ 9. Accessibility Features of CSS http://www.w3.org/TR/CSS-access Uzupelnienie dla Techniques... 10. Fact Sheet for Web Content Accessibility Guidelines 1.0 http://www.w3.org/1999/05/WCAG-REC-fact.html FAQ wyjasniajacy zagadnienia zwiazane z dokumentami WAI. Jestesmy pod wrazeniem decyzji o tlumaczeniu dokumentow WC3 na jezyk polski. Moze ona oznaczac dlugo oczekiwany w srodowisku polskich webmasterow zwrot w kierunku wiekszej zgodnosci stron WWW z normami W3C. Z checia wezmiemy udzial w tlumaczeniu tych dokumentow w ramach oficjalnego rzadowego projektu. Uwazamy jednak, ze dla zapewnienia jego skutecznosci proces tlumaczenia powinien przebiegac w ramach otwartej dyskusji dotyczacej np. nomenklatury technicznej. Dokumentacja powinna odzwierciedlac juz uzywane slownictwo lub tworzyc je w zgodzie z istniejaca tradycja. Jej sens jest nieoddzielny od aplikacji i konwencji slownych, ktore znaja tylko ludzie praktycznie zajmujacy sie tym zagadnieniem. Powinna rowniez temu towarzyszyc akcja promocyjna majaca na celu propagowanie i wyjasnianie zagadnien zwiazanych z Web Accessibility. Co do tak duzego zakresu pracy jestesmy w stanie zagwarantowac to wylacznie w ramach projektu AviaryPL i uwazamy, ze tylko w ten sposob mozna spelnic powyzsze wymogi. AviaryPL to ceniony zespół tłumaczy, z którym ściśle wspólpracujemy. Sami mozemy podjac sie tego tylko dla WCAG 1.0 i powiazanych z nim dokumentow a takze raportu Prezydencji Brytyjskiej. W ten sposob zagwarantujemy nie tylko szybkie wykonanie pracy, ale rowniez wysoka jakosc merytoryczna tlumaczenia i jego wplyw na srodowisko, ktore od dawna czeka na tego typu inicjatywe. Da sie to zauwazyc nie tylko na rownego rodzaju forach internetowych (takich jak np. grupa usenetowa pl.comp.www), ale rowniez w postaci takich projektow jak http://browsehappy.pl , http://osiolki.pl czy nasz skromny http://dwww.pl . Zainteresowanie problemami dostepnosci jest duze potrzebna byla tylko inicjatywa, ktora by zogniskowala ten potencjal i czyms takim miala byc nasza "Web Accessibility po polsku" niestety z powodu braku czasu tlumaczenie samego WCAG 1.0 zostalo przerwane. Mielismy do niego wrocic w najblizszym czasie - w zasadzie jest prawie skonczone - z tym wiekszym zainteresowaniem przeczytalismy informacje o zainteresowaniu Ministerstwa tlumaczeniem dokumentow W3C. WCAG 1.0 jest wprawdzie trzonem prac Web Accessibility Initiative - grupy roboczej powolanej w ramach W3C do prac nad zagadnieniami dostepnosci internetowej - ale rownolegle WAI opracowalo inne materialy, ktore lacznie z WCAG 1.0 uzupelniajac sie, tworza calosc uzyteczna dla specjalistow jak i dla zainteresowanych tym zagadnieniem. Poza samym WCAG 1.0 sa to: 1) Auxiliary Benefits of Accessible Web Design http://www.w3.org/WAI/bcase/benefits.html 2) Evaluating Web Sites for Accessibility http://www.w3.org/WAI/eval/ 3) Accessibility Features of CSS http://www.w3.org/TR/CSS-access 4) How People with Disabilities Use the Web http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/ Pierwszy z nich przystepnie i kompleksowo wyjasnia korzysci z zastosowania sie do wymogow WCAG. Drugi opisuje proces kontroli i dostosowania witryn WWW w celu spelniania tych wymogow i w duzej mierze na nim wlasnie oparty jest raport Prezydencji Brytyjskiej. Trzeci zas koncentruje sie na zgodnym z zaleceniami WCAG zastosowaniu Kaskadowych Arkuszy Stylow. Ostatni wyjasnia problemy dostepnosci od strony osob niepelnosprawnych. Dlatego kiedy zaczelismy tlumaczyc WCAG nigdy nie oddzielalismy powiazanych z nim dokumentow. Wylaczaczyloby to najwazniejszy z nich z kontektu utworzonego przez WAI. Co warto dodac nawet sam WCAG 1.0 nie stanowi odrebnej calosci, poniewaz dowiazane sa do niego bezposrednio cztery dokumenty wyjasniajace zagadnienia stricte techniczne. 1) Checklist of Checkpoints for Web Content Accessibility Guidelines 1.0 http://www.w3.org/TR/WAI-WEBCONTENT/full-checklist.html 2) Techniques for Web Content Accessibility Guidelines 1.0 http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/ 3) Core Techniques for Web Content Accessibility Guidelines 1.0 http://www.w3.org/TR/WCAG10-CORE-TECHS/ 4) HTML Techniques for Web Content Accessibility Guidelines 1.0 http://www.w3.org/TR/WCAG10-HTML-TECHS/ 5) CSS Techniques for Web Content Accessibility Guidelines 1.0 http://www.w3.org/TR/WCAG10-CSS-TECHS/ Najprawdopodobniej w tym roku mozemy sie spodziewac wersji 2.0 [ http://www.w3.org/TR/WCAG20/ ] tej specyfikacji, skonstruowanej zupelnie inaczej. Nie tak jak w przypadku obecnej, ktora jest zbudowana na liscie problemow, ale raczej na postulatach dotyczacych technicznych wlasciwosci, ktore prowinna prezentowac tresc. W najbliższym czasie skontaktujemy się z zespołem AviaryPL, w tej chwili jednak chcielibyśmy zgłosić chęć podjęcia się tłumaczenia tylko wybranych dokumentów, tj. WCAG 1.0 i okumentów z nim powiązanych oraz raportu Prezydencji Brytyjskiej. W odpowiedzi na Państwa mail z wielką przyjemnością chciałabym zaproponować spotkanie - i ile mają Państwo czas i ochotę - w celu omówienia ewentualnej współpracy. Państwo mają pomysły i wiedzę , a ja możliwość sfinansowania projektu z ramienia MSWiA. Nasze spotkanie miałoby na celu nie tylko sprawę jak najsensowniejszego przeprowadzenia projektu tłumaczenia(a wnosząc po Państwa mailu nasza współpraca mogłaby dać wspaniałe rezultaty oraz gewarancje, że pieniądze publiczne zostaną wydane w efektywny sposób) jak również innych form promocji eDostępności. Absolutnie podzielam Państwa zdanie, że tłumaczenie tych dokumentów jest dopiero pierwszym krokiem w całym projekcie promocji i wdrażania eDostępności. Piszą Państwo: "Zainteresowanie problemami dostępności jest duże, potrzebna była tylko inicjatywa, która by zogniskowala ten potencjal". Proszę potraktwać mój mail jako właśnie taką nicjatywę i zaproszenie do jak najszerszej współpracy całego środowiska z MSWiA jako ministerstwa zajmujacego się sprawami informatyzacji i społeczeństwa informacyjnego. Państwo mają wiedzę i pomysły, ja możliwości ich realizacji, dlatego proszę poinformować o moim zaproszeniu do spotkania osoby, które Państwa zdaniem powinny również zostać zaangażowane do projektu. Szanowna Pani, Dziękując raz jeszcze za zainteresownie problematyką Web Accessibility, chcielibyśmy zapewnić, że jesteśmy bardzo zainteresowani współpracą z MSWiA. Dziękujemy również za zaproszenie do spotkania. Natomiast już teraz chcielibyśmy przedstawić przygotowany na początku poprzedniego roku, ale wciaż aktualny, szkic zalożeń naszego projektu, który mógłby posłużyć za punkt wyjścia do rozmowy o dalszej współpracy. Znajduje sie on pod adresem: http://www.isoc.org.pl/wiki/index.php/WebAccessibility

Hej. Przesyłam Ci to, co napisałem kiedyś i dokończyłem dziś. Jutro wieczorem będę w Internecie, także prawdopodobnie ok. 16. Brakuje mi jednego punktu, mianowicie tego o licencji - czy mógłbys mi podpowiedzieć, jak to napisac? Karolina nic nie pisała, trzeba by się odezwać. Proponuję skończyć to jutro i przesłać na wtorek rano. Do usłyszenia, St. PS W zalączniku przesyłam ten tekst w pdf-ie, żeby pokazać, jak mniej więcej zobaczy go Karolina. ######## START ####### W nawiązaniu do wcześniejszych rozmów i ustaleń pragniemy zaprezentować listę kilku powodów, które naszą ofertę tłumaczenia dokumentów W3C czynią atrakcyjną. 1. Znamy sie na tematyce i zajmowalismy się nią już dawno, pierwsi zaczęliśmy tłumaczenie dokumentów WAI. 2. Gwarantujemy dobry kontakt ze srodowiskiem i otwarty proces tłumaczenia - produkt będzie funkcjonalny. 3. Samo tłumaczenie jest tylko częścią, pierwszym etapem naszej oferty. 4. Zachowamy licencję tekstów. 5. Mamy referencje AviaryPL, które tłmaczy Firefoksa, oraz współpracuje z Novellem a także zajmuje się developer.mozilla.org 1. Tematyka zgodna z naszymi zainteresowaniami Jesteśmy osobiście zainteresowani tą tematyką - zarówno tworzeniem stron WWW zgodnie ze standardami jak i wytycznymi dostępności (które tak naprawdę stanowią sens istnienia tych standardów). Śledzimy to co się dzieje na różnych forach dyskusyjnych (np. grupa usenetowa pl.comp.www czy forum mozillapl.org) i blogach, w których pojawia się ta tematyka (tu szczególnie jogger.pl). Zagadnienia dostępności zajęły nas jeszcze w 2003, kiedy zaczęliśmy pracę nad naszą stroną dwww.pl. Była to pierwsza tego typu inicjatywa w polskim internecie i jak dotąd jest jedyna. Od tamtego czasu stale rozwijamy nasz projekt. W 2004 roku pojawiliśmy się w prasie - o e-dostępności i dwww.pl napisał Magazyn Internet (nr 05/2004), w którym ukazał się także wywiad z nami. Oprócz działalności internetowej staramy się promować ideę e-dostępności za pomocą wykładów. W 2004 roku podczas Jesieni Linuksowej, spotkania informatycznego w Ustroniu, miała miejsce prelekcja pt. "Web Accessibility w Polsce i po polsku", z kolei w 2005 roku na Wydziale Matematyki, Informatyki i Mechaniki Uniwersytetu Warszawskiego odbył się wykład pt. "Wykorzystanie CSS do tworzenia dostępnych stron internetowych". 2. Otwarty proces tłumaczenia Zgodnie z ideami Open Source, które towarzysza nam od samego początku, gwarantujemy, że proces tłumaczenia będzie otwarty - na kazdym jego etapie wszyscy zainteresowani - przede wszystkim osoby związane z tworzeniem stron internetowych oraz zagadnieniami e-dostępności - będą mogli przeczytać, ocenić i skomentować tłumaczenie. Jesteśmy przekonani, że środowiska skupione wokół grup dyskusyjnych nie pozostaną obojętne na inicjatywę tłumaczenia dokumentów WAI, a czytelnicy tych grup będą aktywnie uczestniczyć w tłumaczeniu i jego korekcie. Ten system pracy pozwoli zapewnić całkowitą zgodność słownictwa użytego w tekście tłumaczenia ze słownictwem funkcjonującym w rzeczywistości. To m.in. ten wkład (w formie otwartej dyskusji) gwarantuje wysoką jakość tłumaczeń. Co więcej, otwartość procesu tłumaczenia zapewni i legitymację społeczności związanej z tematyką Web Accessibility i umożliwi ich promocję i rozpowszechnienie. Ma to tym większe znaczenie, że niektóre i to dość kluczowe pojęcia (np. "transforms gracefuly") trzeba będzie dopiero przełożyć na polski. Gwarantujemy zatem, że nasze tłumaczenia będą funkcjonować i będą uznawane w środowiskach ludzi tworzących strony internetowe oraz osób niepełnosprawnych. 3. Niezmieniona licencja dokumentów [Nie bardzo wiem, jak to napisać.] Koniecznie o ISOC, pomimo, że jest ostatnim punkcie. 4. Tłumaczenie częścią większego projektu Przetłumaczenie dokumentów W3C traktujemy jako pierwszy etap realizacji całego projektu promocji i upowszechniania idei e-dostępności. Po tym etapie mogłyby nastąpić: a) Przygotowanie witryny internetowej z informacjami o e-dostępności, artykułami (promocyjnymi oraz technicznymi) oraz galerią dobrych i złych przykładów stron internetowych [ http://isoc.org.pl/wiki/index.php/WebAccessibility ]. Jest to naturalna kontynuacja procesu tłumaczenia, którą proponujmy przeprowadzić w podobny, otwarty sposób. Stworzenie i udostępnienie tych materiałów w jednym miejscu razem z dokumentacją WAI ułatwi proces wdrażania e-dostępności i jest uzupełnieniem dokumentacji WAI o konkretną, techniczną treść. b) Przeprowadzenie przykładowego wdrożenia dostępności na jednej ze stron administracji publicznej i opublikowanie pełnej dokumentacji tego procesu. Udowodni to w praktyce zalety e-dostępności i pomoże wypromować standardy WAI. c) Organizowanie konferencji, których celem byłoby uświadomienie i nagłośnienie problemu. d) Opracowywanie cyklicznych raportów o stanie stron internetowych administracji publicznej. e) Promocja marki dwww (Dostępne WWW) jako symbolu i manifestu dostępności, który mógłby być z łatwością stosowany przez instytucje oraz firmy (www.przyklad.pl - dwww.przyklad.pl). Widzimy to jako pełen proces wiodący do wdrożenia standardów na szeroką skalę. Najpierw przez tłumaczenie podstawowych specyfikacji. Potem obudowanie ich własną dokumentacją, która szczegółowo wyjaśniałaby techniczne zagadnienia i pomogła stworzyć zarówno miejsce w sieci jak i społeczność specjalizującą się w tych zagadnieniach. Na końcu praktycznym przykładem wdrożenia norm e-dostępności. Są to trzy etapy, które trudno od siebie oddzielić. (tu coś jeszcze przydałoby się napisać). 5. Aviary.pl i ISOC Korzystamy z doświadczenia grupy Aviary.pl, która od 2003 roku zajmuje się tłumaczeniami informatycznymi. Dorobek Aviary.pl obejmuje takie projekty jak Mozilla Firefox, Mozilla Thunderbird, BugZilla, Camino, SeaMonkey oraz OpenSUSE, które znajduje się pod opieką firmy Novell. Mamy również wsparcie polskiego oddziału ISOC, najważniejszej organizacji zajmującej się standardami internetowymi.

[ redesign ] || [ na górę strony ]