
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.

Obsługa klawiaturą
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.

Audytujemy ekran po ekranie
Manualny przegląd każdego widoku: nawigacja klawiaturą, inspekcja kodu i pomiary kontrastu według WCAG 2.1 AA.

Audytujemy ekran po ekranie
Manualny przegląd każdego widoku: nawigacja klawiaturą, inspekcja kodu i pomiary kontrastu według WCAG 2.1 AA.

Priorytetyzujemy bariery
Każdy wykryty problem klasyfikujemy jako krytyczny, średni lub drobny i opisujemy kryteriami akceptacji — dzięki temu poprawka jest mierzalna i weryfikowalna.

Wdrażamy poprawki
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.

Testujemy i weryfikujemy
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.

Audytujemy ekran po ekranie
Manualny przegląd każdego widoku: nawigacja klawiaturą, inspekcja kodu i pomiary kontrastu według WCAG 2.1 AA.

Priorytetyzujemy bariery
Każdy wykryty problem klasyfikujemy jako krytyczny, średni lub drobny i opisujemy kryteriami akceptacji — dzięki temu poprawka jest mierzalna i weryfikowalna.

Wdrażamy poprawki
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.

Testujemy i weryfikujemy
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:
Uczestnik niewidomy
Bariery
Nad czym pracujemy
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:
Uczestniczka słabowidząca
Bariery
Nad czym pracujemy
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:
Uczestnik z niepełnosprawnością ruchową
Bariery
Nad czym pracujemy
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.
Aplikacja Administratora
Tworzysz i konfigurujesz całe wydarzenie — głosowania, agendę, uczestników, dodatkowe usługi. Uruchamiasz jednym kliknięciem.
