Przeciągnij wyżej — i pozwól zrobić to bez przeciągania

Redaktorka przesuwa kartę „Dojazd” nad „Program”. Na dużym ekranie ruch trwa sekundę. Na telefonie ta sama karta jedzie w dół, lista przewija się w górę, a palec zasłania miejsce docelowe. Po trzeciej próbie człowiek zaczyna zazdrościć ulotce: tam kolejność jest przynajmniej przyklejona na stałe.

Zmiana kolejności to prosta intencja. Interfejs potrafi zamienić ją w zadanie wymagające precyzji dłoni, dobrej pamięci i znajomości ukrytej zasady zapisu. Dlatego projekt warto zacząć od pytania, co ma znaleźć się przed czym oraz kiedy nowy porządek stanie się obowiązujący. Sam gest jest dopiero sposobem wykonania tej decyzji.

Przyjmijmy fikcyjny serwis wydarzenia Przejście. Redaktorzy układają sześć kart informacyjnych, a po zatwierdzeniu publikują stronę dla gości. Projekt musi obsłużyć przeniesienie jednej karty, pokazać skutek i umożliwić dalszą pracę. Ten sam wynik ma być osiągalny na telefonie i klawiaturą, także bez przeciągania.

Co właściwie zmienia położenie karty?

W Przejściu redaktor układa kolejność informacji na stronie głównej. Nie zmienia statusu ich opracowania. To rozróżnienie trzeba nazwać w projekcie, ponieważ podobny gest na tablicy zadań może oznaczać zupełnie inną operację. Przeniesienie „Dojazdu” do góry nie powinno przypadkiem zatwierdzić jego treści ani udostępnić jej gościom.

Ustal, czy porządek dotyczy jednej listy, wybranej sekcji czy całego serwisu. Redaktor może oglądać karty po filtrze i nie widzieć dwóch ukrytych pozycji. Wtedy trzeba określić, co znaczy „na początek”. Czy karta trafia na początek wyświetlanej grupy, czy przed wszystkie pozostałe? Jeżeli interfejs nie potrafi pokazać sensu przeniesienia w filtrowanym widoku, można udostępnić je dopiero po powrocie do pełnej listy, z wyjaśnieniem dlaczego.

Nie łącz też zaznaczenia z chwytaniem. Pole wyboru może służyć do przygotowania paczki, uchwyt do zmiany porządku, a tytuł do otwarcia edycji. Gdy cały wiersz wykonuje te trzy role zależnie od minimalnego ruchu palca, pomyłka staje się częścią codziennej obsługi. Regułę wyboru wielu pozycji rozstrzyga osobno zakres „Zaznacz wszystkie”. Tutaj redaktor powinien rozpoznawać jedną konkretną kartę przeznaczoną do przeniesienia.

Jeżeli redaktor wcześniej zaznaczył kilka kart do innego zadania, uruchomienie ruchu przy jednej nie powinno niejawnie objąć całej grupy. Projekt musi wyraźnie wskazać zakres czynności. Dla naszego panelu przyjmujemy przenoszenie pojedynczej karty. Operacja na wielu elementach wymagałaby osobnego opisu zachowania grupy i jej kolejności wewnętrznej.

Dla niewielkiej listy użyteczne mogą być polecenia „Przenieś na początek”, „Przenieś na koniec” oraz wybór miejsca względem innej karty. Nie trzeba dodawać ich wszystkich do każdego projektu. Dobierz zestaw do rzeczywistych zadań: przesunięcie o jedną pozycję, przełożenie przez całą listę i rezygnacja ze zmiany to odmienne czynności, które warto sprawdzić na przykładzie.

Zwróć uwagę na tytuły podobnych pozycji. Jeśli są dwie karty „Informacje”, przy wyborze miejsca docelowego pokaż dodatkowe rozróżnienie, na przykład nazwy sekcji. Sam numer porządkowy może zmienić się w trakcie pracy. Użytkownik powinien wskazać rozpoznawalny element, a nie zapamiętywać, co przed chwilą znajdowało się w wierszu czwartym.

Ręczny porządek odróżnij od sortowania według tytułu lub daty. Jeżeli widok stale sortuje karty alfabetycznie, przeciągnięcie może po chwili wyglądać na cofnięte. W takim trybie wyjaśnij, dlaczego ręczna zmiana jest niedostępna, albo pozwól świadomie przełączyć się na własny układ. Redaktor powinien wiedzieć, którą regułę właśnie ogląda.

Alternatywa powinna dawać ten sam wynik

W wyjaśnieniu kryterium WCAG 2.5.7 W3C rozdziela obsługę klawiaturą od alternatywy pojedynczym wskaźnikiem bez przeciągania. Sama możliwość użycia klawiszy nie wystarcza do spełnienia tego kryterium. Opis uwzględnia wyjątki, między innymi niezbędność przeciągania i funkcje zapewniane przez przeglądarkę; nie jest to ogólna ocena zgodności całej strony.

Praktyczny projekt dla Przejścia może więc mieć widoczny przycisk „Zmień kolejność” przy karcie. Po jego uruchomieniu redaktor wybiera docelową pozycję prostymi kliknięciami lub dotknięciami. To samo polecenie jest dostępne klawiaturą. Użytkownik telefonu nie musi w tym celu podłączać klawiatury ani wykonywać długiego gestu przez kilka ekranów.

Jeżeli lista jest krótka, przyciski przesunięcia o pozycję mogą być wystarczające. Przy kilkudziesięciu kartach wielokrotne naciskanie „Wyżej” staje się uciążliwe. Wtedy wybór „Przed kartą Program” może lepiej odpowiadać intencji. W projekcie porównaj liczbę decyzji i czytelność wyniku dla obu sposobów, zamiast przyznawać jednemu stałe pierwszeństwo.

Osoba używająca czytnika ekranu, czyli narzędzia odczytującego strukturę i treść interfejsu, powinna rozpoznawać nazwę operacji oraz kartę, której dotyczy. Kilka przycisków odczytywanych wyłącznie jako „Przenieś” nie daje tej informacji. Nazwa dostępna dla takiego narzędzia może zawierać nazwę karty, choć widoczna etykieta pozostaje krótsza. Sposób przekazania obu informacji trzeba odebrać w działającym komponencie.

Przy granicy listy stan również musi być zrozumiały. Karta na pierwszej pozycji nie może zostać przesunięta jeszcze wyżej w tej samej grupie. Projekt powinien pokazać brak takiej możliwości i pozostawić dostępne pozostałe działania. Nie kieruj użytkownika do polecenia, które po wykonaniu bez wyjaśnienia niczego nie zmieni.

Jeżeli redaktor anuluje wybór miejsca, dotychczasowy porządek pozostaje czytelny. Zamknięcie menu nie powinno wyglądać jak przyjęcie zmiany. Gdy interakcja ma etap podglądu, nazwij go i pokaż, jak go zatwierdzić albo porzucić. To szczególnie przydatne wtedy, gdy ruch obejmuje dłuższą listę i użytkownik chce zobaczyć sąsiednie karty przed decyzją.

W próbie użyj jednoznacznych poleceń „przed” oraz „za” konkretną kartą. Po przeniesieniu porównaj rzeczywiste sąsiedztwo z intencją, zwłaszcza gdy element pochodził z wcześniejszej części listy. Przesunięcie usuwa go z dawnego miejsca, więc numer wybrany przed ruchem może wymagać innej interpretacji niż numer w gotowym układzie. Użytkownik nie powinien wykonywać tego przeliczenia w pamięci.

Dostępność strony firmowej obejmuje więcej niż jeden gest. Przy tej konkretnej funkcji warto zachować wąską próbę: tę samą kartę przenieść do tego samego miejsca różnymi sposobami i porównać wynik. Sam fakt istnienia przycisku alternatywnego nie dowodzi jeszcze, że wykonuje równoważną operację.

Przy samym geście sprawdź również zwykłe przewijanie telefonu. Redaktor, który chce przesunąć stronę, nie powinien przypadkiem przestawiać treści. W projekcie pokaż obszar rozpoczęcia ruchu i sposób jego anulowania. Zakończenie przeciągania poza dopuszczonym miejscem musi mieć określony wynik, widoczny także po zakończeniu animacji.

Po ruchu redaktor nadal ma coś do zrobienia

Po zmianie miejsca redaktor powinien od razu rozpoznać nowe położenie karty. Jeśli cała lista nagle przeskakuje, może stracić orientację, nawet gdy porządek jest poprawny. Warto podtrzymać rozpoznawalność przeniesionego elementu i pokazać jego nowe otoczenie. Widoczne wyróżnienie ma pomagać znaleźć kartę, a nie urządzać pokazu animacji po każdym kliknięciu.

Wskazówki dostępności Atlassian dla przeciągania obejmują trzy części: uruchomienie równoważnej czynności, przekazanie wyniku oraz umożliwienie dalszej pracy. W opisie wyniku uwzględniają nazwę elementu i zmianę położenia, a przy kontynuacji zwracają uwagę na zachowanie lub przywrócenie fokusu. Fokus oznacza element, z którym w danej chwili pracuje użytkownik klawiatury.

Własny komunikat dla Przejścia może brzmieć: „Dojazd przeniesiono przed Program. Pozycja 2 z 6”. Treść trzeba powiązać z rzeczywistym wynikiem, również dla technologii asystujących. Nie wystarczy dopisać jej w makiecie obok listy. Wdrożenie musi przekazać informację w odpowiednim momencie, bez przenoszenia użytkownika do przypadkowego miejsca strony.

Po zamknięciu polecenia redaktor powinien móc kontynuować pracę przy tej samej karcie. Jeśli fokus wraca na początek całego panelu, kilka kolejnych zmian wymaga każdorazowo odnajdywania elementu od nowa. Sprawdź też sytuację, w której karta znika z bieżącego widoku po przeniesieniu do innej grupy. Trzeba wtedy świadomie wybrać miejsce dalszej pracy.

Jeżeli dostępne jest cofnięcie, nazwij jego zakres: ostatni ruch, cały niezapisany układ czy ostatni zapis. Po kilku przestawieniach te polecenia prowadzą do innych wyników. Przygotuj krótką sekwencję dwóch ruchów i sprawdź cofnięcie każdego z nich. Dzięki temu przycisk nie stanie się niespodziewanym powrotem do początku pracy.

Mikrointerakcje strony mogą wspierać takie przejście: wskazać ruch i odpowiedź systemu. Nie powinny być jedynym nośnikiem wyniku. Użytkownik, który nie zobaczy animacji albo korzysta z innego sposobu odczytu, nadal musi rozpoznać nową kolejność i stan zapisu.

Przestawione, zapisane i opublikowane

W Przejściu redaktor najpierw zmienia szkic. Nowy porządek staje się widoczny dla gości dopiero po publikacji. Interfejs powinien pokazać tę granicę przy pracy z listą. Komunikat „Zmieniono kolejność” bez dalszej informacji może sugerować, że publiczna strona już wygląda inaczej.

Jeżeli zapis odbywa się automatycznie, pokaż jego rzeczywisty wynik, w tym przerwanie połączenia. Jeżeli wymaga przycisku, odróżnij lokalny układ od zapisanego szkicu. W obu wariantach ustal zachowanie po odświeżeniu strony i po ponownym otwarciu panelu. Redaktor nie powinien odkrywać dopiero następnego dnia, że starannie ułożona lista istniała tylko w otwartej karcie przeglądarki.

Po odrzuceniu zapisu pokaż dalszy stan układu. Można zachować roboczy układ do ponowienia albo przywrócić ostatni potwierdzony stan, zależnie od uzgodnionego działania. Jeśli układ pozostał roboczy, wskaż możliwość ponowienia; przy przywróceniu starego pokaż, że nowa kolejność nie została zachowana. Cichy powrót do starej kolejności wygląda jak pomyłka użytkownika, a pozostawienie nowej bez informacji o błędzie wygląda jak sukces.

Przy wspólnej pracy trzeba też określić, co stanie się, gdy druga osoba zapisze inny porządek. To zadanie dla projektu i wdrożenia: makieta ostrzeżenia nie egzekwuje kontroli zapisu. Proces publikacji treści w CMS powinien wskazywać, kto może zmienić szkic, kto zatwierdza i jaki stan trafia na stronę.

Na odbiór przygotuj krótką listę z podobnymi tytułami, pełną listę dłuższą od ekranu oraz przypadek granicznej pozycji. Poproś o przeniesienie wskazanej karty przed konkretną inną kartę, zapisanie i sprawdzenie po powrocie. W badaniu z osobami używającymi technologii asystujących zobaczysz, czy nazwy, wynik i kontynuacja rzeczywiście składają się w zrozumiałą czynność.

Rozmowę z Aeneia Design można zacząć od takiego zadania redaktora i ustalonej reguły publikacji. Wtedy projekt nie kończy się na karcie, która ładnie podąża za kursorem. Warunkiem odbioru jest porządek, który użytkownik potrafi świadomie ułożyć, zachować i udostępnić. Sprawdź go po powrocie do panelu oraz w widoku dla gości po publikacji. To dwa różne miejsca kontroli: zapis szkicu może być poprawny, choć publiczna strona nadal pokazuje wcześniejszy układ.