Zapobieganie błędom (WCAG 2.0 SC 3.3.6, poziom AAA)

Ponieważ niepełnosprawni użytkownicy są bardziej narażeni na popełnianie błędów przy wprowadzaniu danych, powinno się im zapewnić specjalne wsparcie.

Kryterium sukcesu 3.3.6 dotyczy wszystkich serwisów internetowych, w których użytkownik przesyła wprowadzone przez siebie informacje. Projektując system i przebieg interakcji należy zapewnić użytkownikowi przynajmniej jedną z możliwości: wycofania wysłanych danych, sprawdzenia poprawności danych i możliwości poprawienia błędów lub potwierdzenia przed wysłaniem. Skorzystają na tym:

  • użytkownicy niewidomi,
  • użytkownicy słabowidzący,
  • użytkownicy mający problemy z rękami, na przykład spastyczności,
  • użytkownicy z problemami kognitywnymi,
  • dyslektycy,
  • użytkownicy o małym doświadczeniu,
  • seniorzy.

Zasada ta obejmuje wszystkie formularze publikowane w serwisach internetowych. Formalnie nie ma wyjątków od zasady, chociaż zdarzały się takie w innych kryteriach sukcesu. Można jednak postawić pytanie: co z formularzem wyszukiwania, który składa się z pola edycyjnego i przycisku „szukaj”? Taki formularz wypełnia definicję formularza, za pomocą którego przesyła się informacje wprowadzone przez użytkownika, a przecież stosowanie tego kryterium sukcesu nie ma sensu. Wydaje się jednak, że standardowo takie formularze spełniają kryterium sukcesu dając możliwość wycofania danych. Wystarczy bowiem cofnąć przeglądarkę do poprzedniej strony, by przywrócić stan pierwotny i dokonać poprawek. Jednak formularze wyszukiwania, które nie zapewniają takiej funkcjonalności mogą naruszać wymagania dostępności.

