Pomoc kontekstowa powinna dotyczyć aktualnie wykonywanej operacji lub obsługiwanej kontrolki formularza. Ten rodzaj pomocy znamy z systemów operacyjnych, gdy kliknięcie w znak zapytania powoduje wyświetlenie dodatkowych informacji.

Kryterium sukcesu 3.3.5 zaleca, by zaoferować użytkownikowi pomoc kontekstową, jeżeli same etykiety są niewystarczające. Skorzystają na tym:

  • użytkownicy z ograniczeniami kognitywnymi,
  • seniorzy,
  • użytkownicy nie znający specyfiki serwisu.

Pomoc kontekstowa może przybrać postać linku dowiązanego do kontrolki formularza, po kliknięciu którego wyświetlane są dodatkowe informacje. Taka pomoc kontekstowa jest niezbędna, gdy sama etykieta nie wystarcza do pełnego zrozumienia informacji, jaką trzeba wprowadzić. W ten sposób powinno projektować się formularze, które są obszerne, więc autorzy dążą do ich maksymalnej zwięzłości. Na tej zwięzłości mogą tracić użytkownicy, bo informacja w postaci samych etykiet i informacji może być zbyt skąpa. Wtedy wystarczy dodać przycisk lub link, który poprowadzi do szerszego objaśnienia, które nie będzie wyświetlane wszystkim.

2 thoughts on “Pomoc kontekstowa (WCAG 2.0 SC 3.3.5, poziom AAA)

  1. Problem z pomocą kontekstową polega na tym że do końca nikt nie wie jak ma wyglądać. Są takie podejścia: albo robi się jakieś kreatory wzorowane na „wizardach” programów instalacyjnych (szczególnie jak użytkownik wybrał instalację zaawansowaną). Takie podejście przypomina podejście w serwisach bankowych – długie formularze do wypełnienia. (gdzie do każdego pola muszą być dokładne instrukcje). Inne podejście jest zastosowane w Google AdWord gdzie do kązdego trudniejszego pola przypisano ikonkę ze znakiem zapytania. Klinięcie w tą ikonkę powoduje pojawienie się „dymka” z krótkim objaśnieniem i linkiem do właściwej instrukcji. Można przebadać szereg serwisów obsługujących pocztę online (Gmail, Yahoo, YandexMail, 163,com.cn, Hotmail czy polskie onet, wp, o2, interia ) w celu ustalenia optymalnych zasad działania pomocy kontekstowej. Z punktu projektanta UI pomoc kontekstowa może być zaimplementowana jako formy „tooltip” „dymków” „menu podręcznego” „pie menu” „notyfikacji” „okienek dialogowych”. Temat rozległy biorąc pod uwagę różne platformy i zalecenia UI. Natomiast wg standardu HTML5 (dataset atributes) http://www.w3.org/TR/html5/global-attributes.html#dom-dataset sytuacja jest w miarę klarowna: wystarczy że programiści umówią się że atrybut dowolnego znacznika HTNL5 dla pomocy kontekstowej będzie będzie „data-tooltip” natomiast implementację CSS i JavaScript w sensie szablonów pozostawimy do wyboru twórcom strony internetowej (będzie mógł wybrać inną bibliotekę dla mobile inną na tablety a jeszcze inną na duże monitory). Obecnie wszystkie przeglądarki obsługują dataset atributes – http://caniuse.com/dataset

  2. A ja sądzę, że problem wcale nie jest taki wielki. Po pierwsze – pomoc kontekstowa potrzebna jest dosyć rzadko, bo wtedy gdy etykieta i instrukcja jest niewystarczająca. Po drugie – ważny jest skutek, a nie technika. Opisane rozwiązanie od Google jest moim zdaniem optymalne dla większości formularzy. Kreator jest lepszy w sytuacji, gdy projektant chce uniknąć problemów z dostępnością formularzy, w których pewne elementy zależą od wcześniej wybranych. Sprawdzałem formularz rejestracji poczty na O2.pl i tam było tylko jedno miejsce tego typu. Za to było sporo innych błędów dostępności, na przykład oznaczanie błędnie wypełnionych danych na czerwono oraz kod obrazkowy. Może trzeba napisać jakiś tekst z casem na temat przelewu bankowego…

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *