Sesja wygasła. Co stało się z formularzem?

„Sesja wygasła. Zaloguj się ponownie”. Komunikat wyjaśnia, dlaczego nie możesz teraz działać. Nie odpowiada na pytanie, które zwykle przychodzi pierwsze: co stało się z tekstem wpisywanym przez ostatnie kilkanaście minut? Zanim człowiek poda hasło, próbuje ocenić, czy strona właśnie zgubiła jego pracę.

W fikcyjnym serwisie firmowym redaktor uzupełnia opis realizacji. Otwiera materiały w drugiej karcie, odbiera telefon i wraca do panelu. Wpisany akapit nadal widać, lecz przy zapisie pojawia się prośba o logowanie. Projekt powinien przeprowadzić tę przerwę tak, żeby redaktor rozpoznał stan tekstu i sam zdecydował o dalszym działaniu.

Utrata dostępu i utrata danych to różne zdarzenia

Sesja określa w tym przykładzie okres, w którym system rozpoznaje zalogowaną osobę. Jej zakończenie nie wyjaśnia samo w sobie, czy zapisano szkic. To zależy od rozwiązania używanego w serwisie. Potrzebujesz poznać tę zależność przed napisaniem komunikatu, a nie dopiero podczas odbioru gotowego okna.

Ustal osobno trzy kwestie: kiedy kończy się dostęp, które dane zostały utrwalone i co stało się z rozpoczętą operacją. Redaktor może mieć zapisany wcześniejszy akapit oraz kilka ostatnich zdań bez potwierdzenia. Może też wysłać żądanie zapisu tuż przed przerwą. Każda sytuacja prowadzi do innej informacji po powrocie.

Nie nazywaj wszystkiego „błędem sesji”. Dla użytkownika liczy się, czy powinien ponownie potwierdzić tożsamość, odtworzyć część treści czy sprawdzić wynik czynności. Jeden ogólny komunikat może skłonić go do ponownego naciśnięcia przycisku, chociaż poprzednia próba już się zakończyła.

Wyjaśnienie kryterium WCAG 2.2.5 na poziomie AAA opisuje kontynuację czynności bez utraty danych po ponownym uwierzytelnieniu, czyli potwierdzeniu tożsamości. To konkretny punkt odniesienia dla projektowania powrotu; nie jest samodzielną oceną całej dostępności serwisu.

W naszym przykładzie zapisz oczekiwany przebieg zwykłymi słowami. Redaktor loguje się ponownie, wraca do tej samej realizacji i rozpoznaje zachowaną wersję. Ostatni dopisek pozostaje dostępny do sprawdzenia. Jeżeli część materiału nie została zapisana, system wskazuje ten fakt zgodnie z tym, co rzeczywiście potrafi ustalić.

Doprecyzuj również znaczenie aktywności. Czy za pracę uznawane jest wpisywanie, przechodzenie między widokami, otwarcie dokumentu czy dopiero operacja po stronie serwera? Użytkownik nie powinien odkrywać po czasie, że długie przygotowywanie odpowiedzi było dla systemu bezczynnością. Regułę trzeba uzgodnić z właścicielem mechanizmu sesji i sprawdzić na prawdziwym przebiegu.

Zachowanie treści ma być częścią uzgodnionego rozwiązania. Sam interfejs nie może obiecać odzyskania danych, których nigdzie nie utrwalono. Projektant potrzebuje znać potwierdzony punkt zapisu oraz sposób odzyskania. Z tego wynika uczciwy komunikat, który można pokazać przed przerwą i po niej.

Ostrzeżenie powinno umożliwiać decyzję

Jeżeli sesję można przedłużyć, pokaż, co wkrótce się wydarzy i co człowiek może zrobić. „Potrzebujesz więcej czasu?” bywa zrozumiałe, lecz przyciski powinny nazwać działanie: pozostać w panelu lub się wylogować. Użytkownik nie powinien zgadywać, czy zamknięcie okna również przedłuża dostęp.

W systemie projektowym USWDS przykład okna blokującego pozostałą treść pokazuje ostrzeżenie o końcu sesji z wyborem pozostania lub wylogowania. To przykład uporządkowania decyzji. Czas i skutki w twoim serwisie muszą odpowiadać jego rzeczywistym ustawieniom.

Zapisz zachowanie każdej drogi wyjścia. Kliknięcie przycisku, użycie klawisza Escape, zamknięcie karty i brak reakcji mogą mieć różne skutki. Jeżeli okno wymaga decyzji, człowiek musi móc ją wykonać bez myszy. Sprawdź też, co dzieje się z miejscem obsługi po zamknięciu: redaktor powinien wrócić do czynności, którą przerwano.

Ostrzeżenie potrzebuje czasu na zauważenie i działanie. Przy ustalaniu przebiegu uwzględnij osobę, która czyta dłużej, używa czytnika ekranu albo musi najpierw odnaleźć właściwy przycisk. Nie oceniaj okna wyłącznie podczas szybkiego klikania przez autora projektu.