2 myśli na temat “Zapobieganie błędom (WCAG 2.0 SC 3.3.6, poziom AAA)

  1. Zapobieganie błędom w tym momencie jest dość kłopotliwe z punktu widzenia projektowania interakcji, faktycznie czynności które są przedstawione „wycofania wysłanych danych, sprawdzenia poprawności danych i możliwości poprawienia błędów lub potwierdzenia przed wysłaniem” wymagają szczególnego omówienia z punktu widzenia programisty.

    „wycofanie wysłanych danych” – czyli anulowanie wysłanych danych. Ponieważ komunikacja w internecie jest bezstanowa tj protokół HTTP nie przewiduje cofania działań co najwyżej można dane modyfikować do postaci przed zmianą, natomiast w systemach bazodanowych zabezpieczenie przed przypadkowymi zmianami danych jest kluczowa i dlatego wprowadzono transakcyjność która pozwala na wycofanie wysłanych danych, Dosłowna interpretacja „wycofania wysłanych danych” nie jest możliwa na gruncie internetu. Przez analogię czy można cofnąć wysłany email?

    „sprawdzanie poprawności danych” – tutaj jest największe pole do popisu dla wszelkiego rodzaju formularzy, właściwie to obowiązkowo trzeba wprowadzić mechanizmy walidacji danych do każdego pola w formularzach HTML5 to już duży postęp w wprowadzaniu nowych mechanizmów walidacji danych przede wszystkim dzięki atrybutom pattern i jak dataset. W praktyce najczęściej ludzie korzystają z mechanizmu poprawiania literówek w tekście pisanym (co występuje zarówno w edytorach tekstu takich jak Word, w przeglądarkach internetowych w formularzach, a także w edytorach online typu Google Dysk O tym że sprawdzanie poprawności danych jest bardzo ważne świadczy problem brak standardu zapisu daty, właściwie to każdy ma swój ulubiony sposób zapisu daty a mechanizmy walidujące nie zawsze potrafią wskazać jaka jest poprawna data

    „możliwość poprawienia błędów” – jeżeli mam rozumieć dosłownie to zinterpretowałbym jako modyfikacja wysłanych danych. W internecie do tego wykorzystuje się następujące podejścia: transakcyjne które polega na nadpisaniu danych nowymi co występuje w systemach bazodanowych oraz podejście z kontroli wersji które polega na tym że w momencie modyfikacji tworzona jest nowa wersja danej informacji i użytkownik ma dostęp do historii zmian.
    Coraz większe znaczenie ma ten drugi sposób podejścia który realizowany jest za pomocą mechanizmów NoSQL

    „potwierdzenie przed wysłaniem” jest konsekwencją zapobiegania sytuacji w której wystąpi „wycofanie wysłanych danych”

    Napisanie dobrego case w oparciu o samą wyszukiwarkę jest bardzo trudne (co pokazuje że tematyką accessibility trzeba robić w zespołach z programistami)

    Spróbuję opisać w sposób sformalizowany
    Adress : /szukaj/
    Browser: {poleWyszukiwarki:TextField, Szukaj:Button}
    Event: onFocus(poleWyszukiwarki), onKey(pattern: p{L}p{M}*) {change(poleWyszukiwarki.value)}
    Event: onKey(Enter), onMousePress(Szukaj:Button) onClick(Szukaj:Button) {getURL(/szukaj/#/poleWyszukiwarki.value)

    Adress: /szukaj/#/poleWyszukiwarki.value
    Browser: {poleWyszukiwarki.value:TextField, Szukaj:Button. Szukaj w wynikach:Link, [Popraw poleWyszukiwarki.value:Link ]? ,[Wyniki:Link]*
    Event: onFocus(poleWyszukiwarki), onKey(Backspace) {change(poleWyszukiwarki.value)}
    Event: onBlur(poleWyszukiwarki),onKey(Backspace) {/* cofanie w przeglądarce */}
    Event: onFocus(Szukaj w wynikach) onKey(Enter) onClick(Szukaj w wynikach) {if(change(poleWyszukiwarki.value))getURL(/szukaj/#/poleWyszukiwarki.value/change(poleWyszukiwarki.value)) else onFocus(poleWyszukiwarki)}

    Ta próbka pokazuje że jednak bardzo trudno opisać w sposób sformalizowany procesy zachodzące w interfejsie użytkownika żeby spełniał powyższe wymogi (ale także opisać wiele różnych sytuacji np: z związku z nawigacją po klawiaturze) Teraz zaprogramowanie skomplikwanych interfejsów użytkownika odbywa się za pomocą frameworków JavaScriptowych takich jak Backbone.js czy Spine.js. Tym opisem chciałem zwrócić uwagę na podwójne zachowanie klawisza Backspace raz służy do cofania do poprzedniej strony a drugi raz służy do zmiany zawartości pola tekstowego. Wszystko zależy od tego jak opisane są zdarzenia. Projektanci UX głównie projektują wizualnie natomiast projektant Accesibility powinien świetnie znać technologie aby wyłapywać konteksty którym umykają się projektantom UX którzy nie koniecznie znają możliwości technologii asystujacych

    Polubienie

  2. Wycofanie danych nie oznacza tutaj technicznego wycofania, ale praktyczne. Jeżeli użytkownik ma możliwość wyedytować dane lub po prostu je usunąć z systemu, to jest to spełnienie wymagania. Myślę jednak, że lepszym rozwiązaniem jest zapewnienie możliwości sprawdzenia danych przed wysłaniem, jak to ma zazwyczaj miejsce w systemach bankowości elektronicznej lub w sklepach internetowych. Zgadzam się, że technicznie wysłanych do zewnętrznego systemu danych wycofać się nie da, ale efekt będzie identyczny, gdy damy użytkownikowi możliwość odnalezienia danego wpisu i jego usunięcia.

    Polubienie

Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Wyloguj /  Zmień )

Zdjęcie na Google

Komentujesz korzystając z konta Google. Wyloguj /  Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Wyloguj /  Zmień )

Zdjęcie na Facebooku

Komentujesz korzystając z konta Facebook. Wyloguj /  Zmień )

Połączenie z %s

Ta witryna wykorzystuje usługę Akismet aby zredukować ilość spamu. Dowiedz się w jaki sposób dane w twoich komentarzach są przetwarzane.