Projektujemy i rozwijamy serwisy, które są dostępne od pierwszego wejścia - bez dodatkowych trybów, nakładek czy specjalnej wersji strony.
Łączymy UX, UI, front-end i testy tak, żeby dostępność była częścią całego serwisu, a nie poprawką dodawaną po wdrożeniu.
Możemy zaprojektować nowy serwis, poprawić istniejący albo wdrożyć zalecenia z audytu dostępności.
Od UX i treści, przez UI i interakcje, po kod front-endu i testy.
Użytkownik nie powinien szukać dodatkowego trybu, przełączać kontrastu ani uruchamiać specjalnej wersji strony. Dostępność powinna być częścią podstawowego projektu.
Dlatego wymagania standardu WCAG uwzględniamy już podczas pracy nad UX i UI - w strukturze strony, nawigacji, kolorach, typografii, formularzach i sposobie prezentowania informacji.
Sam projekt graficzny nie wystarczy. Front-end musi poprawnie przekładać jego strukturę na kod, który jest zrozumiały również dla przeglądarek, czytników ekranu i innych technologii wspomagających.
Znaczenie ma kolejność informacji w HTML, właściwe użycie nagłówków i znaczników, obsługa formularzy, przycisków, komunikatów oraz wszystkich elementów, z którymi użytkownik wchodzi w interakcję.
Widoczny focus jest potrzebny, ale dostępność interakcji nie kończy się na kolorowej ramce.
Użytkownik powinien cały czas wiedzieć, gdzie się znajduje, co się właśnie wydarzyło i jaki może wykonać następny krok. Dotyczy to menu, formularzy, wyszukiwarek, filtrów, komunikatów, okien dialogowych i innych elementów reagujących na jego działania.
Dobry serwis daje poczucie, że współpracuje z użytkownikiem.
Nawet poprawnie zbudowany serwis będzie trudny w użyciu, jeżeli komunikaty są nieprecyzyjne, zbyt długie albo napisane językiem, który utrudnia zrozumienie tego, co trzeba zrobić.
Dbamy więc nie tylko o wygląd i kod, ale również o sposób formułowania etykiet, instrukcji, błędów, potwierdzeń i innych komunikatów pojawiających się podczas korzystania z serwisu.
Strona nie powinna prowadzić użytkownika do miejsca, z którego nie wiadomo, co zrobić dalej. Sprawdzamy całe ścieżki: przejście przez nawigację, wyszukanie informacji, wypełnienie formularza, obsługę błędu czy wykonanie konkretnego zadania.
Łączymy testy eksperckie i automatyczne z testowaniem na urządzeniach oraz technologiach wspomagających. Automatyczny wynik jest dla nas jednym ze źródeł informacji, a nie odpowiedzią na pytanie, czy serwis rzeczywiście jest dostępny.
Nasi Klienci
WCAG daje wspólny punkt odniesienia dla projektu, kodu i treści. Dla nas ważne jest jednak to, jaki efekt te wymagania dają w praktyce, czy użytkownik rozumie stronę, potrafi się po niej poruszać i bez przeszkód wykonać to, po co na nią przyszedł.
Dlatego wymagania WCAG zawsze odnosimy do konkretnego serwisu, jego treści, komponentów i sposobu, w jaki korzystają z niego użytkownicy.
Dostępność uwzględniamy już na etapie architektury, UX i UI, a następnie sprawdzamy ją podczas wdrożenia i testów kolejnych komponentów.
Finalnie oddajemy serwis przygotowany technicznie do spełnienia wymagań dostępności. Dokumentujemy stan dostępności serwisu w raporcie z testów oraz przygotowujemy informacje potrzebne do deklaracji dostępności.
Nie zawsze potrzebna jest budowa nowej strony. Możemy pracować na istniejącym serwisie i poprawić elementy, które utrudniają korzystanie z niego.
Może to obejmować UX/UI, strukturę HTML, nawigację klawiaturą, formularze, komunikaty, komponenty interaktywne czy sposób prezentowania treści. Zakres ustalamy na podstawie rzeczywistych problemów serwisu.
Jeżeli masz już raport z audytu, możemy przełożyć jego zalecenia na konkretne zmiany w projekcie i kodzie.
Nie ograniczamy się do zamknięcia listy błędów. Sprawdzamy, jak dana poprawka wpływa na cały komponent i ścieżkę użytkownika, wdrażamy ją, a następnie ponownie testujemy działanie serwisu.
Regularnie audytujemy serwis, wprowadzamy poprawki i sprawdzamy najważniejsze elementy po zmianach.
Na bieżąco doradzamy zespołowi instytucji, omawiamy pojawiające się problemy i pomagamy podejmować decyzje dotyczące dostępności nowych treści, funkcji i komponentów.
Pomagamy też aktualizować deklarację dostępności i przygotować informacje potrzebne do sprawozdawczości.
W zespole CG2 pracuje 3 specjalistów ds. dostępności cyfrowej. Ich wiedzę wykorzystujemy na różnych etapach projektu - od UX i UI, przez front-end, po testowanie i późniejszy rozwój serwisu.
Jesteśmy partnerem rządowego programu Dostępność Plus. Dzięki temu dostępność nie jest u nas osobnym dodatkiem do projektu, tylko kompetencją, która realnie wpływa na sposób projektowania, wdrażania i utrzymywania serwisów.
Przy stałej współpracy wspieramy również zespoły naszych klientów: konsultujemy problemy, omawiamy nowe funkcje i pomagamy utrzymywać dostępność wraz z rozwojem strony.
Audyt pozwoli wskazać bariery, które rzeczywiście utrudniają korzystanie z serwisu. Sprawdzamy stronę automatycznie i ekspercko, testujemy najważniejsze ścieżki oraz działanie z technologiami wspomagającymi.
Na końcu otrzymujesz konkretne zalecenia. Możemy też od razu przejść do ich wdrożenia.
Nie. Część problemów można usunąć bez przebudowy całego interfejsu. Czasem wystarczy poprawić konkretne komponenty, kontrasty, formularze, nawigację lub sposób działania elementów interaktywnych.
Jeżeli problem wynika z samej konstrukcji UX lub UI, wtedy proponujemy zmianę projektu zamiast próbować naprawiać go wyłącznie w kodzie.
To zależy od skali serwisu, jego technologii i liczby problemów do usunięcia. Przy mniejszej stronie poprawki mogą być najbardziej opłacalnym rozwiązaniem. Przy dużym, starszym serwisie może się okazać, że ciągłe naprawianie kolejnych elementów będzie droższe niż przebudowa.
Najpierw oceniamy stan obecnej strony i zakres potrzebnych zmian. Dopiero wtedy możemy porównać oba scenariusze i wskazać rozwiązanie, które będzie rozsądniejsze finansowo i technicznie.
Tak. Problemem nie jest sama animacja czy interakcja, ale sposób, w jaki została zaprojektowana i zaimplementowana. Użytkownik powinien rozumieć, co dzieje się na stronie, mieć kontrolę nad jej działaniem i móc korzystać z funkcji również innymi metodami niż mysz.
Dostępność strony nie kończy się na jej interfejsie. Publikowane dokumenty również mogą tworzyć bariery. Możemy pomóc zespołowi uporządkować sposób ich przygotowywania i publikowania oraz wskazać, które materiały wymagają poprawy lub lepiej udostępnić także w formie treści HTML.
Najpierw sprawdzamy, nad którymi elementami mamy kontrolę. Dotyczy to np. map, systemów rezerwacji, płatności, odtwarzaczy czy innych osadzonych usług.
Jeżeli zewnętrznego rozwiązania nie możemy poprawić bezpośrednio, szukamy sposobu na ograniczenie bariery, przygotowanie dostępnej alternatywy albo zmianę integracji.
