Dostępna strona używa semantycznego kodu, działa z klawiatury, ma widoczny fokus, wystarczający kontrast, zrozumiałe formularze i alternatywy tekstowe oraz przechodzi test manualny. Automatyczną kontrolę uzupełnia sprawdzenie kluczowych zadań, powiększenia i technologii asystujących, a także dostępny kanał zgłaszania barier.
Dostępność strony internetowej oznacza, że z treści i funkcji mogą korzystać osoby o różnych potrzebach związanych ze wzrokiem, słuchem, ruchem lub funkcjami poznawczymi. Pomaga także osobie z kontuzją ręki, korzystającej z urządzenia w pełnym słońcu, na małym ekranie lub przy wolnym połączeniu. Nie jest to dodatek na koniec projektu, lecz cecha projektu, kodu i treści.
Automatyczny skaner potrafi wykryć część problemów, ale nie zweryfikuje, czy kolejność fokusu jest logiczna, tekst alternatywny przydatny, a komunikat o błędzie zrozumiały. Dlatego łączy się kontrolę narzędziem, testy manualne oraz, w miarę możliwości, informacje zwrotne od osób korzystających z technologii asystujących. Obowiązki prawne są różne; konkretną zgodność należy poddać ocenie specjalisty.
Struktura semantyczna i zrozumiała treść
Używaj właściwych elementów dla nagłówków, akapitów, list, przycisków, linków i obszarów strony. Semantyka pomaga czytnikowi ekranu i wyszukiwarce zrozumieć relacje. Nagłówki powinny tworzyć logiczny konspekt bez pomijania poziomów tylko ze względu na wygląd. Przycisk ma wykonywać działanie, a link nawigować; element jedynie wizualnie naśladujący często nie zachowuje się poprawnie.
Pisz zwięźle, konkretnie i wyjaśniaj nietypowe pojęcia. Link w rodzaju „więcej informacji” jest poza kontekstem niejasny; nazwa usługi lub celu jest bardziej użyteczna. Długą treść podziel śródtytułami i listami. Instrukcje nie mogą opierać się wyłącznie na kolorze, położeniu lub kształcie, na przykład „kliknij zielony przycisk po prawej”.
Klawiatura, fokus i elementy interaktywne
Całą witrynę należy przejść klawiszami Tab i Shift+Tab. Fokus musi być widoczny, kolejność logiczna, a każdy element sterujący dostępny bez myszy. Użytkownik nie może utknąć w menu, oknie modalnym ani osadzonej treści. Link umożliwiający przejście bezpośrednio do treści głównej przyspiesza nawigację na stronach z powtarzającym się menu.
Własne elementy rozwijane, zakładki i okna dialogowe wymagają poprawnej obsługi z klawiatury i komunikowania stanu. Pierwszeństwo mają natywne elementy HTML, które już zapewniają wiele oczekiwanych zachowań. Po zamknięciu okna dialogowego przywróć fokus na element, który je otworzył. Automatycznego przenoszenia fokusu używaj tylko z wyraźnego powodu.
- wszystkie akcje dostępne bez myszy
- kontrastowy i stale widoczny fokus
- logiczna kolejność według treści
- brak pułapki klawiaturowej w komponencie
Formularze, błędy i weryfikacja danych wejściowych
Każde pole potrzebuje trwałej etykiety tekstowej programowo powiązanej z kontrolką. Placeholder nie jest jej zamiennikiem, ponieważ znika po rozpoczęciu pisania. O tym, że pole jest wymagane, i o oczekiwanym formacie należy poinformować z wyprzedzeniem. Grupy opcji powinny mieć nazwy, a przycisk wysyłający formularz konkretną etykietę, na przykład wyślij zapytanie.
Po błędzie należy wyświetlić podsumowanie oraz komunikat przy konkretnym polu i dokładnie wyjaśnić, jak go poprawić. Prawidłowo wprowadzone dane należy zachować. Czytnik ekranu musi otrzymać informację o nowym stanie, a fokus powinien zostać odpowiednio przeniesiony. Przy poważnej akcji należy umożliwić sprawdzenie lub poprawienie danych przed ostatecznym potwierdzeniem.
Treści wizualne, kontrast i multimedia
Tekst i elementy sterujące wymagają wystarczającego kontrastu we wszystkich stanach. Informacji nie należy przekazywać wyłącznie kolorem; błędne pole proszę uzupełnić ikoną lub tekstem. Strona musi pozostać użyteczna przy powiększeniu i wąskim widoku bez poziomego przewijania zwykłego tekstu. Proszę respektować ustawienie ograniczenia ruchu i unikać migania.
Tekst alternatywny opisuje cel obrazu w danym kontekście. Obraz dekoracyjny może być ignorowany przez technologie asystujące, a wykres wymaga tekstowego objaśnienia danych. Wideo należy uzupełnić napisami oraz, w zależności od treści, transkrypcją lub audiodeskrypcją. Automatyczne odtwarzanie dźwięku może znacząco przeszkadzać użytkownikowi i powinno być pod jego kontrolą.
Testowanie i dostępność jako proces
Zacznij od automatycznej kontroli, a następnie testuj klawiaturą, przy różnym powiększeniu, w trybie wysokiego kontrastu i przynajmniej podstawowo czytnikiem ekranu. Sprawdź reprezentatywne szablony i kluczowe procesy, nie tylko stronę główną. Każde ustalenie zapisuj z miejscem, wpływem, sposobem odtworzenia i zalecaną poprawką.
Kryteria dostępności należy uwzględnić w projekcie, bibliotece komponentów, odbiorze prac i szkoleniu z tworzenia treści. Po wprowadzeniu poprawki należy przeprowadzić test regresji. Deklaracja dostępności powinna odpowiadać rzeczywistemu stanowi i wskazywać sposób zgłaszania barier. Formalne obowiązki i poziom zgodności należy zweryfikować z wykwalifikowanym specjalistą, w zależności od organizacji i obowiązujących przepisów.
Dostępność w zamówieniach i pracy dostawców
Wymaganie dotyczące dostępności umieść w specyfikacji wraz z zakresem, sposobem weryfikacji i oczekiwanymi rezultatami. Ogólne zdanie „strona będzie dostępna” nie mówi, które szablony, dokumenty i komponenty zewnętrzne zostaną przetestowane. Poproś o demonstrację obsługi z klawiatury, formularzy i komponentów, a nie tylko o wynik skanera lub deklarację producenta. Uzgodnij poprawienie wykrytych problemów i przekazanie wyników testów. Przy zakupie czatu, systemu rezerwacji lub osadzanego widżetu sprawdź także jego dostępność, ponieważ bariera w kluczowej usłudze zewnętrznej szkodzi całej ścieżce użytkownika.
Proszę podzielić odpowiedzialność między projektowanie, rozwój, treści i administrację. Projektant określa kontrast i stany, programista semantykę i sterowanie, redaktor nagłówki i alternatywy, a właściciel produktu akceptację. Szkolenie powinno wykorzystywać Państwa rzeczywiste komponenty i system publikacji. Proszę utworzyć dostępny kanał zgłaszania problemów i reagować bez wymagania, aby użytkownik udowadniał swój stan zdrowia. W przypadku istotnej bariery należy zaproponować praktyczną alternatywę i zaplanować poprawkę. Wymagania umowne i prawne się różnią, dlatego ich zakres oraz formalne deklaracje powinien ocenić wykwalifikowany specjalista. Przy naprawie proszę ustalać priorytety według wagi i częstotliwości, ale krytyczną niemożność skorzystania z usługi rozwiązywać bez czekania na duży redesign. Poprawiony komponent należy dodać do wspólnej biblioteki, aby ta sama bariera nie powracała na kolejnych stronach.
- mierzalne kryteria bezpośrednio w zleceniu
- testowanie zewnętrznych komponentów krytycznych
- podzielona odpowiedzialność między rolami
- dostępny kanał zgłaszania barier
Najczęstsze pytania
Czy automatyczny test wystarczy do oceny dostępności?
Nie. Wychwyci jedynie część problemów technicznych. Logikę, obsługę za pomocą klawiatury, jakość tekstów alternatywnych i zrozumiałość trzeba zweryfikować ręcznie. Wynik automatycznego testu wymaga ponadto interpretacji w kontekście danego komponentu. Warto łączyć skaner, test klawiaturą, powiększenie, czytnik ekranu oraz test kluczowych zadań. W przypadku ważnej usługi cenna jest także informacja zwrotna od osób, które regularnie korzystają z technologii asystujących.
Czy dostępność pogorszy wygląd projektu?
Nie. Dobre ograniczenia prowadzą do bardziej czytelnego, spójnego i przewidywalnego designu. Kreatywność może pozostać bez tworzenia barier.
Kiedy zająć się dostępnością?
Od badań i projektowania, w trakcie rozwoju, a także przy tworzeniu treści. Późny audyt jest przydatny, ale poprawki bywają trudniejsze niż przy bieżącym testowaniu.
Źródła i dalsza lektura
- Profil Firmy w Google – popraw pozycję w wynikach lokalnych
- Wytyczne Google Business Profile
- Google Search Central
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
