Kurs dostępności – EduWeb.pl

Nie tak dawno temu na EduWeb pojawił się kurs poświęcony dostępności. Nie skłamię, mówiąc, że to najbardziej wyczekiwana recenzja na WebKrytyku od bardzo dawna. Sporo osób pytało mnie, czy zrobię recenzję. No więc zrobiłem…

Z kronikarskiego obowiązku muszę odnotować, że Wojtek, autor kursu, jest moim znajomym. Nie miało to jednak żadnego wpływu na ocenę samego kursu.

  • Bardzo podoba mi się fakt, że już na samym początku kursu jest powiedziane, że dostępność dotyczy wszystkich osób, a nie tylko tych z niepełnosprawnościami. Jedyne, co warto byłoby tu dopowiedzieć, to fakt, że obecnie coraz częściej w tym kontekście mówi się o inkluzywności, nie dostępności. Sama dostępność wydaje się obecnie być ograniczona do implementacji założeń inkluzywności. Niemniej to już mocno teoretyczna dyskusja, która na naszym rodzimym podwórku prawdopodobnie toczyć się będzie dopiero za kilka lat.

  • Kolejnym plusem jest powiązanie semantyczności HTML-a bezpośrednio z dostępnością. Semantyka dla samej siebie często wydaje się bezcelowa. W kontekście dostępności brzmi o wiele sensowniej.

  • Bardzo podoba mi się skupienie na aspekcie tzw. chwilowej niepełnosprawności. To w bardzo obrazowy sposób tłumaczy, dlaczego dostępność jest istotna dla każdego użytkownika. Zwłaszcza, że chwilowe niepełnosprawności dotyczą różnych użytkowników w różnym czasie.

  • Ogólnie pierwszy segment kursu bardzo przypomina mi moje własne rozważania nad dostępnością.

  • Przydałyby się w kursie jednak źródła dla podawanych statystyk, np. liczby osób z wadami wzroku w Polsce.

  • Jeśli chodzi o sekcję poświęconą czytnikom ekranowym, wypada dopowiedzieć kilka rzeczy.

    Po pierwsze, JAWS ma licencję próbną, można go używać za darmo przez 40 minut. Następnie trzeba zrobić restart systemu i mamy kolejne 40 minut.

    Nie widzę też za bardzo powodu, dla którego w kursie jest używany ChromeVox zamiast VoiceOvera. ChromeVox jest, niestety, mimo wszystko mocno prymitywnym czytnikiem. VoiceOver o wiele lepiej oddaje to, jak działają czytniki ekranowe typu NVDA czy JAWS. No i warto od razu zaznaczyć, że ChromeVox w postaci rozszerzenia do Chrome’a nie jest już rozwijany:

    Please note that this extension is now in maintenance mode; no new additions will be made moving forward.

    [Należy zauważyć, że to rozszerzenie nie jest dłużej rozwijane; nie pojawią się już nowe funkcje.]

    Ostatecznie różnice między czytnikami są na tyle subtelne, a równocześnie na tyle duże, że i tak wypada sprawdzić przynajmniej w trzech najpopularniejszych (NVDA, JAWS, VoiceOver). A to i tak bez wliczania czytników na urządzeniach mobilnych.

  • Niektórych z wymienionych narzędzi nie znałem, jak np. WhoCanUse. A szkoda, bo to naprawdę fajne narzędzie, pokazujące przy okazji, po co dbać o odpowiedni kontrast kolorów na stronie.

  • W przypadku Chrome’a od pewnego czasu można włączyć już w devtools zakładkę poświęconą dostępności, w której wyświetlać się będzie drzewko dostępności. Informacja o tym, że jest to tylko w Firefoksie jest już więc nieco nieaktualna. Ale muszę się zgodzić, że w Firefoksie działa to o wiele lepiej.

    Niemniej ostatnio w Chrome pojawiły się także narzędzia do symulacji różnych typów wad wzroku. Niestety, kurs był najprawdopodobniej nagrywany pod koniec 2019 roku i tego typu nowości go ominęły.

  • Nie wiem, czy przypadkiem w sekcji o najczęstszych błędach (a zwłaszcza o niepoprawnych [alt]) nie dzieje się nieco za dużo, np. tworzymy prosty layout strony, żeby pokazać dobre praktyki związane z [alt]. Osobiście zmieniłbym koncepcję tego segmentu kursu i faktycznie pokazał błędy na już istniejącym organizmie (czyli np. gotowa strona z obrazkami z błędnymi [alt]), który będzie poprawiany.

  • Co do linków bez kontekstu, sprawa nie jest taka oczywista. Zgodnie z normą WCAG, linki bez opisowej nazwy są dostępne, jeśli ich rola wynika z kontekstu. Kontekst w tym wypadku oznacza otaczający fragment tekstu. Czytniki ekranowe zazwyczaj mają skróty klawiszowe do czytania całego akapitu, w którym znajduje się aktualnie sfocusowany element.

    Nie zmienia to jednak faktu, że choć formalnie jest to rozwiązanie zgodne z normą dostępności, to osobiście uważam je za o wiele gorsze rozwiązanie niż próba faktycznego zawarcia kontekstu w samej treści linka.

  • Przy określaniu języka strony pojawił się pewien błąd (jest obecny też w teście po tym segmencie kursu): w atrybucie [lang] podaje się kod języka, nie kraju. Kodów krajów używa się do dookreślenia, o jaką odmianę języka chodzi, np. en-US (amerykański angielski) czy pl-PL (polski używany w Polsce; akurat w przypadku naszego języka nie ma to większego sensu, bo jest używany tylko w Polsce).

  • Bardzo duży plus za zauważenie, że piksele blokują skalowanie tekstu w przeglądarce! Najczęściej ten problem się pomija, z powodu istnienia całościowego powiększenia w przeglądarce – a jak dla mnie całkiem niesłusznie.

  • Bardzo ciekawe jest to, że ChromeVox nie czyta tekstu, który jest przezroczysty. Powinien, ponieważ opacity w żaden sposób nie wpływa na to, w jaki sposób ten element jest prezentowany w drzewku dostępności. Zarówno NVDA, JAWS, jak i VoiceOver, ten tekst czytają. Nieczytanie przezroczystego tekstu to po prostu bug ChromeVoxa.

    To także powoduje, że odpowiedź na jedno z pytań w teście po tym segmencie jest niepoprawna.

  • W lekcji odnośnie dodatkowych informacji dla czytników ekranowych są nieco mieszane czytniki ekranowe z usługą tłumaczenia strony przez Chrome. To są całkowicie inne mechanizmy, a bug z nietłumaczeniem [aria-label] został już naprawiony. Niemniej zostało to naprawione tylko w Google Chrome, w innych przeglądarkach może dalej nie działać. Natomiast to, w jaki sposób to działało w kursie, wynika po raz kolejny z bugów ChromeVoxa.

  • Przedstawiony w kursie wskaźnik focusu przy pomocy koloru tła czy obramowania nie jest sam w sobie do końca dostępny. Informacja o tym, że element jest zaznaczony, jest przekazywana wyłącznie przy pomocy koloru. Nie jest to jednak aż tak dotkliwe w tym wypadku, ponieważ czytnik ekranowy odczyta stan wprost z elementu input, natomiast dla innych użytkowników jest informacja w postaci „ptaszka” w checkboksie.

  • Bardzo ciekawy był fragment poświęcony dostępności i SEO. Chociaż osobiście wątpię w to, by jakieś narzędzie na chwilę obecną faktycznie stosowało wymienione własności ze Schema.org.

