Blog UX – user experience. Psychologia w IT, marketing, testy A/B

W Polsce 12,2% społeczeństwa (danie z 2012 roku) jest w jakimś stopniu niepełnosprawna (z orzeczeniami jak i bez orzeczeń o niepełnosprawności). Dane zostały zebrane za pomocą ankiety więc istnieje ryzyko niedoszacowania owej liczby. Osoby niepełnosprawne generują 2 biliony dolarów rocznie na całym świecie (według UXPAInternational).

Co za tym idzie przed nami rysuje się profil, dodatkowa persona, która będzie stanowiła jakiś odsetek naszych użytkowników. Dlatego na początek musimy poznać naszego użytkownika, by w rezultacie zaproponować rozwiązanie. Warto również pamiętać, że część zasad WCAG nie jest oczywista i łatwo implementowana. Stąd niezbędne jest wyczucie i zrozumienie użytkownika. Z jednej strony nie możemy przepalić milionów godzin na dostosowywanie aplikacji a z drugiej nie możemy jej kompletnie pominąć ponieważ będzie miało to negatywne skutki w odbiorze rozwiązania.

71% użytkowników z niepełnosprawnościami opuści Twoją stronę lub rozwiązanie gdy będzie im sprawiało problem osiągniecie celu (według Click-Away Pund Survey). Oczywiście tego typu deklaracje trzeba wziąć w duży nawias. Moje doświadczenie w e-commerce pokazuje, że nawet najgorsza strona internetowa posiadająca genialną ofertę (np. zdecydowanie niższe ceny niż konkurencja) będzie miała pokaźną ilość klientów. Jeżeli użytkownik ma dużą korzyść mankamenty w użyteczności są mniej istotne. Jednakże, jeżeli na rynku jest porównywalna oferta, wtedy owa użyteczność będzie miała kluczowe znaczenie.

Z jakimi niepełnosprawnościami możemy się spotkać?

Wzrokowe

  • Problemy z dostrzeganiem kolorów oraz kontrastów
  • Problemy z dostrzeganiem szczegółów oraz małych elementów
  • Brak wzroku

Słuchowe

  • Szumy
  • Infekcje
  • Ograniczone zdolności
  • Brak słuchu

Motoryczne

  • Ograniczone możliwości poruszania rękoma (kończynami)
  • Ruchy ciała przeszkadzające w koordynacji związane z różnego rodzaju schorzeniami (drgawki, fiksacje itp.)
  • Brak poszczególnych kończyn

Inne

  • Przewlekła senność
  • Problem ze skupieniem uwagi (np. ADHD)
  • Bóle głowy oraz migreny
  • Różne spektrum autyzmu
  • Depresja
  • Nerwica
  • Niedorozwój
  • Padaczka, epilepsja itp.

Ciekawostka: Warto również dodać, że uwzględnienie metod UX oraz WCAG pomoże w dość typowych sytuacjach. W przypadku niskiego stanu baterii ekran przygasa, co może przypominać problem z niedowidzeniem. Opieka nad niemowlakiem, może powodować problemy ze skupieniem. Słoneczny dzień może powodować problem z odróżnianiem kolorów. Wiele codziennych sytuacji sprawa, że od czasu do czasu zdarzają nam się pewne ograniczenia, z którymi każdego dnia zmagają się osoby niepełnosprawne.

Co to jest WCAG?

Web Content Accessibility Guidelines (WCAG) czyli Wytyczne dotyczące dostępności treści internetowych. Jest to zbiór zasad pomocnych przy tworzeniu serwisów internetowych, aplikacji oraz rozwiązań informatycznych. Od 2012 roku standard WCAG stał się normą ISO/IEC 40500:2012. 21 lutego 2019 polski sejm przyjął ustawę ustawę o dostępności cyfrowej stron internetowych i aplikacji mobilnych. Co sprowadza się do tego iż strony publiczne muszą spełniać kryteria dostępności dla osób niepełnosprawnych. WCAG dzielimy na trzy poziomy, które oznacza się: A, AA, AAA. Gdzie A oznacza najbardziej podstawowe wymagania, za to AAA najwyższy poziom wymagań względem rozwiązania (a tym samym najtrudniejszy w implementacji).

