Opcje dostępności

Co ma wspólnego audyt WCAG z zapewnianiem dostępności

Opublikowano: , aktualizacja: 2022-04-07 przez

Wielokrotnie w mojej branży dochodzi do sytuacji, w której z różnych powodów trzeba zrezygnować z pewnych rzeczy w projekcie. Aspekt dostępności jest jednym z tych, które porzuca się najczęściej. Jak zatem zapewnić tą dostępność?

Niewygodny aspekt dostępności

Wielokrotnie w mojej branży dochodzi u klienta do sytuacji, w której z różnych powodów czy to budżetowych czy czasowych trzeba zrezygnować z pewnych rzeczy w projekcie. Aby produkt nadal był użyteczny i „dowieziony” na czas wyłącza się z realizacji pewne funkcjonalności lub wodotryski. Tam gdzie istnieje aspekt dostępności jest on jednym z tych tematów, które porzuca się najczęściej. Tyle, że niektórych klientów prawo i normy zobowiązują do zapewnienia dostępności, więc jakieś wymagania zaimplementować trzeba. Zaczyna się wtedy szukanie różnych rozwiązań ograniczających zakres prac.

Dostępność nie tylko dla wybranych

Jednym z podejść jakie kiedyś usłyszałem, aby ograniczyć dodatkową pracę jest pominięcie audytu i wybranie tych najbardziej istotnych, niejako najważniejszych wymagań do implementacji lub wybranie tych pod konkretny rodzaj niepełnosprawności.

Co to oznacza, że skupiamy się tylko tych najważniejszych wymaganiach i co oznacza, że wybieramy te które dotyczą największej grupy osób niepełnosprawnych?

Czy to ma oznaczać, że skupiamy się tylko na pierwszym poziomie dostępności, a może wybieramy te wymagania, które są uważane za top 10 popełnianych błędów? Czy bierzemy pod uwagę tylko osoby niewidome czy też może głuche, gdyż obie stanowią liczną grupę osób?

Jak widać próba odpowiedzi na te pytania generuje kolejne.

Dlatego od razu zaznaczam, nie jest to dobre podejście do tematu zapewniania dostępności. Osobiście nie rekomenduję takiego podejścia i uważam, że choć WCAG nie jest idealnym dokumentem to był konstruowany tak, aby nie pomijać żadnego z typu niepełnosprawności. Zatem jeśli ktoś chce pominąć jakieś wymagania, to musi to robić świadomie i z pełną odpowiedzialnością, za ewentualne wykluczenie pozostałych grup osób.

Nie ograniczaj dostępności przez widzi mi się

Jeżeli skupisz się na spełnieniu wymagań tylko dla jednej z grup osób lub ograniczysz się twoim zdaniem do tych „najważniejszych” wymagań wtedy:

  • wyjdzie to podczas audytu i żaden szanujący się audytor nie przepuści Ci takiej strony/aplikacji jako zgodnej z WCAG,
  • może to narazić klienta na ewentualne spory pomiędzy innymi użytkownikami, którzy zostali wykluczeni poprzez takie zawężenie,
  • będzie to jawne przekłamanie, gdyż klient nie będzie mógł powiedzieć, że jest w pełni dostępny, a w przypadku, gdy obowiązywać go będzie akt prawny, będzie to jawnym łamaniem prawa i dyskryminacją.

Ogranicza Cię kontent na stronie, a nie typ niepełnosprawności

Nie chcę, żeby to wybrzmiało jak stwierdzenie „wszystko, albo nic”, implementujesz standard albo zapominasz o certyfikacji, dlatego postaram przybliżyć Ci metodę, która pozwoli oszacować listę wymagań, jakie należy spełnić, bez narażania się na konsekwencje prawne.

Listę wymagań WCAG można ograniczyć w dwóch krokach:

  • Wykluczając 3 poziom dostępności, który nawet przez ustawodawców został potraktowany jako opcjonalny. Wtedy z całości 78 wymagań standardu WCAG 2.1 pozostaje nam 50.
  • Następnie ograniczając się do typu treści na stronie, można wykluczać te wymagania, których nie jesteśmy w stanie spełniać, gdyż nie posiadamy danego typu kontentu. Zasada prosta nie masz odpowiedniej treści na stronie np. audio/wideo to nie stosujesz tych wytycznych i nie testujesz treści z tymi wymaganiami.

Przykładem jest jeden z klientów, dla którego robiłem audyt. W wyniku analizy treści w aplikacji z 78 wymagań WCAG 2.1 mogłem ograniczyć się aż do 36 z nich za sprawą, że były tam same formularze.

OK, teraz dochodzimy do pytania, w stylu: „A czy tej listy nie można byłoby jeszcze bardziej skrócić?”

