Zacznij od wyboru użytkownika i systemu tokenów
Użyj ustawienia systemowego jako domyślnego z prefers-color-scheme. Jeśli oferujesz przełącznik, zastosuj kontrolkę obsługiwaną z klawiatury z dostępną nazwą i udostępnij aktywny wybór programowo. Nadpisanie ręczne ma mieć pierwszeństwo w kontekście przeglądarki; nie obiecuj, że będzie podążać za użytkownikiem na inne urządzenie lub do prywatnej sesji.
Nazywaj kolory według roli, nie wyglądu: canvas, surface, text, muted text, border, link, accent, error, success, focus i disabled. Zmapuj każdą rolę dla obu motywów. To zapobiega przeciekaniu jasnoszarych wartości z trybu jasnego do ciemnego i sprawia, że poprawki są wielokrotnego użytku. Ciemny motyw nie jest z definicji bardziej dostępny ani uniwersalnie preferowany; to inne doświadczenie, które trzeba uczynić użytecznym.
Udokumentuj kolejność, np. zapisany wybór najpierw, preferencja systemowa jako druga, żeby zespoły testowały ten sam rezultat.
Uwzględnij stany hover, focus, selected, invalid, disabled, loading, empty i visited-link, a nie tylko wartości domyślne.
Mierz kontrast w renderowanym motywie
Kryterium sukcesu WCAG 2.2 1.4.3 określa minimum 4.5:1 dla zwykłego tekstu i obrazów tekstu oraz 3:1 dla dużego tekstu. Nie zaokrąglaj: 4.499:1 nie spełnia 4.5:1. Cienkie kroje mogą wyglądać słabiej niż ich obliczony kolor, więc użyj solidniejszego kroju lub zwiększ marginesy.
Sprawdź każdy renderowany kolor pierwszoplanowy i sąsiednie tło. Tekst na zdjęciach, gradientach, półprzezroczystych panelach lub wideo ma zmienne tło, więc pojedyncze obliczenie tokenu nie udowodni czytelności. Użyj nieprzezroczystego podkładu, odpowiedniej nakładki lub innego umiejscowienia, a następnie sprawdź w realistycznych viewportach.
Zgodnie z WCAG 2.1 Kryterium sukcesu 1.4.11, informacja wizualna niezbędna do zidentyfikowania aktywnej kontrolki, wymaganego stanu lub znaczącej grafiki wymaga 3:1 względem sąsiednich kolorów.
Połącz zmiany koloru z tekstem, ikoną, wzorem, pozycją lub inną wyraźną wskazówką; stany błędu i wybrane nie powinny polegać na subtelnym odcieniu.
Chroń fokus klawiatury, formularze i zmiany stanów
Przejdź tabulatorem przez oba motywy. Fokus musi być widoczny na linkach, przyciskach, polach wejścia, menu, dialogach, niestandardowych widgetach i kontrolce motywu. Nie usuwaj obrysu przeglądarki, chyba że jego zamiennik został przetestowany na każdej powierzchni i w każdym stanie. Przesunięty obrys często jest czytelniejszy niż rozmyty glow, który się zlewa.
Pojawienie się fokusu (Focus Appearance) opisane w WCAG 2.2 jest kryterium AAA, a nie dowodem, że strona spełnia poziom AA. To jednak użyteczny cel: obszar wskaźnika co najmniej wielkości 2 CSS-pikselowego obwodu oraz kontrast 3:1 między pikselami skupionymi i nieskupionymi. Zweryfikuj też, że stany błędu, wymagane, wybrane i niedostępne zachowują sens.
Testuj osobno podpowiedź w polu, wprowadzaną wartość, etykietę, tekst pomocniczy, tekst błędu, nieprawidłową obwódkę, znacznik checkboxa, wybór radio i stan wysyłki.
Dla realizacji zamówienia lub innego przepływu regulowanego użyj sandboxu dostawcy i uzyskaj kwalifikowany przegląd dostępności i bezpieczeństwa tam, gdzie to stosowne. To wskazówka edukacyjna, a nie ocena zgodności czy bezpieczeństwa.
Obsługuj obrazy, osadzone zasoby i UI dostarczane przez przeglądarkę
Przejrzyj logotypy, ilustracje, zrzuty ekranu, wykresy, ikony i tekst wypieczony w obrazach w obu motywach. Ponownie użyty jasny logotyp może zniknąć, a legenda wykresu może przestać działać nawet gdy otaczające HTML przechodzi testy. Dostarcz zasób dopasowany do celu lub stabilne tło. Obrazowość, która przekazuje instrukcje, status lub dane, musi pozostać zrozumiała.
Zadeklaruj obsługę schematu light i dark, a następnie wystylizuj zawartość strony dla wybranego motywu. Właściwość color-scheme wyrównuje canvas przeglądarki, paski przewijania, kontrolki formularzy i inne UI przeglądarki. Umieść odpowiadające metadane wcześnie w dokumencie. Osadzone SVG mogą reagować na motyw rodzica; testuj iFrame'y i widgety stron trzecich end-to-end.
Preferuj semantyczne elementy HTML. Forced-color zachowuje się lepiej z natywną semantyką, a nie z rolą ARIA dodaną do ogólnego elementu.
Sprawdź pobierane, zbuforowane, wolno ładujące się i stany błędów obrazów, zwłaszcza tam gdzie tekst lub wskazówki akcji znajdują się nad mediami.
Szanuj forced-colors i testuj wydanie jako system
Tryb forced-colors stosuje ograniczoną, wybraną przez użytkownika paletę, taką jak Windows High Contrast. Przeglądarki mogą zastępować kolory, usuwać cienie i dodawać podkłady tekstu. Nie blokuj nadpisania. Wprowadzaj ukierunkowane poprawki tam, gdzie komponent traci granicę lub sens, np. rzeczywistą obwódkę tam, gdzie wcześniej affordance dawał cień. Emulacja nie odwzoruje każdego urządzenia, przeglądarki, rozszerzenia, poziomu powiększenia ani kombinacji technologii pomocniczych.
Uruchom macierz tras i interakcji w ustawieniach light, dark i forced-colors przed wydaniem. Chrome DevTools może emulować oba stany; użyj go do przyspieszenia przeglądu, a następnie ręcznie przejdź priorytetowe przepływy. Skanery znajdują kandydatów, ale nie mogą same stwierdzić dostępności. SIU wykonuje preflighty krytycznych zasobów motywu i interakcji, zapisuje bramkę wydania i utrzymuje testowalną ścieżkę rollbacku dla poważnych regresji prezentacji; nie jest to monitorowanie przestoju.
Uwzględnij landing, nawigację, wyszukiwanie, dostęp do konta, formularze, strony błędów, ekrany po zalogowaniu i przepływy konwersji materiału.
Zapisz przetestowane adresy URL, wersje przeglądarek, ustawienia, wyjątki, właściciela i wyzwalacz rollbacku, aby naprawa zaczynała się od faktów.