Dostępnik o nazwie, roli i wartości we WCAG

WCAG ma takie kryterium sukcesu z numerkiem 4.1.2. Jak wiele innych - to kryterium jest dla wielu osób niejasne. A to właśnie ono jest kluczowe dla programistów.

Gorąco mi i sapię przy pisaniu. Jeżeli znajdziesz w tym numerze literówki, lub co gorsza - błędy ortograficzne - wybacz. Staram się, bo temat wybrany przez użytkowników Linkedin jest trudny i ważny. Wybrali temat dotyczący kryterium 4.1.2 WCAG, które dotyczy nazwy, roli i wartości komponentów interfejsu użytkownika.

W przestrzeni społecznej funkcjonuje mit, że WCAG to dokument dla informatyka, cokolwiek to znaczy. Tymczasem tyle w tym prawdy, co w stwierdzeniu, że lekarstwa są dla lekarza. Kiedyś wreszcie zrobię tę tabelkę z podziałem ról w cyfrowej dostępności, a na razie uwierz mi na słowo, że praca redaktora treści jest równie istotna, co programisty i znajdziesz to wyłożone w WCAG. Jednak faktycznie w wcag jest zasada, wytyczna i kryteria sukcesu skierowane właśnie do programistów.

Zasada 4: Solidność.

Twórz treści solidnie, aby mogły być skutecznie interpretowane przez różne programy użytkownika, w tym technologie wspomagające.

Wytyczna 4.1 Kompatybilność

Zapewnij jak największą zgodność z aktualnymi i przyszłymi programami użytkownika, w tym z technologiami asystującymi.

Przyznaj, że to wszystko brzmi jak coś dla programisty. A w środku tej wytycznej 3 bardzo techniczne kryteria sukcesu: poprawność kodu, informowanie o zmianie statusu i właśnie nazwa, rola, wartość. Dlatego ten Dostępnik jest raczej dla osób technicznych, ogarniających graficzne interfejsy użytkownika. Postaram się jednak napisać to najprościej, jak umiem.

Nazwa

Każdy element interfejsu musi mieć dostępną nazwę. Jest to zazwyczaj krótki tekst informujący technologie asystujące, a zatem także użytkownika, jaki jest cel istnienia w interfejsie. Może to trochę górnolotnie, ale przyznaj że przycisk bez informacji, do czego służy nie ma wielkiego sensu.

Dostępna nazwa może być widoczna lub nie. Jeżeli jest widoczna, to nazywamy ją etykietą. I jeżeli to jest faktycznie etykieta tekstowa, to niczego już z nią nie rób, a zwłaszcza nie protezuj jej atrybutem aria-label. Tego wprost zabrania specyfikacja ARIA. Etykietą może być tekst łącza, który może kliknąć użytkownik. Mogą to być etykiety dla pól formularzy, a nawet legenda do grupy elementów formularzy.

Często jest tak, że dostępne nazwy są niewidoczne dla ludzi, a za to są widoczne dla technologii asystujących. Grafiki mają atrybut alt, a ARIA dostarcza kilku atrybutów do dodawania dostępnych nazw: aria-label, aria-labeledby, aria-describedby. Nośnikiem dostępnej nazwy może być także atrybut title. Teraz może pojawić się w Twojej głowie pytanie - a co będzie, jak tych nazw będzie kilka? Która będzie tą prawdziwą?

Odpowiedzią jest wyliczanie dostępnej nazwy za pomocą dokładnego algorytmu. Ten algorytm wygląda strasznie i łatwo się w nim zgubić. Przedstawię go w 3 punktach i pamiętaj, że to tylko uproszczenie, żeby nie złamać mózgu.

1. Atrybuty ARIA nadpisują naturalne dostępne nazwy. Używaj ich z umiarem.

2. Jeżeli atrybuty ARIA nie nadpisują, to dostępna nazwa jest brana z naturalnego źródła, czyli atrybutów alt, label oraz znaczników label, legend i wielu innych.

3. A jak niczego nie można znaleźć, to przeglądarka sięga do atrybutu title. To jest porażka programistyczna, więc raczej unikaj takich sytuacji.

Na koniec jeszcze ostatnie, a za to ważne uwagi. Nazwa powinna być unikalna, bo inaczej nie spełni pokładanej w niej nadziei. Link o treści “czytaj więcej” z wielu powodów jest słaba. Nazwa musi być programowo powiązana z elementem interfejsu. Używając znacznika label powiąż go mocnym sznurkiem z polem tekstowym, do którego się odnosi.

Rola