Oczywiście można, tylko to jest kastrowanie dostępności, a nie jej zapewnianie.

Spełnienie zaledwie kilkunastu wymagań WCAG nie zagwarantuje Ci dostępności

Nie dość, że spełnienie wytycznych WCAG z 1 i 2 poziomu, nie gwarantuje twojemu produktowi pełnej dostępności, to dodatkowo chcesz, aby już i tak krótką listę jeszcze bardziej skrócić. To tak jakby w twoim samochodzie dla przykładu wyjąć reflektory przeciwmgielne, czujniki parkowania oraz klimatyzację. Prowadzić się niby da, ale jak przyjdzie co do czego to z komfortem i z bezpieczeństwem nie będzie najlepiej. Podobnie jest z dostępnością. Możesz okroić wymagania na swój sposób, ale to nie zapewni Ci dostępnego produktu/usługi.

WCAG także nie gwarantuje Ci dostępności

Kolokwialnie przyjęło się, że strona zgodna z WCAG, to strona dostępna, ale tak naprawdę zbudowanie strony lub aplikacji w zgodzie z normą dostępności, będzie wskazywało tylko na zgodność z tą normą. Oczywiście zgodność z WCAG, jest dużym krokiem do posiadania dostępnej witryny, ale dostępność jest szerszym pojęciem obejmującym chociażby projektowanie uniwersalne/inkluzywne. Tak więc twierdzenie, że moja strona jest dostępna, bo spełnia WCAG nie jest do końca prawdziwe.

Certyfikacje dostępnej strony www

Po co zatem istnieją audyty i certyfikacje dostępnej strony?

Strona, która jest podawana audytowi przechodzi nie tylko testy dostępności, ale także użyteczności. To także testy z użytkownikami niepełnosprawnymi, a to nie tylko zerojedynkowe odpowiedzi w stylu: Przeszło / Nie przeszło, ale głębsza analiza np. zrozumiałości procesu i treści na stronie.

Audyt jest robiony właśnie po to, aby ocenić dostępność, a nie tylko zgodność z WCAG.

Pójdźmy dalej i postawmy kolejne pytanie.

Co jeśli nie potrzebujemy certyfikacji, czy nadal powinniśmy bawić się w audyty?

Na polskiej wersji GAAD (Global Accessibility Awareness Day) dotyczącej dostępności w Polsce1, jednym z prelegentów był Wojtek Kutyła. Powiedział wtedy, że powinniśmy zacząć więcej robić w kierunku zapewniania dostępności, niż tylko audyty WCAG. Na przykład skupić się na potrzebach użytkownika czy mikroagresjach jakie może wywołać używanie naszego produktu. Naturalnie w tej materii częściowo z Wojtkiem się zgadzam, ale audyty dostępności są jakby pokłosiem tego co właśnie robimy w tym kierunku.

Jeśli dla przykładu mamy projekt prowadzony od początku, nazwijmy to od „zera” czy to strony czy aplikacji, śmiało możemy tak powiedzieć. Tak, zacznijmy wdrażać dostępność tu i teraz, począwszy od badań i wywiadów z użytkownikami, kończąc na testach tudzież audycie.

Z drugiej strony w kontekście projektu już istniejącego jak przekonać klienta, aby zainwestował przepisanie interfejsu użytkownika uwzględniając aspekty dostępności. Musi być to poparte jakimś twardym dowodem. Takim dowodem jest właśnie raport z… audytu, przedstawiający listę popełnionych błędów. Tu nie ma czasu na badania, to ma być kompleksowe rozwiązanie, zabezpieczające biznes klienta przed pozwem sądowym. Poza tym taki audyt wcześniej czy później i tak będzie potrzebny, gdyż wynika to nie tylko z ewentualnej chęci posiadania certyfikatu, ale także zgodności z prawem m.in. europejskich dyrektyw EAA 2019/8822 i WAD 2016/21023 czy amerykańskiego ADA4.

Choć Wojtek w swojej wypowiedzi słusznie zauważył, że dostępność ma także swoje drugie oblicze, którego nie widać na pierwszy rzut oka, to niestety na tym pierwszym obliczu (czyli zgodności z prawem i WCAG) głównie skupią się audytorzy i osoby zapewniające dostępność. Realia są takie, że jakiemuś mało znanemu i zarobionemu administratorowi w ministerstwie, webmasterowi w urzędzie miejskim czy firmie dostarczającej usługi dla sektora publicznego, bardziej będzie zależeć na jak najszybszym wypuszczeniu produktu zgodnego z prawem i uniknięciu kary finansowej np. za brak deklaracji dostępności, niż „zmóżdżaniu” się co to jest np. intersekcjonalność5, która nie będę ukrywał dla mnie jest pojęciem kontrowersyjnym.

