Zebrało mi się i postanowiłem napisać trochę o technologii ARIA. Zebrało mi się, bo wpadam co chwilę w osłupienie, w jaki sposób można jej użyć. I to wcale nie jest zachwyt, tylko to coś zupełnie przeciwnego. Postanowiłem zatem napisać znowu newsletter skierowany do programistów. Jeżeli nie jesteś w tej grupie, to też przeczytaj to może unikniesz robienia Cię w konia przez dostawców stron internetowych.
Czym właściwie jest ta cała ARIA?
Technologia ARIA (Accessible Rich Internet Applications) to zestaw standardów opracowanych przez W3C, które mają na celu ułatwienie dostępu do treści w internecie dla osób z niepełnosprawnościami. ARIA umożliwia tworzenie interaktywnych elementów na stronach internetowych, takich jak menu rozwijane czy formularze, które są łatwiejsze do obsługi dla osób korzystających z czytników ekranowych i innych technologii asystujących.
Dzięki wykorzystaniu ARIA, strony internetowe mogą stać się bardziej dostępne dla osób z różnymi rodzajami niepełnosprawności, takimi jak osoby niewidome, niedowidzące, z zaburzeniami poznawczymi czy ruchowymi. Przede wszystkim zaś dodaje semantyki do elementów, które domyślnie nie są w nią wyposażone. Dodaje też różne stany możliwe do odczytania. Są to na przykład stany “rozwinięte”, “naciśnięte”, “częściowo zaznaczone” i wiele podobnych. Tego wszystkiego nie da się zrobić tylko za pomocą HTML.
Korzyści i zagrożenia
Korzyści wynikające z wykorzystania technologii ARIA są oczywiste - ułatwienie dostępu do treści w internecie dla osób z niepełnosprawnościami. Dzięki temu osoby te mogą korzystać z internetu w sposób bardziej samodzielny i pełny.
Zagrożenia związane z ARIA wynikają głównie z niewłaściwego stosowania tej technologii. Niedostatecznie przemyślane i zaprojektowane elementy interaktywne mogą wprowadzać zamieszanie i utrudniać korzystanie z serwisów internetowych, zwłaszcza dla osób korzystających z czytników ekranowych. Dlatego ważne jest, aby projektanci i programiści byli świadomi zasad stosowania ARIA oraz korzystali z niej z umiarem.
ARIA z zasadami
Autorzy ARIA zrozumieli, że ARIA może być doskonałym narzędziem, a jednocześnie okropnym psujem. Dlatego w opisie tej technologii zawarli kilka bardzo podstawowych zasad jej używania. Posłużę się nimi, ale dołożę praktyczne przykłady z życia wzięte.
Brak ARIA jest lepsze niż zła ARIA
To jest ta najbardziej podstawowa zasada, zalecająca daleko idącą ostrożność. To wcale nie jest tak, że im więcej atrybutów ARIA nawrzucamy do kodu HTML, tym strona będzie bardziej dostępna. To nie sernik, do którego wrzucasz rodzynki bez opamiętania. To nie jest moja intuicja, ale badania przeprowadzane co roku przez WebAIM na próbce miliona stron. Tu możesz przeczytać raport z tego badania, z którego wynika, że im więcej ARIA, tym więcej błędów dostępności.
Trafiły ostatnio w moje ręce takie strony, na przykład nowiutka strona Urzędu Miasta Drawsko. Tam właśnie nasypali aż 371 takich rodzynek już na stronie głównej.
A co właściwie robi tam ARIA? Najwięcej rodzynek jest z gatunku aria-label. To taki atrybut, za pomocą którego można dodać etykietę tekstową do elementu, do którego inaczej tego się nie da zrobić. Tu jednak pojechali po całości i wprost złamali zasady stosowania ARIA, bo tego atrybutu nie należy stosować, gdy etykieta tekstowa jest widoczna! Gdybyż się zatrzymali na podmienieniu etykiety z sensem, to jeszcze dałoby się przymknąć oko. Tu jednak prostą etykietę łącza Kontakt zamienili na Kliknij aby przejść do strony. Kontakt. Kliknij aby przejść do strony. Kontakt dymek. Nawet nie wiesz jak to boli przy używaniu czytnika ekranu. Zrób zresztą eksperyment i podmień sobie te łącza wizualnie, czyli zamiast Kontakt wstaw tego tasiemca. I szablon robi to automatycznie, bo przecież tyle rodzynek jest super.
Przypisanie roli jest zobowiązaniem
Atrybuty ARIA miały służyć do tego, by wyłatać braki w semantyce strony tworzonej w czasach, gdy wszystko było niesemantyczne. Dlatego dla jakiegoś elementu można było przypisać rolę i poinformować dostępnościowe API, że to coś jest przyciskiem, polem edycyjnym czy jakimkolwiek innym. Rzecz jest banalnie prosta, ale to zobowiązanie… Jeżeli nadasz jakiemuś elementowi rolę przycisku, to musi się zachowywać jak przycisk! A to wcale już takie proste nie jest. Na ile to jest trudne i niepewne, możesz obejrzeć w tym filmie.
Na wspomnianej wcześniej stronie zrobione jest coś podobnego, ale… Ten pseudoprzycisk został usunięty z obsługi klawiaturą. A zatem po co w ogóle było to robić?
ARIA może ukrywać lub wzmacniać
Przyjrzyjmy się teraz dwóm atrybutom ARIA. Ten ukrywający to aria-hidden, a wzmacniający to aria-live. Źle użyte mogą poważnie zaszkodzić dostępności.
Atrybut aria-hidden służy do ukrywania elementu przed technologiami asystującymi. Taki element po prostu wylatuje z drzewa dostępności i koniec. Dość często spotykam się z sytuacją, gdy jest dodany do łączy prowadzących do mediów społecznościowych. Długo nie wiedziałem, skąd taki dziwny zabieg, aż oświecił mnie Piotr Osipa. Wszystko przez bibliotekę ikonek Font Awesome, która pozwala na pobranie kodu do wklejenia na swojej stronie, żeby wyświetlić konkretną ikonkę. Sęk w tym, że domyślnie w kodzie jest właśnie atrybut aria-hidden, co wyrzuca tę ikonkę z drzewa dostępności. A jeżeli ktoś użył jej do opisania łącza, to dało właśnie taki efekt.
Nie wiem, co stało za tym, że automatycznie dodawany był ten atrybut. Efekt jest jednak taki, że na ogromnej liczbie stron internetowych występuje właśnie taki problem, że do społecznościówek nie da się dojść przy użyciu czytnika ekranu lub nawigacji głosowej. Mam w swoich przeglądarkach skryptozakładkę, która usuwa ten atrybut ze strony, dzięki czemu mogę jej normalnie używać.
Z kolei aria-live ma bardzo potrzebną rolę, wskazaną w kryterium sukcesu 4.1.3 WCAG. Element z tym atrybutem ma szczególną właściwość, że jest stale monitorowany. Gdy cokolwiek zmieni się w treści tego obszaru, jest automatycznie odczytywane użytkownikowi. Przykładem może być koszyk w sklepie internetowym. Kiedy kliknę na dodaj do koszyka, w miejscu wyświetlania koszyka pojawia się komunikat w rodzaju produkt dodany lub coś w tym guście. Użytkownik korzystający z czytnika ekranu lub dużego powiększenia może ten komunikat przeoczyć, a wtedy kliknie jeszcze raz, bo nie ma pewności, czy dodał ten produkt, czy też nie. No i ma 2 lub więcej sztuk tego samego produktu. Atrybut aria-live rozwiązuje ten problem w sposób zupełnie automatyczny.
Wygląda to bardzo dobrze, ale zawsze można to zrobić źle. Tu właśnie dochodzimy do problemu wzmocnienia. Jeżeli dodasz ten atrybut do elementu, który często się zmienia, możesz uniemożliwić pracę niewidomemu użytkownikowi. Bo będzie słyszał bez przerwy komunikat statusu, ale nie będzie mógł przeczytać zawartości strony. I to wcale nie jest problem wymyślony! Kiedyś taki efekt był na Youtube, gdy wysyłałem film na kanał. Pasek postępu z procentami gadał cały czas i do pracy mogłem wrócić dopiero, gdy plik się załadował. A mogło to trwać długo. Drugim przypadkiem była aplikacja do samospisu, w której czas na wprowadzenie danych był ograniczony bodajże do 30 minut. Tylko że na 5 minut przed końcem status zmieniał się co sekundę i trudno było cokolwiek zrobić z tym fantem.
Stosuj ARIA tylko wtedy, gdy nie da się inaczej
Ta reguła wychodzi z poprzednich kawałków tekstu niemal automatycznie. Warto jednak to wyraźnie powtórzyć - jeżeli jest inny sposób, to zrezygnuj z ARIA. Tym bardziej, że wiele rozwiązań z ARIA włączono do HTML 5 i stały się one zbędne. Takim atrybutem wypartym jest aria-required, który można zastąpić zwykłym required. Jest to oczywiście atrybut wskazujący, że pole formularza jest obowiązkowe. Podobnie stało się z landmarkami, które można sobie odpuścić, bo są przecież obszary w HTML. Tu możesz zobaczyć porównanie obu technik. Takich zmian jest całkiem sporo, więc pamiętaj - zawsze lepiej użyć znaczników i atrybutów HTML, niż ARIA.
To mam w ogóle nie używać ARIA?
No nie… Tego bym nie sugerował. ARIA daje jednak pewne możliwości, których sam HTML nie dostarczy. Dzięki ARIA możesz zbudować aplikację webową na wypasie, w tym z kontrolkami których próżno szukać w HTML. Jednak musisz to robić z umiarem i rozsądkiem, a przede wszystkim z wiedzą, co właściwie robisz. No i nie syp tych rodzynek do sernika, bo nie od tego jest sernik.
Czasem możesz nawet nie wiedzieć, że używasz ARIA i to może być problem. Biblioteki w rodzaju Bootstrap mają w sobie już wstawione atrybuty ARIA dla różnych kontrolek. Zazwyczaj jest to przemyślane, ale dla standardowych rozwiązań. Trochę jak z tymi ikonkami Awesome, bo użyte jako ozdobne grafiki mogą być ukryte, ale już jako linki - nie mogą. Tak więc sięgnij po Wave i zwróć uwagę na fioletowe ikony. Czy ich użycie ma sens? Czy można to zrobić technikami HTML? Co one tu do cholery robią? Ja ich przecież nie wstawiałem!
Gdzie się tego nauczyć?
Myślę, że pierwszym źródłem powinny być materiały od W3C. Zacznij od wprowadzenia, żeby mieć ogólną wiedzę. Potem zajrzyj do wskazówek dla deweloperów, a tam już wzorce do wykorzystania, wyliczanie dostępnych nazw i wiele innego dobra. A jak znajdziesz ciekawe źródełka - podziel się z innymi, w tym ze mną.
Polecanki
Teraz kilka polecanek z mojego dostępnościowego światka. Na początek drugi odcinek podcastu od Fundacji Katarynka. Jest tam mowa między innymi o przedprzewodniku. Stefan Wajda mocno rekomenduje Bibliotekę Liderów Dostępności, gdzie znajdziesz ponad 100 materiałów poświęconych dostępności. To już faktycznie nie jest biblioteczka, tylko Biblioteka!
Wielkimi krokami zbliża się kolejna edycja Global Accessibility Awareness Day. Przypominam więc, że jest już pierwsza oficjalna impreza związana z tym dniem. Jeżeli wiesz o innych, daj mi proszę znać. Może i ja coś przygotuję, chociaż nie obiecuję.
No i to chyba na tyle w tym numerze. Jeżeli Ci się spodobał - podziel się nim z innymi. Życzę Ci nadejścia wiosny, przejścia w tryb krótkiego rękawka i radości. A Ukrainie życzę jak najszybszego zwycięstwa.
Jacku,
w kwestii polecanek, a w szczególności informacji o imprezach z okazji GAAD.
Tego dnia, 18 maja w Poznaniu odbędzie się już piąte, i do tego rocznicowe po roku działaności spotkanie Poznań a11y Meetup.
Pozdrawiam z Poznania
Henryk