Ogólnie jestem mocno pozytywnie zaskoczony jakością tego kursu. Nie było to nudne odhaczanie WCAG, jak w niektórych innych kursach dostępności, ale faktyczne pochylenie się nad problemem i próba wyjaśnienia sensu dostępności. Choć zdarzały się w kursie potknięcia i niezrozumiałe decyzje (jak ten nieszczęsny ChromeVox), to i tak stanowi on porządne wprowadzenie do tematyki dostępności oraz punkt wyjścia do dalszego zgłębiania tematu – właśnie przez to podejście skupione na tłumaczeniu po co.

Mimo to brakowało mi tam nieco więcej informacji o innych typach niepełnosprawności. Większość uwagi skoncentrowana została na wadach wzroku. Ten ChromeVox też mnie boli, bo fakt jego użycia wygenerował kilka błędów w treści kursu. Gdyby go podmienić na VoiceOvera, to byłoby niemal idealnie. A tak jest po prostu dobrze.

16 komentarzy do “Kurs dostępności – EduWeb.pl”

  1. Dziękuję Ci Tomku za dokładny przegląd i opinię.

    Odniosę się do kilku kwestii, tak dla pełności kontekstu i uzasadnienia niektórych decyzji/efektów końcowych w kursie.

    Co do JAWS – szczerze mówiąc, nie jestem biegły w czytnikach ekranowych na system Windows, bo po prostu z tego systemu na co dzień nie korzystam – fajne uzupełnienie, jeśli ktoś mnie o to spyta to teraz na pewno odpowiem rzetelniej 🙂

    Moja decyzja co do ChromeVox była prosta – jest w miarę multi-platformowy, wystarczy Chrome/Chromium. Dzięki czemu w niektórych firmach, w których miałem okazję pracować, developerzy mieli możliwość jakiegokolwiek testowania dostępności, niezależnie od tego czy pracowali na Ubuntu/Windows/MacOS. Wszyscy mogli wziąć udział w jednym „szkoleniu” dot. czytników ekranowych. Tutaj kierowałem się podobnym rozumowaniem, możliwość uruchomienia tego samego czytnika ekranowego niezależnie od platformy była kluczowym powodem, dlaczego wybrałem ChromeVox.

    Sam co dnia używam VoiceOvera, ale jest to czytnik specyficzny dla urządzeń Apple. Niestety nie wiem z jakiej platformy korzystać mogą widzowie. Faktycznie, szkoda że ChromeVox jest już niewspierany i ma wymienione przez Ciebie bugi. Mam nadzieję, że jeśli ktoś zarazi się ideą tworzenia dostępnych stron, nie zamknie się tylko na jedno narzędzie i będzie testował też na innych czytnikach 🙂

    Być może w kolejnych kursach poruszę też inne kwestie projektowania inkluzywnego – jest to ogromny temat – ale zależy to też od popytu widzów na tą tematykę. Dla zainteresowanych, pracuję nad platformą/blogiem, budowaną z uwzględnieniem konceptów takich jak prywatność, wydajność czy dostępność (chociaż w tym momencie, treści są dostępne jedynie w języku angielskim). Link umieszczam w odpowiedniej sekcji komentarza.

    Na pewno będę wspominał o tym wpisie jako o uzupełnieniu treści dostępnych w kursie, gdy będę go gdzieś promował – dziękuję i wszystkiego dobrego!

  2. Tomku, bardzo Ci dziękujemy za opinię, zwłaszcza, że zdajemy sobie sprawę, że tak przychylne recenzje nieczęsto pojawiają się na łamach Webkrytyka.

    Nie chcemy przypisywać sobie zasług Wojtka – to on zrobił kawał świetnej roboty, przygotowując rzetelnie cały kurs, także raz jeszcze dla niego ogromne podziękowania. Cieszymy się, że poziom naszych materiałów stale rośnie, a kolejne osoby które tworzą kursy na eduweb.pl to czołowe postaci polskiej sceny, które są gotowe dzielić się wiedzą i dawać innym wartość.

    Przypominamy, że także dla Ciebie zaproszenie do tworzenia treści pozostanie aktualne – kto wie, może kiedyś uda nam się coś wspólnie stworzyć? 🙂

    Pozwolimy sobie umieścić Twoje cenne komentarze bezpośrednio w kursie, oznaczając Cię jako autora, tak aby jeszcze zwiększyć jego wartość.

    Z pozdrowieniami,
    Grzegorz Róg
    eduweb.pl

  3. Brakuje mi kursu lub książki która uczyłaby JavaScript od podstaw ale w najnowszej wersji EcmaScript 11. Wiem zaraz ktoś mi powie, to naucz się zwykłego JavaScript, a potem doucz się EcmaScript6 i nowszego standardu. Niestety robi się z tego taka partyzantka i nowi adepci tego języka mają przez to złe praktyki. Tu trochę nauki JavaScript stąd, tam trochę nauki EcmaScript6+ stąd i robi się z tego taki kocioł i mały chaos, pomieszania z wymieszaniem wiedzy. Sądzę, ze taka książka, biblia który od razu uczy podstaw JavaScript w połączeniu z najnowszym stabilnym standardem EcmaScript 11 wystarczyłaby na kilka lat. Niestety nikt się nie kwapi aby stworzyć taką książkę…

    Pozdrawiam serdecznie Kamil Nowak!

    1. Osobiście to nie rozumiem tego podziału na „normalny” JS i „ten nowy”. Ten nowy nie jest normalny? To, że taki podział faktycznie występuje w książkach i kursach, jest IMO szkodliwe dla tego, jak się postrzega JS jako język.

      1. Nie wiem skąd wziąłeś ten „normalny”, ale ja nic takiego nie napisałem. Gdyby nowe książki dla początkujących uczyły najnowszego ES11, tak jak jest w książkach Javy, gdzie wychodzi Java 14 i wiemy że uczymy się tej wersji. To wtedy nauka takiego TypeScript nie byłaby potrzebna. Tak to nowy adept nie wie czy uczyć się od razu JavaScript czy TypeScript. Sam nie wiem czy porzucanie JavaScript na rzecz TypeScript ma sens, czy to tylko nie chwilowa moda na język Microsoftu?

        1. No właśnie, dzielisz JS na wersje. A JS nie ma wersji jako tako. Wersje są tylko w standardzie, żeby w jakiś sensowny sposób rozwijać ten język. Na gruncie przeglądarek JS to po prostu zbiór ficzerów i różne silniki JS obsługują różny zakres ficzerów, bez patrzenia na wersję ES. Nowe książki powinny uczyć po prostu JS-a w postaci takiej, w jakiej język się obecnie znajduje, bez wyszczególniania wersji.

          Jedyne miejsce, w którym widzę sens mówienia o ES6 jako nowym JS-ie, to wyjaśnianie, dlaczego nagle mamy const i let zamiast var itd.

          Przy okazji, ES6 to ostatnia wersja standardu, którą określa się przy pomocy numeru wersji. Kolejne wersje standardu określa się przy pomocy roku wydania (czyli obecnie mamy ES 2020).

          1. Niestety polskie książki na temat JavaScript wydane w 2020 uczą jedynie wersji ES6, nie ma w nich nowości z ES11. Teraz na helionie dużo książek wychodzi do TypeScript i zastanawiam się czy znając podstawy podstaw JavaScript ucząc się go dalej, czy pójść w TypeScript? Główny administrator popularnego forum dla programistów 4programmers zmienił język PHP na TypeScript. Do tego dochodzi coraz bardziej popularne środowisko uruchomieniowe Deno jako konkurencja dla Node napisana w bezpiecznym Rust.

          2. Deno to na tę chwilę ciekawostka, nie realna konkurencja dla Node’a. Największym minusem jest brak kompatybilności z istniejącym ekosystemem npm-a. Brak managera pakietów może Deno po prostu zabić.

            TypeScript to po prostu JS z typami i nieco bardziej rozbudowanymi mechanizmami obiektowości klasowej. Więc można spokojnie poznać go obok JS-a, bez konieczności porzucania jednego na rzecz drugiego.

          1. Na backend polecasz jakiś framework do Node? Z nowych jest NestJS i AdonisJS. Takie połączenie z VueJS na frontendzie będzie dobrym wyborem na początek dla fullstacka?

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.