Jestem także zdania, że należy robić dostępność z dala od ideologii, a mam wrażenie, że właśnie do tematu dostępności próbuje się dorobić różnego rodzaju ideologie jak np. pojęcie: abelizmu, które dla mnie jest taką trochę nadbudówką na słowo dyskryminacja.

Subiektywność ocen audytora

Zarzut to może zbyt mocne słowo, ale na pewno istotną uwagą Wojtka był fakt, że spotkał się z wieloma ekspertami, którzy ciągle nawiązywali do WCAG.

Czy audytorem musi być koniecznie osoba ze sznytem UX lub doświadczony programista? Nie, to osoba mająca znać się na rzeczy. Czy zatem audytorem może zostać tester lub nauczyciel języka polskiego? Jeżeli dobrze ogarnia aspekt technologiczny, to dlaczego nie. Problem jest jednak w postrzeganiu co jest błędem dostępności, a co nim nie jest. Co dla jednej osoby będzie oczywiste, dla drugiej wcale być nie musi. Czy zgłoszony przez nauczyciela-audytora błąd będzie faktycznie błędem źle zaprojektowanego UI, czy może pewnego rodzaju „wydaje mi się, że to powinno wyglądać inaczej?”

Wychodząc na tą chwilę poza wcag, w związku z tym, że audytorem może być teoretycznie każdy, to każda z ocen tych osób może być bardzo subiektywna. Dlatego powstały metody ocen dostępności WCAG-EM czy RGAA, które są tak popularne i których użycie jest stosunkowo proste. Dlatego większość ekspertów wciąż do nich nawiązuje jako uniwersalne metody oceny dostępności.

Konkluzja

Pomijając aspekt prawny, ideologiczny i to jak podchodzimy do audytów, to mimo wszystko jest on jest dobrym sposobem na dość szczegółową cenę dostępności i nawet jeśli nie zdecydujesz się na certyfikację lub implementację wszystkich poprawek dostępności od razu, to będzie on dobrą podstawą do zrobienia strategii dostępności w firmie i zaplanowania działań na rzecz jej poprawy.

Osobiście także nie jestem zwolennikiem nadmiernej ilości audytów, bliżej mi to technik prowadzenia projektu w sposób zwinny, gdzie m.in. metoda „shift left”6 sprawdza się lepiej w zapewnianiu dostępności niż tona dokumentacji jaką jest po audytowy raport. Niestety czasami taki audyt będzie konieczny czy to ze względu, że wymaga od nas tego prawo, czy też jako „podkładka” dla firm składających ofertę na wykonanie oprogramowania, które ma być dostępne.

Reasumując

  • Audyt nie zapewni Ci dostępności, służy jedynie do jej oceny.
  • Audyty są i przez długi czas będą podstawą oceny dostępności – chociażby w sektorze publicznym.
  • Dobrze zrobiony plan audytu pozwoli Ci wykluczyć sporą ilość wymagań, co trochę zmniejszy nakład pracy.
  • Audyt dostępności prawie zawsze wiąże się z testami wymagań opisanych w WCAG lub użyciem metod bazujących na tym dokumencie
  • Nawet jeżeli nie jesteś audytorem tylko osobą odpowiedzialną za przetestowanie wymagań niefunkcjonalnych w tym wymagań dostępności, taki audyt pozwoli Ci na klarowną identyfikację błędów, które w późniejszym etapie krok po kroku można realizować w swoim backlogu.
  • Audyt w niektórych sytuacjach jest wymagany i zazwyczaj jest to uregulowane prawnie
  • Wyniki audytu pozwolą Ci na opracowanie strategii dostępności oraz będą pomocne podczas opracowywania deklaracji dostępności.
  • Zapewnianie dostępności rozpocznij od badań i wywiadów z użytkownikami niepełnosprawnymi, a zakończ na audycie także z ich uczestnictwem.
  • Realizację wymagań WCAG ograniczaj tylko poprzez pryzmat treści i funkcjonalności na stronie.
Logo Smyku.pl
smyku.pl
  • https://www.youtube.com/watch?v=q43jpIBxdh4
  • https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX%3A32019L0882
  • https://eur-lex.europa.eu/legal-content/PL/ALL/?uri=CELEX%3A32016L2102
  • https://www.ada.gov/regs2010/2010ADAStandards/2010ADAstandards.htm
  • https://pl.wikipedia.org/wiki/Intersekcjonalno%C5%9B%C4%87
  • https://www.deque.com/shift-left/

Zmień widoczność widżetów