4 główne zasady WCAG

  1. Dostrzegalność – prezentowane elementy, powinny być widoczne dla wszystkich odbiorców. Szczególnie zwraca się tutaj uwagę na: alternatywne teksty “alt”, transkrypcje do wideo oraz audio oraz kontrast pomiędzy tekstem, a obszarem znajdującym się za nim.
  2. Interaktywność – elementy interfacu powinny umożliwiać wchodzenia z nimi w interakcje. Ta zasada powinna umożliwiać wykonanie zadań wyłącznie za pomocą klawiatury (Tab), bez dostępu do myszy czy trackpada, hiperlinki powinny być jasno opisane oraz oznaczone, a użytkownik powinien mieć odpowiednią ilość czasu na wykonanie zadań.
  3. Zrozumiałość – elementy rozwiązania nie powinny budzić wątpliwości (używamy języka zrozumiałego dla wszystkich), wprowadzać w błąd (powinny dokładnie opisywać dany element) oraz czytelne (piszemy zwięźle oraz konkretnie, nie lejemy wody).
  4. Rzetelność – tworzenie rozwiązania powinno być spójne i dokładne, ponieważ różne nakładki czy czytniki mogą błędnie interpretować niespójny kod. Zwróćmy uwagę na dynamiczny rozwój różnych typów urządzeń. Dbanie o kod jest istotne ponieważ niebawem mogą pojawić się nowe rozwiązania technologiczne, które powinny rozumieć naszą witrynę czy rozwiązanie.

WCAG z perspektywy roli w organizacji

Rola w organizacji będzie definiowała odmienne podejście oraz zadania względem wymogów WCAG.

  • Graficy/Designerzy – Opracowują warstwę wizualną z uwzględnieniem ograniczeń użytkowników. Ich rola będzie najbardziej widoczna i to ten zespół powinien posiadać dużą świadomość wymogów WCAG. Braki w wiedzy czy pominięcie zasad WCAG na etapie projektowania ekranów, może skutkować dużymi kosztami (redesign) lub problemami użyteczności.
  • Twórcy treści – Twórcy treści w kontekście WCAG posiadają dość jasne zasady, które bywają łatwo implementowane. Ważne jednak by mieć z tyłu głowy profil klienta, do której owa treść będzie skierowana. Tworzenie treści do kilku zasad WCAG jest proste. Tworzenie treści dostosowanej do odbiorcy jest dużo bardziej wymagającą umiejętnością, która może stanowić o powodzeniu jakiegoś produktu.
  • Deweloperzy – Odpowiadają za implementacje poszczególnych ekranów oraz rozłożenia treści. Ich umiejętności opisywania elementów powinny być czymś naturalnym aby na etapie testów wprowadzać jak najmniej zmian. Deweloperzy mogą być dodatkowymi strażnikami wytycznych WCAG na etapie implementacji.
  • Testerzy – Tutaj moim zdaniem sytuacja się komplikuje. W przypadku testerów możemy poza wiedzą, posiłkować się różnymi wtyczkami. Niestety poszczególne wtyczki mogą wskazywać błędy np. implementacji atrybutu “for” jednakże nie wskażą gdzie dokładnie powinien się znaleźć, lub gdzie występuje błąd w jego implementacji. Co za tym idzie wskazywanie rozwiązań dla danego błędu może być bardzo trudne. Idealnym byłby tester ze znajomością HTML oraz CSS oraz bogatą wiedzą na temat zasad WCAG.

Baza wymagań WCAG

Skrócona instrukcja – znajdziesz tam pełną bazę wytycznych WCAG, z podziałem na role w zespole, które wymieniłem powyżej. Filtrowanie jest proste, a instrukcja aktualizowana. Jest to podstawowe narzędzie służące do weryfikacji założeń WCAG.

