Audytujemy ekran po ekranie
Manualny przegląd każdego widoku: nawigacja klawiaturą, inspekcja kodu i pomiary kontrastu według WCAG 2.1 AA.
Chcemy, aby w głosowaniu mógł wziąć udział każdy uczestnik — niezależnie od sprawności wzroku, słuchu czy ruchu. Dlatego obie aplikacje Wyborka budujemy zgodnie z wytycznymi WCAG 2.1, a większość rozwiązań dostępnościowych jest już wdrożona i działa na co dzień.
Dostępność jest u nas częścią produktu, nie dodatkiem. Kluczowe ekrany obu aplikacji są już zgodne z wytycznymi WCAG 2.1, cały czas audytujemy ekrany, mierzymy kontrasty i testujemy aplikację z czytnikami ekranu.
Dążymy do tego, aby każdą funkcję — od dołączenia do wydarzenia po oddanie głosu — dało się wykonać bez użycia myszy. Sprawdzamy każdy ekran pod kątem pułapek klawiaturowych i logicznej kolejności tabulacji.
Cztery powtarzalne etapy, które przechodzimy dla każdego ekranu aplikacji — od audytu po testy z czytnikami ekranu.
Manualny przegląd każdego widoku: nawigacja klawiaturą, inspekcja kodu i pomiary kontrastu według WCAG 2.1 AA.
Manualny przegląd każdego widoku: nawigacja klawiaturą, inspekcja kodu i pomiary kontrastu według WCAG 2.1 AA.
Każdy wykryty problem klasyfikujemy jako krytyczny, średni lub drobny i opisujemy kryteriami akceptacji — dzięki temu poprawka jest mierzalna i weryfikowalna.
Zmiany trafiają do aplikacji w kolejnych wydaniach: od hierarchii nagłówków i etykiet pól, przez kontrasty, po mechanizmy pomijania powtarzających się bloków.
Po wdrożeniu każdą poprawkę sprawdzamy ponownie względem kryteriów z audytu — nawigację klawiaturą, semantykę dla czytników i kontrast. Ekran wraca do testów, aż spełni wszystkie wymagania WCAG 2.1 AA.
Manualny przegląd każdego widoku: nawigacja klawiaturą, inspekcja kodu i pomiary kontrastu według WCAG 2.1 AA.
Każdy wykryty problem klasyfikujemy jako krytyczny, średni lub drobny i opisujemy kryteriami akceptacji — dzięki temu poprawka jest mierzalna i weryfikowalna.
Zmiany trafiają do aplikacji w kolejnych wydaniach: od hierarchii nagłówków i etykiet pól, przez kontrasty, po mechanizmy pomijania powtarzających się bloków.
Po wdrożeniu każdą poprawkę sprawdzamy ponownie względem kryteriów z audytu — nawigację klawiaturą, semantykę dla czytników i kontrast. Ekran wraca do testów, aż spełni wszystkie wymagania WCAG 2.1 AA.
Realne sytuacje uczestników wydarzeń, dla których usuwamy bariery.
Przykładowy scenariusz:
Bariery
Nawigacja
wyłącznie słuchowa
Obrazy
wymagają opisów
Zmiany na ekranie
muszą być ogłaszane
Nad czym pracujemy
Etykiety pól
powiązane z polami
Role i stany
komunikowane przez ARIA
Wyniki głosowań
ogłaszane na bieżąco
Czytnik ekranu
VoiceOver
NVDA
Dołącza do wydarzenia i głosuje z czytnikiem ekranu — struktura strony i formularze są czytane w logicznej kolejności.
Przykładowy scenariusz:
Bariery
Mały tekst
nieczytelny
Niski kontrast
niewidoczne linki
Fokus
łatwo go zgubić
Nad czym pracujemy
Kontrast tekstu
min. 4.5:1
Zoom 200%
bez utraty treści
Fokus
widoczny na każdym elemencie
Powiększenie 200%
Kontrast
Widoczny fokus
Powiększa interfejs do 200% i potrzebuje wyraźnych kontrastów, aby samodzielnie oddać głos.
Przykładowy scenariusz:
Bariery
Mysz
niedostępna
Złożone gesty
niewykonalne
Małe przyciski
trudne do trafienia
Nad czym pracujemy
Pełna obsługa
z klawiatury
Pułapki fokusowe
eliminowane
Cele dotykowe
min. 44×44 px
Klawiatura
Bez złożonych gestów
Duże cele dotykowe
Obsługuje całe wydarzenie wyłącznie klawiaturą — od dołączenia po oddanie głosu.
Nad dostępnością pracujemy równolegle w aplikacji uczestnika (PWA) i administratora (CRM) — usuwamy bariery tam, gdzie realnie napotykają je użytkownicy.
Tworzysz i konfigurujesz całe wydarzenie — głosowania, agendę, uczestników, dodatkowe usługi. Uruchamiasz jednym kliknięciem.