Przez te 30 lat istnienia Internetu i 40 lat istnienia graficznego interfejsu użytkownika (GUI) trochę się nauczyliśmy. Wiemy jak używać stron internetowych, aplikacji mobilnych i tych na komputerze. A to wszystko dlatego, że poszczególne elementy interfejsu różnią się między sobą wyglądem. Nawet jeżeli nie potrafisz fachowo nazwać jakiegoś elementu, to zazwyczaj umiesz go używać. Ale właściwie to skąd wiesz, że konkretnego elementu używa się tak, a nie inaczej? Może zatem na przykładach.

Wyszukiwarka to bardzo popularny komponent na stronach internetowych. Zazwyczaj składa się z 2 elementów: pola edycyjnego i przycisku. Każdy wie, że w pole edycyjne należy wpisać wyszukiwany tekst, a w przycisk należy kliknąć. Nikt nie robi odwrotnie, bo to nie zadziała. Wynika to z faktu, że oba elementy mają określoną rolę w interfejsie, a zatem zaprogramowane w przeglądarce i naszych mózgach zachowania. Taki przycisk rozpoznasz po tym, że jest prostokątny, a do tego troszkę jest taki trójwymiarowy. Na nim jest napis lub grafika. Aż się prosi, żeby kliknąć. Z kolei pole tekstowe to taka ramka z migającym kursorkiem, zachęcającym do wpisania czegoś z klawiatury.

Podobnych komponentów znamy bardzo dużo: pola wyboru, pola opcji, rozwijane listy, zakładki, suwaki, drzewa i całe mnóstwo innych. Jednak zawsze wiesz, jak ich użyć. No chyba że ktoś kreatywny wymyślił coś innego, żeby zmylić przeciwnika, czyli Ciebie. Generalnie wiesz, że tu trzeba kliknąć, tam wpisać, owdzie przesunąć, przeciągnąć i upuścić, rozwinąć itp.

Język HTML dostarcza dość dużo takich kontrolek. Ich zachowanie jest zgodne z oczekiwaniami, a równocześnie są cyfrowo dostępne. Mając pole tekstowe z etykietą Szukaj masz pewność, że to wyszukiwarka. Chyba starczy tych przykładów i teraz kolej na to, jak zepsuć ten wspaniały świat. Oczywiście przez programistów.

Tak długo, jak programista używa natywnych kontrolek, na przykład z HTML lub biblioteki graficznej, problemu nie ma. Pole edycyjne ma przypisaną rolę, a programista musi tylko dołączyć etykietę tekstową, czyli dostępną nazwę. Czasem jednak programista wymyśla własną kontrolkę, która ma zastąpić taką natywną. W tym miejscu nie mogło zabraknąć tego filmu:

Ja wiem, że długi i naszpikowany technicznymi pojęciami. Jednak ilustruje problem, jaki pojawia się w sytuacji, gdy programista robi własne komponenty. Musi zadbać o każdy element interakcji, w tym zdefiniowanie roli, obsługi myszą i klawiaturą, odpowiedniej animacji. Po prostu musi sam zrobić to, co za niego mogłaby zrobić przeglądarka, gdyby użył zwykłego przycisku.

Czasem jednak jest tak, że HTML nie dostarcza odpowiedniej kontrolki. Wtedy można sięgnąć po ARIA, ale dopiero wtedy. Bo ARIA - jak sama nazwa wskazuje - służy do tworzenia bogatych aplikacji, a nie prostych stron. No i wtedy zaczyna się zabawa, jak w filmie powyżej.

Kiedyś na Twitterze przeczytałem bardzo fajny tekst, chociaż autora nie pomnę. Brzmiał on mniej więcej tak: Jeżeli coś wygląda jak przycisk i działa jak przycisk, to jest to przycisk. To jest kwintesencja opisu, czym jest rola w rozumieniu WCAG. Ja jednak napiszę to w kilku punktach.

1. Rola elementu powinna być zgodna z jego wyglądem. Jeżeli wygląd sugeruje, że to jest pole do wstawienia ptaszka, to rolą musi być checkbox.

2. Jeżeli możesz użyć komponentu HTML - użyj go. Zastępowanie go rolą ARIA jest złym rozwiązaniem.

3. Nie powielaj ról, nawet jeżeli są takie same. HTML wciąż się rozwija i coraz więcej znaczników się pojawia, wypierając ARIA.

4. Jeżeli korzystasz z gotowego komponentu lub samodzielnie go programujesz, upewnij się że użytkownik będzie mógł go użyć.

Wartość

To chyba najprostszy kawałek tego kryterium sukcesu. Technologie asystujące muszą mieć możliwość odczytania wartości, stanu i właściwości komponentu interfejsu. Weźmy kolejny przykład, jakim jest rozwijane menu. Co technologie asystujące powinny wiedzieć o elemencie menu? Muszą znać nazwę, rolę (menu-item) i to trzecie. Element menu może być rozwinięty lub nie. Może być aktywny lub nie. O te wszystkie informacje należy zadbać, w tym przypadku za pomocą ARIA.