W odsłuchu sprawdź kolejność informacji: co się dzieje, jaki jest skutek oraz które działanie pozwala kontynuować. Jeżeli licznik zmienia wartość, posłuchaj, czy nie przeszkadza w poznaniu tych zdań i etykiet przycisków. Celem próby jest wykonanie właściwego działania, a nie usłyszenie każdej kolejnej sekundy. Daj osobie korzystającej z czytnika samodzielnie przejść ostrzeżenie i odnotuj moment, w którym rozpoznała potrzebną czynność. Odbiór dostępności strony powinien objąć także ten przerwany stan, a nie tylko formularz przed pojawieniem się okna.

W próbie kliknij „pozostań” tuż przed końcem. Sprawdź, czy system rzeczywiście potwierdził przedłużenie. Samo zniknięcie ostrzeżenia nie pokazuje wyniku. Jeśli żądanie się nie udało, potrzebna jest informacja odpowiadająca temu stanowi oraz droga do logowania lub zachowanej pracy.

Nie pozostawiaj starego ostrzeżenia po skutecznej zmianie stanu. Okno mówiące, że dostęp za chwilę wygaśnie, choć właśnie został odnowiony, podważa zaufanie do kolejnych komunikatów. Podobnie działa licznik, który wraca do początku bez wyjaśnienia. Czas wyświetlany użytkownikowi powinien odnosić się do tej sesji, z której rzeczywiście korzysta.

Przeprowadź próbę po zmianie karty i uśpieniu urządzenia. Odczekaj ustalony okres, wróć i porównaj komunikat z możliwością wykonania czynności. Nie zakładaj, że sam widoczny licznik jest wiarygodnym dowodem ważności dostępu. W naszym przykładzie redaktor może zobaczyć dawną planszę, mimo że musi już ponownie się zalogować. Interfejs powinien rozpoznać aktualny stan przed przyjęciem kolejnej decyzji, zamiast pozwolić dopisywać tekst pod nieaktualnym ostrzeżeniem.

Przejdź też scenariusz bez reakcji. Redaktor może rozmawiać przez telefon i nie widzieć ostrzeżenia. Przedłużenie czasu nie może być jedyną drogą zachowania sensownego doświadczenia. Po powrocie nadal potrzebuje informacji o stanie danych oraz możliwości odzyskania miejsca. Właśnie tę drogę sprawdzaj niezależnie od samego okna.

Logowanie powinno prowadzić do właściwej pracy

Po potwierdzeniu tożsamości redaktor chce wrócić do konkretnej realizacji. Strona startowa panelu pozostawia mu zadanie odnalezienia jej od początku. Jeżeli ma podobne wpisy, łatwo otworzyć inny. Zachowaj więc rozpoznawalny kontekst: tytuł, identyfikację materiału i miejsce, w którym przerwano edycję.

Przy dłuższej treści sprawdź również miejsce, w którym wznawiasz edycję. Redaktor mógł edytować podpis ostatniej fotografii, mieć rozwinięty panel oraz widoczny komunikat o brakującej informacji. Przywrócenie samych wartości na początku długiej strony pozostawia mu ponowne szukanie tego miejsca. Ustal, które elementy kontekstu warto odtworzyć, i pokaż je w rozpoznawalny sposób. Odzyskany formularz powinien umożliwiać dalszą czynność bez przeglądania całej realizacji w poszukiwaniu przerwanego zadania.

W projekcie formularza na kilka podejść opisujemy zapisany szkic. Przy wygaśnięciu sesji potrzebujesz dodatkowo rozpoznać fragment bez potwierdzenia zapisu. Jeśli oba stany pokazujesz tak samo, człowiek może uznać, że odzyskał cały tekst, choć widzi tylko wcześniejszą wersję.

Wprowadź do próby dwa łatwo odróżnialne akapity. Pierwszy zapisz, drugi dopisz przed samą przerwą. Po zalogowaniu sprawdź obecność obu i komunikat o ich stanie. Dzięki temu odbiór nie zakończy się na stwierdzeniu, że „formularz się pojawił”. Oceniasz zachowanie własnej treści oraz możliwość jej dalszej poprawy.

Jeśli odnowienie dostępu wymaga otwarcia innego widoku, ustal, co zostaje w pierwotnym. Redaktor może wrócić do starej karty, w której wciąż czeka dawny komunikat. Powinien rozpoznać, gdzie ma teraz działać i czy musi odświeżyć stan. Odgadywanie, które z trzech okien jest zalogowane, nie powinno być dodatkowym zadaniem redakcyjnym.

Przerwij również samo logowanie. Wpisz błędne dane w środowisku próbnym, cofnij się, a następnie ponów potwierdzenie. Sprawdź, czy droga nadal prowadzi do tej samej pracy. Komunikat o nieudanym logowaniu nie powinien sugerować, że utracono szkic, jeśli problem dotyczy wyłącznie dostępu. Przy kolejnym podejściu redaktor potrzebuje zachowanego celu powrotu. Bez tego pomyłka przy haśle może zakończyć się na ekranie głównym, chociaż odzyskiwany dokument wciąż istnieje.

