Dostępność interfejsu testowego

1) Dlaczego i co uważamy za „gotowe”

• Spełniono kryteria WCAG 2. 1/2. 2 poziomy AA dla platform docelowych;
• interfejs jest całkowicie przekazywany z klawiatury;
• prawidłowa praca z czytnikami ekranu;
• kontrasty są zgodne z normami;
• wszystkie stany/błędy/statusy są dostępne poza zasięgiem wzroku i bez myszy;
• lokalizacja, RTL, zmniejszenie ruchu i funkcje mobilne są brane pod uwagę.

2) Strategia testowania (A11y piramidy)

1. Autotests/linters (szybki zasięg do 40-60% klas problemów).
2. Ręczne sprawdzanie wzorca (klawiatura, ostrość, treść, logika).
3. Sesje Assistive Tech (AT): czytniki ekranu, skalowanie, filtry kolorów.
4. Testy terenowe z użytkownikami (jeśli to możliwe).

Cel: złapać usterki systemowe na poziomie komponentu/wzoru, aby nie rozmnażały się w funkcjach.

3) Lista kontrolna kontroli podstawowych (szybkie uruchomienie)

• Klawiatura: wszystko jest dostępne za pomocą kart/strzałek; kolejność skupienia jest logiczna; trick pułapka w modalach; ESC/Enter/Space działa.
• Wskaźnik ostrości jest widoczny w dowolnym temacie/tle.
• Kontrast: tekst ≥ 4. 5:1 (regularne), ≥ 3:1 (duże), ikony/sterowniki są czytelne.
• Semantyka: poprawne znaczniki ('przycisk','a ',' label ',' ul/li ',' th/td'), role i 'aria-' tylko w razie potrzeby.
• Czytnik ekranu: tytuły według hierarchii, znaczące nazwy przycisków/linków, alternatywy dla ikon/obrazów.
• Formularze: wyraźna „etykieta”, wskazówki/błędy są powiązane („aria-description by”), teksty błędów są specyficzne.
• Dynamika: toasty/banery/błędy są ogłaszane za pośrednictwem „aria-live” („grzeczny ”/„ asertywny”).
• Animacje szanują „preferuje zredukowany ruch”; bez „wstrząsania” interfejsem.
• Lokalizacja/RTL: ekrany kluczowe są wyrównane, numery/daty/waluty są formatowane przez narzędzia.
• Mobilność: cele dotykowe ≥ 44 × 44 px, powiększenie nie jest zabronione, rotacja ekranu nie łamie treści.

4) Role, obowiązki i artefakty

System projektowania: A11y wymagania w opisie każdego komponentu.
Programiści: automatyczne kontrole, testy jednostkowe/interakcyjne z A11y-asserts.
PA: skrypty ręczne + sesje AT; raport z ciężkością/częstotliwością.
UX/Content: mikrokopia błędów/statusów, czytelność na głos.
Artefakty: listy kontrolne, skrypty, screencasty AT, lista wad z odniesieniami WCAG, zalecenia.

5) Zautomatyzowane kontrole

Lintery/analizatory: axe, eslint-plugin-jsx-a11y, pa11y, latarnia morska.
W rurociągu: blokujemy PR dla krytycznych naruszeń (role/label/contrast/tab traps).
Migawki kontrastowe: badania wizualne tematów/stanów.

6) Ręczne testowanie: scenariusze

6. 1 klawiatura

Przejdź przez stronę tylko za pomocą klawiatury (Tab/Shift + Tab/Enter/Space/arrows).
Sprawdź: widoczność ostrości, priorytet, dostępność wszystkich działań, brak „pułapek” i „martwych” elementów.
W modalu: ostrość wewnątrz, po zamknięciu, wraca do inicjatora.

6. 2 czytniki ekranu (minimalny zestaw)

