Deklaracja dostępności
Alcometer.org dąży do tego, aby kalkulator stężenia alkoholu we krwi, treści o kacu, regeneracji i nawodnieniu były dostępne dla jak najszerszego grona użytkowników, w tym osób z różnicami wzrokowymi, motorycznymi, słuchowymi, poznawczymi i neurologicznymi.
Cel zgodności
Dążymy do zgodności z Web Content Accessibility Guidelines (WCAG) 2.2 na poziomie AA, publikowanymi przez W3C. Ten cel jest zgodny z EN 301 549 i Europejskim Aktem o Dostępności, przy czym WCAG 2.1 AA traktujemy jako minimalny poziom kompatybilności.
Repozytorium zawiera wykonywalny baseline axe-core i Puppeteer dla głównych tras narzędzi Alcometer. Kolejne poprawki mają usuwać znane problemy bez wprowadzania regresji.
Znane luki opisujemy poniżej i traktujemy je jako obszary do ręcznej oraz automatycznej weryfikacji przed bramką launch.
Aktualny zakres testów automatycznych
Projekt uruchamia npm run test:alcometer:a11y: buduje stronę, startuje Astro preview, otwiera wybrany zestaw tras narzędzi, wstrzykuje axe-core przez @axe-core/puppeteer i sprawdza tagi wcag2aa oraz wcag22aa.
Bieżący baseline znajduje się w test/a11y-baseline.json, a najnowszy raport jest zapisywany w reports/a11y-run.json. Baseline śledzi istotne i krytyczne ustalenia, aby kolejne commity mogły wykazać brak regresji.
Zadanie dostępności w GitHub Actions pozostaje nieblokujące do czasu końcowej bramki launch i publikuje baseline oraz raport jako artefakty do przeglądu.
Co to oznacza w praktyce
• Kontrolki interaktywne powinny używać natywnych elementów HTML tam, gdzie to możliwe, z widocznym fokusem i obsługą klawiatury.
• Wizualizacje SVG i wykresy powinny mieć równoważny opis tekstowy albo tabelaryczny, jeśli przenoszą istotną informację.
• Okna dialogowe muszą zachowywać logiczną kolejność fokusu i zapewniać jasną ścieżkę wyjścia.
• Język dokumentu jest deklarowany na każdej wygenerowanej stronie przez atrybut <html lang>.
Znane ograniczenia
Pierwszy baseline axe-core nadal może zawierać ustalenia istotne lub krytyczne, które są obsługiwane w kolejnych poprawkach. Do czasu końcowej bramki runner blokuje regresje względem baseline zamiast deklarować brak wszystkich ustaleń.
Część wizualizacji danych ma już alternatywy dla czytników ekranu, ale kopie wykresów i parytet językowy nadal wymagają ręcznego przeglądu z technologiami wspomagającymi.
Języki pisane od prawej do lewej nie mają jeszcze dedykowanych układów RTL; treść korzysta z dostępnej powłoki LTR, jeśli taka jest obecnie obsługiwana.
Jak testujemy
• Automatycznie: axe-core przez @axe-core/puppeteer na Astro preview, w zakresie tagów wcag2aa i wcag22aa.
• Raport regresji: reports/a11y-run.json.
• Zamrożony baseline: test/a11y-baseline.json.
• Ręczny przegląd nadal jest potrzebny dla przepływu klawiatury, treści dla czytników ekranu, jasności poznawczej, zoomu i regresji wizualnych.
Narzędzia automatyczne wykrywają tylko część zgodności z WCAG. Przegląd człowieka jest wymagany przed launch, szczególnie dla kalkulatora, bramki zgodności i stron z wykresami.
Kontakt i uwagi
Jeśli napotkasz barierę dostępności, na przykład brak opisu alternatywnego, pułapkę klawiatury, problem z kontrastem, niejasną kolejność fokusu albo inną trudność, skontaktuj się z nami.
Email: alcometer@wp.pl
Adres pocztowy: Piotr Zieminski, Kalonka 71a, Polska
W zgłoszeniu podaj: (1) adres URL, którego dotyczy problem, (2) krótki opis bariery, (3) używaną technologię wspomagającą, jeśli ma znaczenie.
Egzekwowanie
Jeśli odpowiedź nie będzie satysfakcjonująca, sprawę można przekazać właściwemu krajowemu organowi egzekwującemu przepisy Europejskiego Aktu o Dostępności. W Polsce jest to Urząd Komunikacji Elektronicznej (UKE, https://www.uke.gov.pl/).
Przygotowanie deklaracji
Deklarację zaktualizowano 25 kwietnia 2026 r. po dodaniu baseline axe-core i nieblokującego zadania CI dla dostępności.
Następny przegląd zaplanowano na 25 kwietnia 2027 r. albo wcześniej, jeśli istotnie zmienią się szablony stron, UI kalkulatora lub narzędzia dostępności.