Artykuł „Strona internetowa dostępna dla każdego, czy to możliwe? Grzechy i grzeszki twórców stron internetowych”

Bardzo dobrze, że świadomość dostępności stron internetowych w Polsce stoi na coraz wyższym poziomie. To jednak sprawia, że pojawia się problem klęski urodzaju. Artykułów traktujących o dostępności zaczyna pojawiać się bardzo dużo, a tylko niektóre z nich są warte uwagi. Dzisiaj przyjrzę się artykułowi Strona internetowa dostępna dla każdego, czy to możliwe? Grzechy i grzeszki twórców stron internetowych, który ukazał się w serwisie dobreprogramy.pl.

  • Na sam początek warto zwrócić uwagę, że artykuł nie rozróżnia zasad i zaleceń WCAG od technik pozwalających je wdrożyć. Wszystko jest umieszczone pod hasłem zalecenia, co jest dość mylące. Ba, rzeknę więcej: artykuł niemal w całości skupia się wyłącznie na poszczególnych technikach, nie opisując niemal żadnej z zasad czy zaleceń.

    Dodatkowo, w żaden sposób nie wspomniano, że każde zalecenie jest przyporządkowane do odpowiedniego poziomu (A, AA lub AAA). Wrzucenie tego wszystkiego do jednego worka sprawia wrażenie, że stworzenie choćby ciut dostępnej strony staje się zadaniem tytanicznym.

    Nie można też nie wspomnieć, że dostępność sprowadzono wyłącznie do zgodności ze standardem WCAG, co jest dość niebezpiecznym uproszczeniem. Owszem, strony zgodne z tym standardem będą spełniać formalne wymogi dostępności, ale niekoniecznie będą używalne.

  • Jeśli już jednak skupiamy się wyłącznie na wytycznych WCAG, warto je podać i przyporządkować do konkretnych punktów. Inaczej zostajemy z zasadami, których nijak się nie da do niczego przyporządkować. I tak jest już z pierwszą zasadą: Materiały filmowe i interaktywne najlepiej gdy są umieszczone pod jednym adresem.

    Ne udało mi się dopasować żadnej techniki ani zalecenia ze standardu WCAG. Co więcej, nie bardzo widzę sens w upychaniu wszystkich materiałów interaktywnych na jednej podstronie. Owszem, grupowanie tematyczne brzmi sensownie – o nim jednak ta zasada całkowicie nie wspomina. Argument, że zgromadzenie ich na jednej stronie ułatwia nawigację po skomplikowanej witrynie, jest bardzo wątły. Jeśli witryna jest skomplikowana, wypada zacząć od uproszczenia jej. To równocześnie rozwiąże problem z nawigacją do filmów.

  • Kolejna zasada, Możliwość nawigowania po stronie za pomocą programu odczytu ekranu, poszła w złym kierunku. Nie wspomniano bowiem ani o semantyce kodu, ani o tzw. skip links. Co więcej, ta zasada jest w gruncie rzeczy redundantna w stosunku do innej zasady z tekstu:

    Strona powinna zawierać nagłówki, łącza, listy, ponieważ elementy te ułatwiają nawigację po stronie internetowej. Powoduje to , że użytkownik porusza się na podanej stronie szybciej, w porównaniu do strony nie mającej wyżej wymienionych elementów

    Poprawna obsługa czytnika ekranowego od autora strony w zasadzie wymaga tylko tego: właściwego używania elementów HTML, od czasu do czasu wspierania ich przy pomocy ARIA. Natomiast używanie [accesskey] jest w dużej mierze odradzane. Jak pokazuje MDN, skróty klawiszowe są niespójne pomiędzy przeglądarkami. To dodatkowo powoduje, że skróty do najważniejszych części strony mogą być niepotrzebnie udziwnione. Stąd poleca się skróty klawiszowe robić przy pomocy JS-a.

    I tu taka mała dygresja: W3Schools nie jest renomowanym źródłem informacji.

  • Kolejna zasada (Na stronie nie powinny pojawiać się elementy animowane, gdyż rozpraszają użytkownika) również nie ma odzwierciedlenia w standardzie WCAG. Standard ten o animacjach wspomina, niemniej nie zakazuje ich. Wymaga jednak, by istniała możliwość sterowania animacją.

    Co więcej, obecnie pojawiają się rozwiązania w CSS-ie, które pozwalają zareagować, gdy użytkownik nie życzy sobie animacji.

  • Kolejna zasada (Strona musi posiadać takie elementy, aby były one obsługiwane za pomocą klawiatury, a nie tylko z poziomu myszki.) jest źle opisana. Nie ma sensu sprawiać, żeby do każdego elementu strony dało się dotrzeć przy pomocy klawisza Tab. Tego typu nawigacja jest przeznaczona wyłącznie dla elementów interaktywnych. I tak też jest zdefiniowana w standardzie.

  • Zasada z odpowiednim kontrastem dla osób słabowidzących jest dobra… Niemniej nie mogę nie zauważyć, że umieszczenie w niej żółtego linku na białym tle jest co najmniej autoironiczne.
  • Jedna z kolejnych zasad (Serwis powinien dać się obsłużyć w urządzeniach, które mają wyłączoną obsługą CSS) jest źle opisana. Sugeruje bowiem, że czytniki ekranowe nie obsługują CSS-a, co jest nieprawdą. Najlepszym dowodem, że CSS rozumieją, jest ignorowanie elementów ukrytych przy pomocy display: none.

    Ta zasada w gruncie rzeczy ma motywować do pisania semantycznego kodu HTML. Dobrze zorganizowany, semantyczny HTML jest w stanie przekazywać treść nawet bez warstwy prezentacji. Ot, podstawy Progressive Enhancement.

  • Kolejna z zasad demonizuje tabele:

    Tabele – zmora niewidomych, ciężkie do nawigacji, paskudne, brzydkie.

    Stoi to w jawnej sprzeczności z technikami WCAG, które mówią wprost: do danych tabelarycznych należy używać tabeli.