Pulpit: NVDA/JAWS (Windows), VoاOver (macOS).
Telefon komórkowy: VoاOver (iOS), Na plecach (Android).
Sprawdzamy: prawidłowe nagłówki (hierarchia H), nazwy przycisków/linków, tabele odczytu ('th '/' scope'), deklarowanie statusów, zrozumiałe błędy formy.

6. 3 Zawartość i mikrokopia

Czytamy krytyczne teksty głośno - bez dwuznaczności, bez „błędu 400”.
Błąd = „co jest nie tak + jak naprawić + ograniczenie/format”.

6. 4 Dynamika i regiony żywe

Toast sukcesu jest 'aria-live =' grzeczny ', błąd jest' asertywny '.
Postęp/pobieranie wyjaśnione tekstem; szkielet jest preferowany do spinner.

7) Formy i błędy (w głębi)

Każde pole posiada powiązaną etykietę (nie pośrednik).
Błędy są związane z polem: 'aria-invalid =' true ',' aria-description by = '[error id]' '.
Formuły formatu (data, numer telefonu) są wcześniej określone; maski nie łamią wejścia/włożenia.
Podsumowanie bannera błędów podczas przesyłania + automatyczne przewijanie i skupienie się na pierwszym błędzie.
Teksty błędów: specyficzne, bez żargonu technicznego.

8) Tabele, listy, wykresy

Tabele: nagłówki "th 'with' scope =" col/wiersz ", podpisy, wznowienie.
Listy są prawdziwe 'ul/ol/li', nie divas.
Wykresy - tabele/opisy alternatywne; dostępne są legendy; kolorystyka - pojedynczy sygnał.

9) Multimedia i animacje

Wideo: napisy/transkrypt; sterowanie klawiaturą; bez autoplay (lub z ciszy).
GIF/mikroanimacje: wyłączyć, gdy „preferuje zredukowany ruch”; unikanie epidemii.
Wibracje/dźwięki - opcjonalne i powielane wizualnie/tekst.

10) Dostępność mobilna

Interaktywny ≥ 44 × 44 px, wystarczające odstępy czasu.
Nie zabraniaj skalowania (meta viewport bez 'user-scalable = no').
Formularz/klawiatura: poprawne typy ('tel', 'e-mail', 'number'), nie ukrywać możliwości systemu.
Sprawdź w ciemnym motywie i czcionki systemowe „więcej”.

11) Lokalizacja, numery i RTL

Ciągi przez klucze i18n z kontekstem; długie języki (DE/TR) nie łamią układu.
Formaty daty/waluty - narzędzia, nie ciągi.
Tryb RTL: lustro ikony nawigacji, sprawdzić kolejność ostrości i przewozu, wejście dwukierunkowe.

12) Specyfika przepływu krytycznego (iGaming)

Płatności/Wnioski

Jasne instrukcje, limity/terminy/prowizje - w tekście.
Błędy dostawcy są deklarowane wyraźnie, bez kodów; istnieje alternatywa dla działań.
Potwierdzenie działania: skupienie się na logicznej CTA, możliwość anulowania.

CCM/weryfikacja

Porady krok po kroku dotyczące zdjęć/dokumentów; postęp i ETA.
Błędy niewyraźne/odblaskowe/okrojone - z przykładami korekcji.
Neutralny ton, bez humoru.

13) Ocena wady

Bloker: Nie można wykonać zadania kluczowego (klawiatura/czytnik ekranu).
Krytyczna: funkcjonalność krytyczna działa, ale z poważnymi barierami.
Major: wchodzi w drogę, jest pole robocze.
Drobne: kosmetyki/niezgodność z przewodnikami bez wpływu na zadanie.

Każda wada jest odniesieniem do kryterium WCAG i odtwarzanego skryptu.

14) Definicja wykonana (A11y)

Przechodzenie skrypt klawiatury bez myszy jest 100%.
axe/latarnia morska: brak krytycznych/wysokich naruszeń.
Kontrast AA we wszystkich tematach/stanach.
Czytnik ekranu-uruchomienie ścieżek kluczowych (navbar, formy, modale, tosty).
dokumentacja A11y dla nowych komponentów/cech (model ról, aria, ostrość, przykłady).
Regresja testów A11y zielony w CI.

