dostępność nie bierze się z
zaznaczenia jednego checkboxa .
Dostosowanie strony do wymagań dostępności to nie nakładka, dodatkowy przycisk ani kilka automatycznych poprawek. To dedykowane prace projektowe i programistyczne, które wykonujemy bezpośrednio w serwisie.
W Red Wolf realizujemy wdrożenia w oparciu o wymagania WCAG na poziomie AA. Analizujemy stronę, określamy zakres niezbędnych zmian i wprowadzamy je w kodzie, strukturze oraz interfejsie.
Każda strona zostawia inne ślady. Dlatego nie mamy „pakietu WCAG”.
Zakres prac zależy od tego, jak została zbudowana strona, jakie posiada komponenty, jak rozbudowana jest jej struktura i jakie problemy z dostępnością występują w konkretnym serwisie.
Dlatego do wdrożeń WCAG podchodzimy indywidualnie.
Sprawdzamy stronę, identyfikujemy obszary wymagające zmian i na tej podstawie określamy zakres dedykowanych prac programistycznych oraz projektowych potrzebnych do dostosowania serwisu do poziomu AA.
Nie wypuszczamy automatu w teren. Każdy ślad sprawdzamy osobno.
Dostępność powinna być częścią strony, a nie warstwą położoną na niej.
Na rynku można znaleźć rozwiązania obiecujące dostępność po instalacji dodatkowej nakładki czy wtyczki.
My wybieramy inną drogę.
Jeżeli element strony wymaga poprawy, poprawiamy sam element. Jeżeli problem leży w strukturze, zmieniamy strukturę. Jeśli konieczna jest ingerencja w kod, wykonujemy odpowiednie prace programistyczne.
Dzięki temu dostępność nie funkcjonuje obok strony. Staje się częścią sposobu, w jaki strona została zbudowana.
Nie gonimy za trzema literami.
Pracujemy nad realnymi elementami serwisu.
Wdrożenie na poziomie AA może wymagać zmian w wielu warstwach strony — od jej struktury po sposób działania konkretnych komponentów.
W zależności od serwisu prace mogą obejmować między innymi:
To, czego nie widać,
może mieć ogromne znaczenie.
WCAG nie kończy się na kolorach, większej czcionce i alternatywnym opisie zdjęcia.
Duża część dostępności znajduje się pod powierzchnią interfejsu — w strukturze HTML, kolejności elementów, atrybutach, sposobie działania komponentów czy obsłudze strony z klawiatury.
Dlatego wdrożenie WCAG traktujemy również jako zadanie developerskie.
Użytkownik może tego kodu nigdy nie zobaczyć. Ale jego przeglądarka i technologie asystujące już tak.
Projekt może być początkiem
albo częścią większej trasy.
Dostępność dotyczy
całej drogi użytkownika.
Nagłówek może mieć odpowiedni kontrast, a mimo to formularz kontaktowy może być niedostępny. Menu może działać prawidłowo, podczas gdy popup blokuje możliwość dalszej nawigacji.
Dlatego nie patrzymy na stronę jak na zbiór pojedynczych ekranów.
Analizujemy komponenty i ścieżki, z których rzeczywiście korzysta użytkownik — od nawigacji, przez treści i elementy interaktywne, aż po formularze oraz wykonanie kluczowego działania.
Bo dostępny powinien być cały teren, a nie tylko główna ścieżka.
Nie liczymy WCAG od liczby łap.
Ani od liczby podstron.
Dwie strony o podobnej wielkości mogą wymagać zupełnie innego zakresu pracy.
Jedna może posiadać prostą strukturę i kilka powtarzalnych komponentów. Druga — niestandardowe menu, formularze, slidery, filtry, popupy i elementy tworzone przez zewnętrzne rozwiązania.
Dlatego wdrożenie WCAG wyceniamy po poznaniu serwisu i określeniu rzeczywistego zakresu prac.
Najpierw trop. Potem zakres. Dopiero później wycena.
Jak wygląda
wdrożenie WCAG?
Najczęstsze pytania
i odpowiedzi
Poznaj historie tych, z którymi przeszliśmy całą drogę.
Do jakiego poziomu WCAG dostosowujecie strony?
Czy wystarczy zainstalować wtyczkę WCAG?
Czy możecie dostosować już istniejącą stronę?
Czy WCAG oznacza zmianę wyglądu strony?
Czy wykonujecie prace programistyczne?
Czy WCAG można uwzględnić już podczas tworzenia nowej strony?
Nie znalazłeś odpowiedzi
na swoje pytanie?
Napisz do nas! Chętnie rozwiejemy
Twoje wątpliwości!
Ślady jakie zostawiliśmy.
Każdy projekt to inne wyzwanie.
Poznaj historie tych, z którymi przeszliśmy całą drogę.
