Na jednym ze spotkań Izby Rzemiosła Dostępnościowego Rafał Charłampowicz zadał pytanie, które siedzi mi w głowie do dziś: czy ekran wprowadzania kodu PIN w iPhonie jest zgodny z WCAG?
Krótka odpowiedź brzmi: to zależy, jak na to patrzysz. Długa odpowiedź to cały ten numer.
Ekran, który niby łamie kryteria
Rafał zauważył, że teoretycznie ten ekran łamie kilka kryteriów sukcesu. A jednocześnie, gdyby naprawić je po kolei, zgodnie z dosłownym czytaniem przepisów, ekran stałby się gorszy w używaniu. Wolniejszy, bardziej zagracony, mniej przewidywalny.
I to nie jest dowcip ani wymówka. To jest codzienność pracy z WCAG, tylko zwykle nie mamy czasu się nad tym zatrzymać. Tym razem się zatrzymałem.
Bo pytanie Rafała nie dotyczy wcale iPhone’a. Dotyczy naszego odruchu. Kiedy widzimy coś, co nam się nie podoba, szukamy kryterium, pod które da się to podciągnąć. Czasem naprawdę trzeba. Czasem tylko chcemy mieć mocny argument.
WCAG tylko udaje precyzyjny zestaw reguł
Brzmi jak lista zero-jedynkowych testów. Spełnione albo nie. Pass albo fail. A w praktyce każda wersja WCAG to zbiór zdań, które trzeba zinterpretować, i to w konkretnym kontekście — interfejsu, użytkownika, sytuacji.
Do tego dochodzi model, który znamy z numeru o siedmiu odrzuconych kryteriach: starszych kryteriów się nie przepisuje, bo siedzą w przepisach i muszą zostać kompatybilne. Zamiast tego dokleja się nowe. Stąd nakładki, takie jak Przeciąganie (2.5.7) obok Gestów dotykowych (2.5.1), i stąd luki, które łatano kolejnymi kryteriami.
Kiedy pokazuję narzędzia, na przykład Wave Toolbar, zwracam uwagę na to, że kolor zielony nie oznacza wcale, że jest dobrze. Oznacza tylko tyle, że zostało zastosowane odpowiednie rozwiązanie. Tego rodzaju narzędzia mogą nam dużo powiedzieć o warstwie technicznej, ale praktycznie nic o funkcjonalności i użyteczności.
Weź 2.4.7 Widoczny fokus. Brzmi jednoznacznie. Ale słowo „widoczny” nie jest w specyfikacji zdefiniowane. Jeden dodatkowy piksel, który pojawia się przy fokusie, też jest „widoczny”. Kryterium przechodzi, a interfejs nadal jest fatalny w obsłudze klawiaturą.
Albo kontrast. 1.4.3 Kontrast (minimalny) wymaga 4,5 do 1. Wartość tuż poniżej progu nie przechodzi, wartość dokładnie na progu przechodzi. Wizualnie obie szarości wyglądają tak samo. Granice bywają linią narysowaną na piasku. A do tego dochodzi kwestia kroju i wagi czcionek w konkretnym zestawie kolorystycznym. Ciężkie czcionki wymagają mniejszego kontrastu, niż te zbudowane z nóg pająka. WCAG zresztą przewiduje to wprost: tekst duży, czyli co najmniej 18 punktów, a przy pogrubieniu co najmniej 14 punktów, wystarczy na poziomie 3 do 1. Tylko czy naprawdę to wystarczy?
Dlatego osoby zajmujące się audytami mogą w różny sposób interpretować dokładnie te same obserwacje. Tu nie jest tak, jak w dostępności architektonicznej, gdzie wiemy że szerokość wejścia w świetle ościeżnicy ma wynosić przynajmniej 90cm. Bierzemy miarkę i już wiemy. W cyfrowej dostępności takich parametrów jest jak na lekarstwo, a i tam pojawiają się poważne wątpliwości.
Aplikacja mobilna to inny świat
Tu wracamy do ekranu PIN-u, bo on nie jest stroną internetową. Jest ekranem systemu.
W numerze z marca pisałem o siedmiu kryteriach, które norma EN 301 549 wyłącza z oceny aplikacji mobilnych: 2.4.1 Możliwość pominięcia bloków, 2.4.2 Tytuły stron, 2.4.5 Wiele dróg, 3.1.2 Język części, 3.2.3 Spójna nawigacja, 3.2.4 Spójna identyfikacja i 4.1.3 Komunikaty o stanie. Nie dlatego, że dostępność w tych obszarach jest nieważna, ale dlatego, że te kryteria opisują wielostronicowy serwis w HTML-u. W natywnej aplikacji takich mechanizmów po prostu nie ma — albo przejmuje je platforma. Co nie oznacza, że należy te kryteria zupełnie olać, bo jednak warto o nie też zadbać, adaptując je do platformy. Wytknął mi to Mikołaj Rotnicki w komentarzu pod Dostępnikiem.
A ekran blokady jest jeszcze o warstwę wyżej, bo to system, nie aplikacja. Możesz go oceniać, możesz krytykować, ale pytanie „czy łamie WCAG” trzeba najpierw dobrze postawić. WCAG 2.x mówi o stronach internetowych, treści i komponentach. Zestaw, który opisuje, jak przenieść te wymagania na inne technologie, to WCAG2ICT, a aplikacjami mobilnymi zajmuje się Mobile Accessibility Task Force.
Szare strefy
Kilka przykładów, przy których naprawdę można się spierać. Znam je z audytów i z rozmowy Patricka H. Lauke’a i Petera Krautzbergera w odcinku Working Draft 718.
1.1.1 Treść nietekstowa. Wszyscy wiedzą, że obrazek potrzebuje alternatywy. Ale co jest dobrą alternatywą, zależy od kontekstu. Zdjęcie prelegenta z podpisem obok — dekoracyjne czy nie? Jeśli to zdjęcie mówiącego, a nazwisko jest w tekście obok, opis wyglądu nie wnosi nic nowego. Ale jeśli to zdjęcie slajdu z treścią, sytuacja jest odwrotna. To osoba audytująca musi samodzielnie zdecydować: przechodzi, czy nie przechodzi.
2.5.8 Rozmiar celu (minimum). Kryterium mówi o 24 na 24 piksele. Ale dopuszcza odstępstwa. Łącze wysokości jednego piksela, z wystarczającym odstępem, formalnie przechodzi. Formalnie. Jakościowo to katastrofa. I znowu decyzja jest po stronie osoby audytującej.
1.4.10 Dopasowanie do ekranu. Progi są bardzo konkretne: 320 pikseli CSS. A co z 319? Albo 321? Dlaczego właśnie ta liczba? Bo trzeba było jakąś wybrać. Rozumiem intencję, ale w praktyce audytowej rodzi to żarty i spory. I znowu trzeba zdecydować, gdzie postawić granicę.
Definicja strony. WCAG myśli jeszcze „stronami”. W aplikacji jednostronicowej, w widoku aplikacji mobilnej, w dynamicznie zmienianym ekranie to słowo przestaje pasować. WCAG 3 i metodyka WCAG-EM mówią już o widokach i ekranach. Tylko że w raporcie i tak trzeba napisać, co właściwie ocenialiśmy. A to też jest decyzja osoby, która ocenia.
Reguły rozstrzygania
Na podstawie wystąpienia Patricka H. Lauke’a These (still) aren’t the SCs you’re looking for — i jego rozmowy z Peterem Krautzbergerem w odcinku 718 — ułożyłem sobie kilka reguł na sporne przypadki. To moje sformułowanie, ale pomysły są z tej rozmowy, więc mówię, skąd je wziąłem.
Po pierwsze: nie naciągaj kryterium do swojego celu. Jeśli musisz długo tłumaczyć, dlaczego to jest akurat to kryterium, prawdopodobnie to nie jest to kryterium. Nie mów, że coś trzeba naprawić „żeby przejść WCAG”, jeśli normatywnie nie trzeba.
Po drugie: bądź zachowawczy w ocenie. Zarówno w zaliczeniach, jak i w błędach. Wpisywanie błędu tam, gdzie go nie ma, wygląda na mocną rekomendację, a jest ryzykiem.
Po trzecie: zapisuj wahanie. Wprost napisz, co jest twardym naruszeniem normy, a co tylko sugestią. Różnica między „naruszenie kryterium 1.4.3” i „rekomendacja wykraczająca poza WCAG” nie jest wstydem. Jest rzetelnością.
Po czwarte: pilnuj kaskad i par. Brak alternatywy tekstowej to nie tylko 1.1.1 — pociąga 4.1.2 Nazwa, rola, wartość, a czasem 2.4.4 Cel łącza (w kontekście). Brak języka strony oznacza automatycznie brak języka części. Kryteria minimalne i wzmocnione chodzą parami. Raportuj to spójnie, bo inaczej klient dostanie trzy błędy tam, gdzie jest jeden problem, albo odwrotnie — jeden, gdy są trzy.
Po piąte: pamiętaj, co jest normatywne. Objaśnienia i techniki są nienormatywne. Mają pomagać w interpretacji, a nie zastępować kryteria. I nie opiszą wszystkich możliwych scenariuszy, choćby dlatego, że ktoś wymyśli nowy.
Po szóste: nie udawaj sędziego. Audytor nie jest prawnikiem, choć jego ocena ma czasem wymiar prawny. Jeśli klient słusznie zakwestionuje jeden wpis, traci wiarygodność cały raport. Jeden naciągnięty błąd kosztuje więcej niż dziesięć uczciwie opisanych wątpliwości.
Co z tego wynika dla ekranu PIN-u
Tyle, że nie odpowiem Ci dziś prosto „zgodny” albo „niezgodny”. Bo najpierw trzeba ustalić, co właściwie oceniamy — ekran systemu czy aplikację, treść czy mechanizm platformy — a potem sprawdzić, czy kryterium w ogóle ma tu zastosowanie.
Jeśli jedynym powodem zmiany jest „żeby przeszło WCAG”, a po zmianie interfejs staje się gorszy w używaniu, to problem nie leży w WCAG. Leży w tym, jak go używamy. Najlepiej widać to na pytaniu Rafała: sprawny audytor potrafi tu powiedzieć „to nie jest naruszenie normy, ale warto to poprawić inaczej”, a nie „szukam kryterium, żeby to wpisać”.
Prace nad WCAG są publiczne
Nie musimy zgadywać, co autorzy mieli na myśli. Prace nad WCAG są otwarte: repozytorium to github.com/w3c/wcag, a otwarte i sporne tematy porządkuje WCAG 2 Backlog Project Board. Patrick Lauke prowadzi tam między innymi stronę interpretacji kryteriów i pokazuje, ile luk już udało się domknąć — a ile wciąż czeka. Jeśli trafisz na przypadek, który wygląda na niejasny, to jest miejsce na zgłoszenie. A jeśli po tym wszystkim chcesz jednak dopasowywać kryteria sukcesu do obserwacji, to pobaw się zaprojektowaną przeze mnie grą i daj znać, jak Ci poszło.
Wieści o dostępności
Świeży Working Draft WCAG 3.0. W tym tygodniu W3C opublikowało kolejną wersję roboczą WCAG 3. Najciekawsze: propozycja jednego poziomu zgodności, z dodatkowymi poziomami raportowania powyżej i poniżej. W3C prosi o opinie o tym modelu. Pamiętaj tylko, że to wciąż wersja robocza — WCAG 2.2 zostaje z nami na lata albo na zawsze. Podziwiam hart ducha piszących ten nowy standard, ale jest on tak skomplikowany, abstrakcyjny i jednocześnie trudny do zrozumienia, że jeżeli kiedyś wejdzie w życie, to zatęsknisz za starszymi wersjami.
Russ Weakley o atrybucie, którego nie słychać. Nowy artykuł na Max Design wyjaśnia aria-details — atrybut, który nie wciąga treści do opisu, tylko sygnalizuje, że szczegóły są gdzie indziej. Problem w tym, że wsparcie czytników ekranu jest szczątkowe: NVDA ma wsparcie eksperymentalne, JAWS ogłasza „has details”, a reszta milczy. Używać ostrożnie i nigdy jako jedynego nośnika informacji. Dodam od siebie, że to jest bardzo fajny atrybut, którego nigdy nie rekomenduję.
Ile masz stron internetowych? Sophie Count z Clearleft przypomina, że podmiot publiczny ma zwykle stronę główną, BIP, kilka subdomen i dwa zapomniane serwisy. Zanim zrobisz plan naprawy dostępności, zrób inwentaryzację. Bo deklaracja dostępności na „stronę” bywa deklaracją na jedną dziesiątą zasobu. Tak miałem kiedyś, gdy przygotowałem szkolenie dla NFOŚiGW. Poszukałem ich stron internetowych i pokazałem je podczas szkolenia. Ja znalazłem 10, a nie przykładałem się nadmiernie.
Rok egzekwowania EAA. Podsumowanie pierwszego roku po wejściu w życie Europejskiego Aktu o Dostępności pokazuje, że kary nie spadają z nieba z powodu kontroli urzędowych. Sprawy zaczynają się od skarg i pozwów. Ryzyko mierzy się więc liczbą niezadowolonych użytkowników, nie liczbą urzędników. Dlatego ponownie apeluję — zgłaszajcie problemy z dostępnością, bo bez tego nic się nie wydarzy. Ja na razie czekam na wynik mojego zgłoszenia problemów z mobilną aplikacją InPost.
Dostępny spektakl dla dzieci w MOCAK-u. Fundacja Kinematograf i Muzeum Sztuki Współczesnej w Krakowie MOCAK zapraszają na spektakl „Inaczej”, który MOCAK przygotował razem z Teatrem Figur Kraków. 24 września o 11.30, ul. Lipowa 4, dla dzieci od 6. roku życia z dorosłymi. Dzieła sztuki współczesnej poznaje się tam różnymi zmysłami: jest audiodeskrypcja, możliwość poznania sceny z bliska przed spektaklem i artystyczne tłumaczenie na polski język migowy. Po spektaklu warsztaty, osobne dla osób z niepełnosprawnością wzroku i osobne dla osób migających — i tak należy to robić, bo jedna wspólna grupa z tłumaczem obok to zwykle dostępność na papierze. Budynek jest dostępny architektonicznie, a zaproszenie w PJM jest nagrane na wideo.
I na koniec przypominam że odpaliłem zbiórkę na AutomaticA11y 2027. Oddzieliłem w ten sposób kawy dla mnie i na organizację wydarzenia. Zachęcam do wpłacania, bo inaczej będę musiał gościć Was za własne, a to może się nie spodobać Ewie. Dodatkową zachętą niech będzie to, że osoby, które zasilą budżet AutomaticA11y dostaną wcześniejszy dostęp do rejestracji. Nie umiem już wymyślić, jak mogę jeszcze namówić Cię do wyskoczenia z kasy.
I to by było na tyle. Rozważam zmianę nazwy mojego newslettera na Amerykański Dostępnik, ale jeszcze się waham. Nie umiem już traktować Trumpa poważnie, co jest niebezpieczne. Bo on ma możliwość zabijania ludzi na całym świecie i robi to dość często. Jest w tym niezwykle podobny do Putina, a podobieństw mogę znaleźć więcej. Na przykład aroganckie wywołanie wojny z mniejszym krajem i problem, żeby z tej wojny wyjść. Światem rządzą błazen i drapieżnik. A miliarderzy budują sobie schrony w Nowej Zelandii, bo przecież ich życie jest więcej warte, niż 8,5 miliarda innych. Żyjemy w złym świecie, więc przynajmniej my bądźmy dobrzy.
Jacek, tutaj mam poważny problem nie tylko z doborem słów, ale z samym tokiem rozumowania.
Piszesz o ekranie wprowadzania kodu PIN w iPhonie: „A ekran blokady jest jeszcze o warstwę wyżej, bo to system, nie aplikacja”. W kontekście całego tekstu nie jest to wyłącznie luźne techniczne dopowiedzenie. To rozróżnienie zostaje użyte przy zastanawianiu się, co właściwie oceniamy i czy konkretne wymagania dostępności mają zastosowanie.
I właśnie tutaj, moim zdaniem, pojawia się zasadniczy błąd.
„System” i „aplikacja” nie są przeciwstawnymi kategoriami. System operacyjny nie jest jednym monolitycznym programem, który bezpośrednio tworzy wszystkie ekrany widziane przez użytkownika. Składa się z jądra, sterowników, usług, bibliotek, procesów, aplikacji systemowych i innych komponentów. Tak jest w iOS, macOS, Windows, Linuksie i innych systemach.
Interfejsy, z którymi użytkownik rzeczywiście wchodzi w interakcję, są realizowane przez konkretne oprogramowanie. Apple samo mówi o „built-in apps” i „system apps”. Telefon jest aplikacją. Wiadomości są aplikacją. Ustawienia są aplikacją. SpringBoard, odpowiedzialny za znaczną część interfejsu iOS, również jest przez Apple określany jako aplikacja. To, że aplikacja lub komponent jest integralną częścią systemu operacyjnego, nie powoduje, że przestaje być oprogramowaniem czy aplikacją systemową.
Dlatego stwierdzenie „to system, nie aplikacja” tworzy fałszywą alternatywę.
Poprawne rozróżnienie mogłoby brzmieć: to nie jest ekran aplikacji zewnętrznej, lecz ekran interfejsu dostarczanego przez oprogramowanie systemowe iOS. To jednak zupełnie co innego.
I właśnie w kontekście dostępności ta różnica jest bardzo ważna.
EN 301 549 ma cały rozdział dotyczący oprogramowania niewebowego. Obejmuje między innymi platform software, czyli oprogramowanie platformy, oprogramowanie posiadające interfejs użytkownika oraz aplikacje mobilne. Systemy operacyjne są wprost przykładem platform software.
WCAG2ICT również wprost odnosi wymagania WCAG do oprogramowania, w tym do oprogramowania platformy i systemów operacyjnych.
Prawidłowe pytanie nie brzmi więc: „czy to system, czy aplikacja?”.
Prawidłowe pytanie brzmi: „który element oprogramowania tworzy ten interfejs, którą warstwę właśnie oceniamy i kto za nią odpowiada?”.
Jeżeli badam aplikację X, a ona uruchamia interfejs należący do iOS, mogę dojść do wniosku:
„Ten problem nie należy do aplikacji X, lecz do oprogramowania platformy iOS”.
To jest prawidłowe rozdzielenie odpowiedzialności.
Nie można jednak przejść od tego do:
„To system, a nie aplikacja, więc pojawia się pytanie, czy podlega takiej ocenie”.
Oprogramowanie systemowe również podlega wymaganiom dostępności. To, czy konkretny audyt obejmuje system operacyjny, jest zupełnie innym pytaniem dotyczącym zakresu audytu, zamówienia, produktu albo obowiązku prawnego.
„Nie znajduje się w zakresie tego audytu” nie oznacza „nie podlega wymaganiom dostępności”.
To rozróżnienie uważam za fundamentalne.
Mam też drugi problem z przykładem z PIN-em.
Nie uczestniczyłem w spotkaniu, na którym Rafał Charłampowicz przedstawił ten przypadek. Czasami uczestniczę w tych spotkaniach, ale akurat tej dyskusji nie słyszałem. Dlatego jako czytelnik artykułu chciałbym się dowiedzieć, co konkretnie Rafał uznał za problem.
Z tekstu dowiaduję się jedynie, że ekran PIN „teoretycznie łamie kilka kryteriów sukcesu” i że poprawianie go zgodnie z literalnym odczytaniem tych kryteriów mogłoby pogorszyć użyteczność.
Ale jakich kryteriów?
Co konkretnie na ekranie ma stanowić naruszenie?
Jakie zachowanie zostało zaobserwowane?
Dlaczego zastosowanie danego kryterium miałoby prowadzić do pogorszenia interfejsu?
Czy Rafał rzeczywiście twierdził, że ekran formalnie nie spełnia tych kryteriów, czy przedstawiał raczej przypadek problematycznej interpretacji?
Bez tych informacji osoba, która nie uczestniczyła w spotkaniu, nie ma możliwości zweryfikowania punktu wyjścia całego przykładu.
A przecież jest to tekst właśnie o tym, kiedy coś „przechodzi”, a kiedy „nie przechodzi”.
Dlatego taki przypadek powinien być moim zdaniem pokazany w prostym ciągu:
obserwowane zachowanie,
konkretne kryterium,
warunki zastosowania kryterium,
odpowiednia interpretacja WCAG2ICT lub EN 301 549,
wynik oceny.
Dopiero wtedy można uczciwie dyskutować o pass/fail.
Zgadzam się natomiast z ważną częścią Twojej ogólnej tezy: nie należy na siłę dobierać kryterium WCAG do każdego problemu z użytecznością. Użyteczność nie jest tym samym co zgodność z WCAG. Rekomendację wykraczającą poza normę trzeba odróżniać od formalnej niezgodności.
Ale właśnie dlatego przykład z PIN-em wymaga szczególnej precyzji.
Tym bardziej że w poprzednim tekście o nowej EN 301 549 sam słusznie zwracałeś uwagę na architekturę produktu i wymagania dotyczące oprogramowania. Tutaj natomiast cała złożoność tej architektury zostaje nagle sprowadzona do zdania „system, nie aplikacja”.
To jest bardzo daleko idące uproszczenie i, moim zdaniem, w tekście dotyczącym metodologii oceny dostępności może prowadzić do szkodliwych wniosków.
Podobnie jak przy mojej wcześniejszej uwadze dotyczącej siedmiu kryteriów wyłączonych dla aplikacji mobilnych: formalny zakres zastosowania konkretnego kryterium jest niezwykle ważny, ale nie oznacza, że potrzeba użytkownika znika, że problem przestaje być problemem dostępności albo że interfejs oprogramowania platformy znajduje się poza obszarem dostępności tylko dlatego, że jest elementem systemu operacyjnego.
Dlatego chętnie zobaczyłbym uzupełnienie tego przykładu o konkretne kryteria wskazane przez Rafała i dokładne rozumowanie prowadzące do wniosku o ich potencjalnym niespełnieniu.
Bo na razie przykład, który miał pokazać potrzebę ostrożnego stosowania kryteriów, sam opiera się na bardzo problematycznej klasyfikacji „system kontra aplikacja”. I właśnie tę część uważam za wymagającą zasadniczej korekty.