WCAG Quick guide

  1. Zakładka o nazwie zawartość. W skrócie baza wiedzy. Zawierają się pod nią wszystkie wytyczne z podziałem na 4 główne zasady. Tutaj jesteśmy w stanie prześledzić dokładne wytyczne dla każdej heurystyki.
  2. Ekran główny mający na celu prezentowanie treści.
  3. Zakładka filtrowania, jedna z bardziej przydatnych rzeczy w naszej instrukcji. Zawiera wiele różnie powiązanych kategorii naszych wymagań.
  4. Rozwijane menu wersji WCAG. Za jego pomocą możemy zdefiniować z jakiego zbioru wytycznych chcemy korzystać. Najnowszym na ten moment jest 2.1 i rekomenduję korzystać z niego, celem weryfikacji założeń.
  5. Sekcja tagów, podstawowy podział jest zgodny z rolami. Możemy zdefiniować odpowiednią rolę względem naszych potrzeb. Brakuje sekcji tester? Tak brakuje ponieważ tester powinien ogarniać całość 🙂
  6. Tagi luźno powiązane. Interesują nas jakie zasady dotyczą captchy? Rozwijamy sekcję chmurki tagów i szukamy. Mamy tam tagi, które w różny sposób wiążą poszczególne wymagania.
  7. Poziomy. Tutaj definiujemy z jakiego poziomu wytycznych chcemy korzystać. Zanim przystąpimy do realizacji projektu powinniśmy zdefiniować standard według którego pracujemy. Niekiedy zbyt wysoki standard może nałożyć zbyt wysokie wymagania i radykalnie wpłynąć na koszt realizacji projektu.
  8. Techniki to filtr pozwalający na edytowanie wyników danych wytycznych. Jeżeli nie chcemy przykładów porażek, to odklikujemy. Chcemy rady jak naprawić błąd dotyczący tego wymagania klikamy w Advisory.
  9. Ostatni filtr dotyczy bezpośrednio technologii, wybieramy technologie, które nas interesują.

Najczęściej występujące błędy WCAG

  1. Zbyt mały kontrast
  2. Problem z podświetleniem elementów gdy używamy TABa
  3. Brak lub kiepskie teksty alt
  4. Mało znaczące linki
  5. Problem z responsywnością tekstu

Jak testować strony pod kątem WCAG?

Etap 1: Na początek upewnij się, z jakich przeglądarek korzystają Twoi użytkownicy. Sprawdź za pomocą Google analytics. Niektóre rozwiązania czy style mogą nie być obsługiwane przez daną grupę odbiorców.

Etap 2: Weryfikacja dostępności za pomocą klawiatury. Czy masz dostęp do wszystkich funkcjonalności? Czy jesteś w stanie zrealizować scenariusze testowe wyłącznie za pomocą klawiatury? Co przysparza Ci problemy?

Etap 3: Wykorzystaj narzędzia online. Miej również na uwadze, że część programów będzie zwracała błędy tam gdzie ich nie ma (będą wskazywały za mały kontrast, bo nie będą rozumiały rozłożenia poszczególnych elementów), ale również części błędów nie wykryje. Pamiętaj również, że większość wskazówek w wersji 2.1 jest możliwe do testowania wyłącznie manualnego.

Etap 5: Wszystkie strony, które sprawiały problemy oraz takie które znaleźliście jako kluczowe dla poszczególnych procesów przefiltruj ręcznie. Zweryfikujcie kod, a najlepiej sprawdźcie je z listą kontrolną, którą dodaje na końcu artykułu.

Lista kontrolna WCAG

WCAG lista kontrolna [PDF]

WCAG 2.1 najnowsze zmiany

WCAG co pewien czas jest rozszerzany o dodatkowe elementy. Biorąc pod uwagę zmianę naszych zachowań w oparciu o nowe urządzenia np. interafce głosowe, ekrany dotykowe, VR itp. trzeba stale aktualizować listę rekomendacji aby nadążała za urządzeniami i postępem.

Najnowszą wersją jest wersja 2.1 która przynosi zmiany w postaci:

Zmiany dla urządzeń mobilnych

  • Zwrócenie uwagi na gesty (dotyk)
  • Zwrócenie uwagi na możliwość nie intencyjnego uruchomienia sensorów urządzenia np. puknięcie w ekran, ściśnięcie boków telefonu itp.

Zmiany w kontekście niedowidzenia

  • Rozszerzenie wymagań kontrastu dla grafik
  • Zwrócenie uwagi na responsywność tekstów oraz designu rozwiązań

Zmiany w kontekście lepszego zrozumienia

  • Rekomendacja lepszego i szerszego opisywanie elementów służących do kontroli celem obsłużenia coraz bardziej zaawansowanych możliwości edycji i dostosowania paneli czy rozwiązań

Zmiany w kontekście standardów europejskich EN 301 954

  • Zunifikowanie norm względem EN 301 954

Typ od psychologii i IT, czyta w ludziach by wiedzieć więcej o stronach www.

View Comments

There are currently no comments.
Next Post