Etap rozliczenia jest dla wielu sklepów internetowych najbardziej wrażliwą częścią strony, jeśli chodzi o dostępność. Podczas gdy strony produktów zwykle działają jeszcze względnie dobrze z czytnikiem ekranu, proces zawiesza się, gdy klient musi zapłacić: przyciski bez wyraźnej etykiety, komunikaty o błędach, które nie są ogłaszane, lub widget płatniczy od zewnętrznego dostawcy, którego nie można obsługiwać bez myszy. To nie przypadek. Etap rozliczenia zawiera największość dynamicznych elementów całej strony, a elementy dynamiczne to dokładnie tam, gdzie czytniki ekranu i nawigacja za pomocą klawiatury zawieszczają się najszybciej.
Nie chodzi tu o małą szczegół. Etap płatności podlega tym samym wymaganiom EN 301 549 co reszta strony, a użytkownik przechodzi ten etap dokładnie w momencie, gdy chce coś kupić. Czytnik ekranu, który się tam zawiesza, wyklucza klienta w decydującym momencie. To również powód, dla którego w axessia standardowo uwzględniamy etap rozliczenia w pełnym skanowaniu, a nie tylko w bezpłatnym skanowaniu szybkim stron głównych.
Gdzie w praktyce pojawia się problem
Najczęstsze problemy są zdumiewająco powtarzalne. Przycisk dla "następny krok" lub "zapłać teraz", który zawiera tylko ikonę bez tekstu, który czytnik ekranu może odczytać. Komunikat o błędzie dla nieprawidłowo wypełnionego pola kodowego, który pojawia się na ekranie, ale nie jest ogłaszany, ponieważ brakuje prawidłowego powiązania technicznego. Wskaźnik postępu ("krok 2 z 3"), który jest wizualnie wyraźny, ale pozostaje niewidoczny dla czytnika ekranu. I sam dostawca płatności: widgety iDEAL lub karty kredytowej od firm trzecich są często zainstalowane luźno i mają swój własny poziom dostępności, na który sklep internetowy ma mało wpływu, ale pozostaje za niego odpowiedzialny.
Kolejność ogniskowania jest również powtarzającym się problemem. Po przesłaniu formularza z błędem uwaga użytkownika powinna być zwrócona na komunikat o błędzie. Jeśli tak się nie stanie, osoba pracująca z klawiaturą lub czytnikiem ekranu szuka tego, co poszło nie tak, bez żadnego punktu zaczepienia.
Dlaczego automatyczne skanowanie to częściowo przegapuje
Automatyczne skanowanie jest dobre w wykrywaniu brakujących etykiet, pustych przycisków i strukturalnych problemów w kodzie źródłowym. Co skanowanie nie może dobrze ocenić, to zachowanie: czy komunikat o błędzie jest rzeczywiście ogłaszany na głos, czy ogniskowanie przesuwa się logicznie, i czy etap rozliczenia po wprowadzeniu danych jest nadal dostępny bez myszy. To wymaga kogoś, kto rzeczywiście przechodzi przez etap z czytnikiem ekranu. To dokładnie typ ograniczenia, które w każdym raporcie axessia jest wyraźnie nazwane: skanowanie testuje część wymagań, nie wszystkie.
Dlatego pełne skanowanie skupia się nie tylko na stronie głównej, ale szczególnie na etapach, przez które rzeczywiście przechodzi klient, w tym logowanie i rozliczenie. Jeśli najpierw chcesz orientacyjnie bez zobowiązań, możesz w kilku pytaniach zobaczyć, gdzie Twoja strona jest teraz.
Co to oznacza dla wymagań, które musisz spełnić
Norma bazowa EN 301 549 przekłada się w praktyce na WCAG 2.1 poziom AA. Zawiera wymagania dotyczące nazwy, roli i stanu elementów interaktywnych, komunikatów o stanie, które muszą być wiadome bez uwagi wzrokowej, i informacji, które nie są przekazywane tylko poprzez kolor lub pozycję. W przypadku dokładnego sformułowania i lokalizacji w tekście oficjalnym EUR-Lex jest właściwym źródłem; tłumaczymy te wymagania na rozpoznawalne sytuacje, takie jak etap rozliczenia, ale nie wydajemy opinii na temat Twojej konkretnej sytuacji. Więcej tła na temat tego, jak powstaje ta translacja, przeczytasz na stronie wyjaśniającej, skąd pochodzą nasze informacje.
Jak sam to przetestujesz lub poprosisz o przetestowanie
Praktycznym pierwszym krokiem jest przejście przez samą stronę płatności bez myszy: tylko za pomocą klawisza Tab i Enter. Jeśli gdzieś się zatrzymacie, istnieje duża szansa, że czytnik ekranu również tam się zablokuje. Drugim krokiem jest testowanie za pomocą bezpłatnego czytnika ekranu, takiego jak NVDA, i zwrócenie szczególnej uwagi na to, co jest odczytywane w momencie pojawienia się błędu. Aby uzyskać pełny obraz, w tym elementy dostrzegalne tylko poprzez ręczne przeglądanie, wymagane jest bardziej rozbudowane testowanie; axessia.eu przeprowadza to testowanie i ustala ustalenia w postaci listy działań w porządku priorytetów, ale nie wykonuje samych prac naprawczych. Pozostaje to do Waszego własnego programisty lub dostawcy, często na podstawie dokładnie tych punktów, które wskazujemy. Inne często zadawane tematy dotyczące tego rodzaju konkretnych problemów znajdziecie zebrane w bazie wiedzy z opracowanymi tematami dla każdej sytuacji.
Jeśli chcecie wiedzieć, ile kosztuje pełne testowanie Waszej strony płatności i środowiska logowania, znajduje się to przejrzyście na stronie z taryfami i tym, co się w nich zawiera.
Chcecie najpierw sami zorientować się bez zobowiązań? Bezpłatne szybkie skanowanie axessia.eu daje obraz Waszych głównych stron w ciągu kilku minut, a test zakresu pokazuje, czy przepisy mają zastosowanie do Waszej organizacji.