Dostępny.net

Skip linki są (nie)potrzebne

Jak obiecałem – zajmuję się tematem tzw. skiplinków. Skiplink to anglicyzm oznaczający dodatkową nawigację (często ukrytą w warstwie wizualnej) pozwalające na szybkie przemieszczanie się pomiędzy elementami składowymi strony. Najczęściej umieszczane na początku strony pozwalają przeskoczyć np. wprost do treści z pominięciem nawigacji.Ich wykorzystanie to realizacja m.in. wytycznej 13. WCAG – Zapewnij jasny mechanizm nawigacyjny.

Podczas badania stron serwisów partii politycznych brak dodatkowej nawigacji w połączeniu z brakiem jakichkolwiek nagłówków i rozmieszczeniem elementów na stronie metodą to co po lewej (menu) pierwsze na stronach PSL wprawiał użytkowników w nie lada frustrację. A to dlatego, że biedny użytkownik musiał za każdym razem odsłuchać nazwy wszystkich elementów w menu zanim doczłapał do treści.

Układ zamiast nawigacji

W tytule postawiłem śmiałą tezę, że skip linki są niepotrzebne. Bo kto powiedział, że jasny mechanizm nawigacyjny da się zapewnić tylko w ten jeden sposób? Z obserwacji wiem, że osoby niewidome trafiając na “nową” stronę zaczynają od sprawdzenia czy strona ma nagłówki Hx. Dopiero później zwracają uwagę na alternatywne sposoby nawigacji. Jeśli więc na stronie pojawi się <h2>Menu główne</h2> ... <h2>Tytuł artykułu</h2> – zapewnimy użytkownikowi mechanizm nawigacyjny co jest naszym celem.

Nie bez znaczenia jest też układ elementów w kodzie źródłowym strony. Jeśli treść znajdzie się przed nawigacją (CSS pomoże ładnie to ułożyć potem na stronie) to w znaczącej większości wypadków zapewnimy użytkownikowi szybki dostęp do informacji, której akurat poszukuje. Skip link do treści z oczywistych powodów potrzebny nie będzie, pozostaje ew. linkowanie do nawigacji.

Jeśli dodatkowo będziemy konsekwentnie trzymać się układu i kolejności elementów na poszczególnych stronach – sukces nieomal murowany.

Nieomal, ponieważ kwestia dotyczy nie tylko niewidomych ale również użytkowników przeglądarek tekstowych (mało ich już) oraz urządzeń mobilnych. Ja sam nie raz musiałem przebierać palcami po klawiszach telefonu by przewinąć pojawiająca się stronę. Dla tychże skiplinki będą nieocenioną pomocą, a ponieważ ich realizacja nie wymaga niesamowitych umiejętności i czasu to zamiast wdawać się w jałową polemikę lepiej od razu je dodać ;-)

Na koniec kilka uwag technicznych:

Oczywistością powinno być, że linki umieszczamy na początku strony jeśli dodatkowo zgrupujemy je np. za pomocą listy <ul> z krótkim opisem w title tym bardziej ułatwimy ich znalezienie. Widziałem już mechanizmy “wspomagające” na stronach umieszczone w takim miejscu, że niewidomy dowiadywał się o nich dopiero jak ktoś mu pokazał gdzie to jest ;-)

Po drugie z przyczyn wspomnianych w poprzednim wpisie z uwagi głównie na użytkowników widzących aktywne skip linki powinny mieć swoje miejsce w warstwie widzialnej serwisu.

IE, hasLayout, a skiplinki

Trzecie zagadnienie zasłużyło na własny śródtytuł.  Ze względu na specyficzne zachowanie Internet Explorera ważna jest odpowiednia konstrukcja samego kodu elementu docelowego.
Kłania się tu jeden z pomysłów twórców tej przeglądarki jakim jest znienawidzony za swoją nieobliczalność atrybut hasLayout:

Jeśli korzystając z klawiatury przejdziemy poprzez skiplink do treści intuicyjnie następnym elementem do odczytania powinien być tekst, a kolejnym linkiem pierwszy znajdujący się w tejże. Rzecz jednak w tym, że czasem kliknięcie klawisza tabulacji przenosi z powrotem na początek strony do elementu tuż za skip linkiem. Skąd się to bierze? Ano z pomysłu twórców IE by podzielić elementy na stronie na takie, które “layout” mają i takie, które nie.

Dla linku <a href="#tresc">Skocz do treści</a> miejsce docelowe możemy zdefiniować ogólnie rzecz biorąc na dwa sposoby:

  • poprzez utworzenie kotwicę (elementu A)
  • poprzez nadanie atrybutu id obiektowi do którego się odnosimy

W pierwszym wypadku nasz cel mógłby wyglądać tak: <a name="tresc"></a>. W przypadku XHTML gdzie atrybut name jest wycofany zachowując jednak zgodność wsteczną dla starszych przeglądarek otrzymamy: <a name="tresc" id="tresc"></a>.

W drugim od razu używamy id więc otrzymujemy postać: <DIV id="tresc">Lorem impsum sid dolor amet</DIV>.

Drugi przypadek choć wygląda zdecydowanie estetyczniej (nie wymaga nadmiarowego kodu) i jest zgodny z wszelkimi wytycznymi – nie działa w przy nawigacji klawiaturą IE6 (sic! żeby było ciekawiej IE6 wspomagany screenreaderem radzi sobie nieźle). Dlatego dla pełnej dostępności musimy się posłużyć dodatkowym elementem <a>.

I tu znowu czeka nas niespodzianka z hasLayout, ponieważ jeśli link docelowy nie znajdzie się w opakowaniu, które nada mu niejako layout (atrybutu hasLayout nie można modyfikować wprost) efekt będzie w IE 5, 6 i 7 (w 8 nareszcie poprawili) zbieżny z tym opisanym dla ID, czyli powrót na początek strony. Obszernej analizy problemu dokonał na swoich stronach Jim Thatcher. Przeanalizował pojawiające się rozwiązania pod kątem ich wpływu na zachowanie IE oraz innych przeglądarek oraz wykorzystywanych screenreaderów. Ja pozwolę sobie korzystając z doświadczeń Jim’a i własnych  pokazać zwycięzcę rywalizacji na najlepsze obejście problemu:

<span style="position:absolute;">
<a name="tresc" id="tresc">&nbsp;</a>
</span>

Span pozycjonowany absolutne ustawi nam hasLayout na upragnioną wartość true, dodatkowo wyciągnie element z biegu (flow) dokumentu dzięki czemu nadmiarowa spacja nie będzie miała wpływu na wygląd strony. Niełamliwa spacja sprawi, że element A jako niepusty nie zostanie zignorowany przez niektóre screenreadery (np. JAWS 8.0).

Posłowie

W ten sposób dzięki radosnym pomysłom programistów wiele osób zachodzi w głowę dlaczego nie działa poprawnie nawet na stronach wzorcowych (np. stronie głównej WAI), wiele osób ma materiał na nowe wpisy ;-) a na koniec webdeveloper generuje nadmiarowy kod tylko po to, by obejść problem w zanikającej w statystykach przeglądarce.