W tym tygodniu badałem pewną stronę internetową, której dostępność była pod psem. Za to dostarczyła mi autentycznych przykładów do zilustrowania. Miała bowiem 2 zakładki, jedną dla informacji o globalnej firmie, a drugą o polskim oddziale. Działało to jak trzeba, poza jednym - technologie asystujące nie dostawały informacji, która zakładka jest wybrana. Zaznaczone były obie, chociaż wizualnie było inaczej. Na tej samej stronie był mechanizm do zmieniania kafelków z aktualnościami. Do przewijania służyły 2 przyciski. I wszystko działało, ale z niezrozumiałego powodu przycisk wstecz był oznajmiany jako nieaktywny, chociaż działał. Wizualnie przyciski się nie różniły. Ktoś dodał właściwość bez sensu i pewnie nawet tego nie zauważył.

Jeszcze ostatni przykład do zilustrowania. W formularzu jest pole do wpisania adresu email. Pole jest obowiązkowe. Co o nim musi wiedzieć technologia asystująca?

1. To jest pole tekstowe służące do wpisania adresu email. Jest taki typ elementu input i w tym kontekście warto go użyć.

2. Musi mieć nazwę, czyli trzeba dodać etykietę (widoczną) za pomocą znacznika label. Technologie asystujące nie widzą, że etykieta jest przy tym polu, więc musisz jakoś je ze sobą połączyć programowo.

3. Wreszcie technologia musi wiedzieć, że pole jest obowiązkowe. Oznacz je gwiazdką, ale dodaj jeszcze atrybut required, żeby technologie nie musiały się domyślać.

Sporo tego i mam wrażenie, że jakoś prosto nie udało mi się tego wyjaśnić. Zawsze możesz jednak obejrzeć drzewo dostępności, tworzone przez przeglądarkę internetową. Ja najbardziej lubię do tego używać przeglądarki Firefox. Po naciśnięciu klawisza F12 pojawiają się narzędzia deweloperskie dotyczące dostępności.

Mam prośbę do Ciebie - napisz w komentarzu, czy napisałem to jasno. Wiesz jak jest… Czasem rzeczy oczywiste dla mnie trudno mi przełożyć na prosty komunikat.

Wieści o dostępności

Monika Szczygielska przygotowała listę z mikrowykładami do kawy. Już wspominałem o tej inicjatywie, bo bardzo mi się podoba ta inicjatywa z pigułeczkami wiedzy. Dowiesz się sporo o napisach, języku migowym, tekście łatwym do czytania. Krótka forma pozwala na szybkie poznanie tematu, ale zgłębić go musisz już samodzielnie. Zajawka jest super.

Adam Pietrasiewicz z Ministerstwa Cyfryzacji zaprasza do obejrzenia i skrytykowania narzędzia, które zaprojektował. Jest to elektroniczna wersja listy sprawdzającej dostępność aplikacji mobilnych. Aplikacja podpowie co zbadać i w jaki sposób, a na końcu wygeneruje raport. Z krytyką pisz do Adama, a nie do mnie.

Anna Żórawska zaprasza do współtworzenia tegorocznej edycji Festiwalu Kultury bez barier. W październiku odbędą się liczne wydarzenia, w których możesz wziąć udział. A tutaj informacje dla zainteresowanych.

Jeżeli potrzebujesz środków na zapewnienie dostępności w kulturze, to może zainteresuje Cię ogłoszenie o naborze. Minister Kultury i Dziedzictwa Narodowego chce dofinansować dostępność w ramach programu FEnIKS.

Dla przedsiębiorców jest kolejny nabór, także na wdrażanie dostępności. Mogą to być badania, wdrożenia. Projekt musi się wpisywać w przynajmniej jedną krajową inteligentną specjalizację. Nie wiem co to jest, więc rozkminianie pozostawiam Tobie.

Wojtek Kutyła zaprasza na UX wieczorową porą. Wydarzenie się przesunęło, więc mogę o tym poinformować. Audycja będzie na żywo 11 lipca o godzinie 19:00 polskiego czasu. Nie umiem wyjaśnić, o czym jest ten program, więc wpadnij i obejrzyj. Można też pisać na chacie.

I to by było na tyle. Lato w pełni i to coraz gorętsze z roku na rok. Pewnie w grudniu znowu jakiś geniusz od ekologii zrobi zdjęcie śniegu na dachu samochodu, udowadniając że nie ma żadnego ocieplenia. Musimy zadbać o naszą planetę, bo uciec z niej będą mogli nieliczni, którzy już budują dla siebie rakiety. Pomyśl o tym proszę.