Bardzo dobrze, że temat dostępności jest poruszany. Niemniej wypada go poruszać nieco dogłębniej, a nie całkowicie po łebkach.

10 myśli na temat “Artykuł „Strona internetowa dostępna dla każdego, czy to możliwe? Grzechy i grzeszki twórców stron internetowych””

  1. Cześć Comandeer. Zastanawiałem się ostatnio nad nawigowaniem po stronie za pomocą tabulatora używając :focus, kiedy mamy do czynienia, na przykład ze stronami typu onePage. Czytałem kilka Twoich uwag na ten temat kiedy poprawiałeś strony innych osób. Zaciekawiło mnie to na tyle, że poszperałem trochę by podpatrzeć jak robią to inni. Jeśli chodzi o focus to jest tak jak przeważnie wszędzie kiedy chodzi o dostępność, czyli dramat. Nawet taki bootstrap, tylu speców a nie jest to porządnie zrobione. Koniec końców skończyłem na Twojej stronie https://tutorials.comandeer.pl oraz na https://css-tricks.com/smooth-scrolling-accessibility i bardziej przemawia do mnie sposób od css-tricks. Rozumiem, że Twój sposób to dodanie ikonki oraz jej tekstowej etykiety, czyli „Bezpośredni link do sekcji” to jej nazwa, tak? Dlatego przy każdej jest taka sama? A nie lepiej byłoby to zrobić właśnie tak jak css-tricks? Ikonka z lewej strony, a nagłówek z prawej, który dzięki temu staje się jej tekstową etykietą. Wszak bardziej pasuje mi wtedy dodanie ikonki poprzez span a nie bezpośrednio jako hash w tagu a, ale nawet i ten sposób uważam, że jest w porządku. Jakby nie było nie mamy tutaj do czynienia z elementem interaktywnym, nigdzie nas to szczególnie nie przenosi a jest to po prostu element, który ma pomóc w nawigowaniu po stronie za pomocą tabulacji. Wiem, że nie powinno się tutaj zapominać o semantyce, ale nie ucierpi w tej sytuacji. Z kolei im więcej się zastanawiam, który sposób lepszy tym bardziej jestem w kropce. Podsumowując oba sposoby są dobre, ale ja wybrałbym ten od css-tricks. Co o tym sądzisz?

    1. Ale oczywiście, że jest to element interaktywny. I nie służy wyłącznie do polepszenia TAB-owania po stronie. Głównym założeniem, jakie przyświecało temu mechanizmowi, było po prostu umożliwienie zdobycia linka do konkretnej sekcji na stronie. W tym wypadku ten mechanizm niejako duplikuje zadanie spisu treści.

      W przypadku linków nie można mówić o tym, że elementy w otoczeniu nadadzą kontekst (to w gruncie rzeczy działa głównie przy obrazkach), ponieważ czytniki ekranowe (ale też część przeglądarek) ma opcję pozwalającą wyciągnąć wszystkie linki ze strony i zaprezentować jako listę. W tym wypadku tego typu linki, pozbawione kontekstu, są całkowicie bez sensu.

      Z tego też powodu obydwa rozwiązania są średnie. Dobre rozwiązanie powinno mieć pełną etykietę w linku, a równocześnie – mieć sens dla użytkowników, którzy posługują się myszką/klawiaturą. Być może coś typu a[aria-labelledby=id-naglowka]?

  2. No tak. Muszę przyznać, że masz racje. Takie linki są elementami interaktywnymi. Nigdy nie używałem czytnika ekranowego i do końca nie wiem jak to wygląda i czasami ciężko przewidzieć jak to będzie na takim czymś wyglądało. Jednym słowem rozwiązanie jakie prezentuje css-tricks jest nijakie. Sprawdzałem też bootstrapa i oni robią podobnie, tylko zamiast bezpośredniego hasha w linku dodają go za pomocą ::after i link zostaje pusty. To było moje poprzednie rozwiązanie:

    h2 class=”section__title”
    a class=”section__link” href=”#zespol” # /a
    Jakiś podtytuł
    /h2

    A dlaczego nie zrobić tego po prostu tak:

    h2 class=””
    a class=”section__title” href=”#zespol” Jakiś podtytuł /a
    /h2

    Mamy pełną etykietę w linku zamiast hasha czy sposobu z ikonką. Focus jest. Jeśli ktoś ma stronę typu one-page i się komuś nie podoba, że najeżdżając na taki tytuł zmienia się cursor na pointer to zamieniamy go na auto oraz wyłączamy domyślne właściwości CSS dla linku tak by wyglądał jak normalny tekst i wtedy graficznie jest ok i dla czytników ekranowych jest ok. Dlaczego nie tak?

    1. W sumie jest to jakieś rozwiązanie. Niemniej zastanawiam się, czy w przypadku, gdy – tak jak u mnie – jest też menu, które zawiera te wszystkie linki, tego typu linki przy nagłówkach nie są niepotrzebne.

      1. No też racja. Takie rozwiązanie duplikuje tak naprawdę link, który już istnieje w menu. Na pewno jest to lepsze rozwiązanie od tego hasha. Nie wiem, może takie coś by było lepsze:

        h2 class=””
        a class=”section__title” href=”#zespol” span class=”visuallyhidden” Drugi/Bezpośredni link do /span Jakiś podtytuł /a
        /h2

        Tutaj już nie duplikujemy. Informacja zostanie przekazana dla czytników ekranowych a ukryta dla normalnych użytkowników. W zasadzie ta cała sytuacja to sporna kwestia a rozwiązań też kilka, także ciężko będzie znaleźć konsensus.

  3. Comandeer jak coś to napiszę mejla jak znowu natchnie mnie jakaś nowa myśl, ale zapytam jeszcze tutaj, bo to w sumie będzie na temat tego o czym tutaj rozmawialiśmy. Jakby tak zebrać te wszystkie sposoby o których tutaj pisałem plus Twój z Twojej strony to co stoi na przeszkodzie by po prostu zrobić tak:

    <h2 class=”section__title” tabindex=”0″>Jakiś tytuł</h2>

    Wymusić focus za pomocą tabindex=”0″ i po sprawie, bez zabawy w linki czy ikonki. Odwiedziłem stronę w3c.org by poczytać czy są jakieś restrykcje odnośnie elementów do jakich można przypisać tabindex i nie znalazłem nic.

  4. Teraz to się już sam pogubiłem. Mam napisany już komentarz, ale w sumie przeczytałem jedno zdanie z Twojego poprzedniego komentarza i cały mój plan się posypał 🙂 Problem jest w tym, że ja rzeczywiście nigdy nie miałem możliwości zobaczyć jak działa taki czytnik ekranowy i stąd te moje pytania. Powiedz mi jak to mniej więcej wygląda? Jeśli mamy nawigację na stronie to ten czytnik grupuje i oddziela linki z nawigacji w jakieś osobne miejsce? Pójdźmy jeszcze do Twojej strony tutorials.comandeer.pl i tam do każdego tytułu przypisałeś link i dzięki temu można nawigować po stronie za pomocą klawisza tabulacji i jest link o nazwie „Bezpośredni link do sekcji” i czytnik takie linki też grupuje, zbiera i wyświetla jakoś w innym miejscu? To jak będą wyglądały Twoje linki? Będzie tylko wyświetlało „Bezpośredni link do sekcji” czy „Nasz cel” „Bezpośredni link do sekcji”?

    1. Raczej wyłącznie „Bezpośredni link do sekcji”, dlatego – jak mówiłem – to nie jest najlepsze rozwiązanie. Prawdopodobnie w ogóle się go pozbędę i zostawię samo menu.

  5. Ja stosuję takie:

    h2 class=”column__title”
    a class=”column__link” href=”#Kontakt” span class=”sr-only” Bezpośredni link do sekcji /span Kontakt
    /a
    /h2

    W css usuwam kursor i domyślne style dla tagu a. Tutaj już będzie link o nazwie „Bezpośredni link do sekcji Kontakt”

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

This site uses Akismet to reduce spam. Learn how your comment data is processed.