Sprawdź logowanie na inne konto. Odzyskanie dostępu nie powinno bezrefleksyjnie pokazywać materiału poprzedniej osoby. Ustal z wykonawcą sposób powiązania zachowanej pracy z uprawnionym użytkownikiem. Komunikat o wznowieniu musi odpowiadać temu powiązaniu, zwłaszcza przy wspólnym komputerze.

Oddziel też wygaśnięcie od świadomego wylogowania. Człowiek kończący pracę przy wspólnym stanowisku podejmuje inną decyzję niż ktoś, kto nie zauważył ostrzeżenia. W próbie wróć przyciskiem przeglądarki do wcześniej oglądanego panelu i sprawdź, co można zobaczyć oraz wykonać. Sam wygląd dawnego widoku nie potwierdza ponownego dostępu. Potrzebujesz zgodnego z ustalonymi zasadami stanu dla osoby, która faktycznie korzysta teraz z urządzenia, a nie automatycznej zachęty do wznowienia cudzej edycji.

Zastanów się również nad osobą, która nie może się teraz zalogować. Może nie mieć pod ręką potrzebnego sposobu potwierdzenia. Powinna wiedzieć, czy jej praca poczeka i jak długo pozostanie dostępna według ustalonych zasad. Jeżeli odzyskanie wymaga pomocy zespołu, przekaż rozpoznawalny identyfikator szkicu zamiast prosić o odtworzenie treści w kolejnym zgłoszeniu.

W zakupie bez konta rozdzielamy wykonanie czynności od rejestracji. Tu podobnie nie kieruj do założenia nowego konta, gdy problem dotyczy dostępu do już rozpoczętej pracy. Nowa tożsamość może wcale nie otwierać poprzedniego szkicu. Dalszy krok powinien wynikać z faktycznego stanu konta i danych.

Sesja mogła się skończyć, a operacja nadal trwać

Redaktor naciska „Zapisz”, po czym pojawia się prośba o logowanie. Nie wiadomo jeszcze, czy żądanie dotarło i jaki ma wynik. Powrót powinien najpierw odtworzyć stan tej operacji. Ponowne wykonanie nie zawsze jest właściwą reakcją, szczególnie gdy przycisk publikuje materiał lub uruchamia pracę poza panelem.

Do materiału próbnego dodaj fotografię, której przesyłanie trwa dłużej niż zapis krótkiego opisu. Wygaśnięcie może nastąpić między tymi czynnościami. Sprawdź osobno tekst, plik i ich powiązanie z realizacją. Lista może pokazywać wybraną fotografię, chociaż nie została jeszcze przyjęta do dokumentu. Po odzyskaniu dostępu redaktor musi rozpoznać, czy ma ponowić tę konkretną czynność, czy znaleźć gotowy materiał. Sam powrót nazwy pliku do widoku nie domyka sprawy.

Przy długim zadaniu na stronie wynik może powstać niezależnie od otwartej karty. Po odzyskaniu dostępu trzeba odnaleźć właściwe zadanie i jego status. Komunikat „sesja wygasła” nie wyjaśnia, czy generowanie paczki przerwano, ukończono, czy nadal czeka ono na wykonanie.

Nazwij więc dalszy przycisk według potwierdzonej sytuacji. „Wróć do szkicu”, „Sprawdź wynik zapisu” oraz „Ponów zapis” nie są wymiennymi etykietami. Każda zakłada inną wiedzę o wcześniejszej próbie. W formularzu kontaktowym podobne rozróżnienie decyduje, czy użytkownik przypadkiem nie złoży kolejnego zgłoszenia.

Odbierz cały przebieg na ustalonej wersji serwisu: przedłużenie, brak reakcji, wygaśnięcie, powrót i czynność rozpoczętą tuż przed przerwą. Przy każdej próbie porównaj widoczny komunikat z zachowaną treścią oraz skutkiem po stronie systemu. Szybki test samego okna nie pokaże, czy odzyskiwanie prowadzi do właściwego materiału.

Uzgodnij sposób wywołania wygaśnięcia w środowisku próbnym. Samo ręczne otwarcie makiety ostrzeżenia sprawdza inny fragment niż rzeczywista utrata dostępu. Wykonawca może przygotować kontrolowany przebieg, w którym znany jest ostatni zapis i stan sesji. Dzięki temu da się porównać oczekiwanie z wynikiem. Zostaw zapis użytej wersji i warunków próby, żeby kolejna osoba mogła powtórzyć problem po poprawce, zamiast czekać przy przypadkowo otwartej karcie.

Przynieś do rozmowy z Aeneia Design opis jednej takiej przerwy i dane, które miały po niej pozostać. Pozwoli to ustalić stany do zaprojektowania oraz warunki odbioru. Użytkownik powinien po ponownym wejściu wiedzieć, gdzie jest jego praca i jaka decyzja pozostała do wykonania. Nie powinien zaczynać od pisania tego samego akapitu po raz drugi.