15) Procesy i automatyzacja

Przed rozwojem: A11y-criteria w zadaniach, układy z ostrością/stanami błędów.
W rozwoju: linters/ahe podczas montażu lokalnego; migawki wizualne kontrastu/ostrości.
W CI: pa11y/axe-scan przez strony krytyczne; build drop under Blocker/Critical.
Po wydaniu: kwartalne audyty, monitorowanie reklamacji użytkowników przez A11y-tag.

16) Anty-wzory

Odtwórca zamiast etykiety.
'div' instead 'przycisk '/' a'.
Wyłączone pierścienie ostrości „dla dobra piękna”.
Kolor jako jedyny nośnik statusu.
Modale bez pułapki ostrości/ESC.
Brak skalowania na komórce.
„Błąd 400/500” bez ludzkiego wyjaśnienia.

17) Szablony skryptów testowych

Scenariusz 1 - Nawigacja klawiatura (strona formularza)

1. Zakładka do pierwszego pola, wprowadź dane.
2. Shift + Tab back - Sprawdź prawidłowe zamówienie.
3. Walidacja wywołania (przesłanie) - focus przenosi się do pierwszego błędu.
4. Zamknij modulator za pomocą klucza ESC, aby skupić się na inicjatorze.

Scenariusz 2 - Czytnik ekranu (Strona płatności)

1. Przejdź do nagłówka strony (h1), posłuchaj sekcji.
2. Otwórz wybór metody - słychać deklarację ról/stanów.
3. Celowo wykonaj błąd sumy - wiadomość jest odczytywana i powiązana z polem.
4. Udany toast płatniczy uznany za „grzeczny”.

Scenariusz 3 - Dynamika

1. Uruchom operację z czekaniem> 3 sekund - jest tekst o procesie/ETA.
2. W przypadku błędu sieciowego - baner 'asertive', dostępny z klawiatury, jest ścieżka 'repeat/help'.

18) Przydatne mikroszablony

Role/aria dla tostów

html
<div role = "status" aria-live = "polite"> Payment accepted. Balance updated. </div>
<div role = "alert" aria-live = "assertive"> The payment was denied. Try another method. </div>

Błąd łącza do pola

html
<label for = "amount "> Amount </label>
<input id="amount" aria-invalid="true" aria-describedby="amount-error">
<div id = "amount-error "> Minimum 100 UAH. Please enter a larger amount. </div>

Modalka (atrybuty semantyczne)

html
<div role="dialog" aria-modal="true" aria-labelledby="m-title">
<h2 id =" m-title "> Confirm Payment </h2>
<! -- content -->
<button> Confirm </button>
<button> Cancel </button>
</div>

19) Plan szybkiego wdrożenia A11y praktyk

1. Audyt aktualnych komponentów/wzorów (kontrast/nacisk/semantyka ról).
2. Design System Edits: Dodaj partycję A11y do każdego komponentu.
3. Narzędzia: Ustaw up/axe/pa11y/Lighthouse lintery lokalnie i w CI.
4. Szkolenie: krótkie poradniki dla projektantów/programistów/copywriterów.
5. Pilot: naprawić 3-5 najczęściej występujących wad (modale, formy, tosty).
6. Rozporządzenie: DoD z A11y kryteriami; kwartalny audyt.

Końcowy arkusz oszustwa

Sprawdź klawiaturę, ostrość, kontrasty, czytnik ekranu, dynamikę.
ogłaszać statusy poprzez aria-live; błędy - związane z polami.
Szacunek zmniejszyć ruch, nie zakazać skalowania.
Przemyśl semantykę (tagi/role), a nie „jak to wygląda”.
Automatyczne kontrole, ale zawsze uzupełniają ręczne.
Naprawić wady w odniesieniu do WCAG, dotkliwości i odtwarzania skryptu.