Opis projektu
PrzetłumaczoneMamy działającą stronę internetową z kilkoma interaktywnymi blokami (formularze, katalog z filtrami, modalny koszyk) i nigdy nie sprawdzaliśmy jej pod kątem dostępności. Ostatnio klient korzystający z czytnika ekranu napisał, że nie mógł zrealizować zakupu — i to skłoniło nas do poważnego potraktowania tematu. Szukam specjalisty, który przeprowadzi audyt WCAG 2.1 AA, uczciwie wskaże słabe punkty i nie tylko przekaże listę skarg, ale faktycznie naprawi problemy, które znaleźliśmy w naszych szablonach.
Praca dzieli się na dwa wyraźne etapy. Najpierw strukturalny audyt: automatyczne skanowanie plus ręczne testowanie klawiaturą i przynajmniej jeden prawdziwy czytnik ekranu na kluczowych stronach (strona główna, katalog, karta produktu, strona treści i cały proces realizacji zamówienia). Chcę priorytetowego raportu, w którym blokady są oddzielone od drobnych problemów, każdy problem jest powiązany z konkretnym kryterium sukcesu i zawiera kroki reprodukcji, aby programiści zrozumieli problem. Następnie wdrożenie: dokonujesz poprawek bezpośrednio w szablonach i weryfikujesz wyniki. Ważne jest, aby zachować niezmieniony wygląd wizualny i nie zakłócać obecnego zachowania.
Frontend to zwykły HTML, CSS i trochę czystego JavaScript; ciężkie frameworki nie są potrzebne, ale oczekuję przemyślanego podejścia: gdzie ARIA jest odpowiednia, a gdzie lepsza jest semantyka natywna. Wyślij krótki przykład wcześniejszego audytu lub parę przed/po i opisz, jak weryfikujesz, że poprawka faktycznie działa dla technologii wspomagających.
— Audyt zgodnie z WCAG 2.1 AA z narzędziami automatycznymi oraz ręcznym testowaniem klawiaturą i czytnikiem ekranu
— Priorytetowy raport: blokady i drobne problemy, mapowanie kryteriów, kroki reprodukcji
— Naprawa semantyki, kolejności nagłówków, punktów orientacyjnych i etykiet pól formularzy
— Pełna operacja za pomocą klawiatury, widoczne skupienie i logiczna kolejność skupienia w modalach
— Naprawa kontrastu kolorów i dodanie jasnych alternatyw tekstowych
— ARIA tylko tam, gdzie natywny HTML nie wyraża potrzebnego wzorca
Praca dzieli się na dwa wyraźne etapy. Najpierw strukturalny audyt: automatyczne skanowanie plus ręczne testowanie klawiaturą i przynajmniej jeden prawdziwy czytnik ekranu na kluczowych stronach (strona główna, katalog, karta produktu, strona treści i cały proces realizacji zamówienia). Chcę priorytetowego raportu, w którym blokady są oddzielone od drobnych problemów, każdy problem jest powiązany z konkretnym kryterium sukcesu i zawiera kroki reprodukcji, aby programiści zrozumieli problem. Następnie wdrożenie: dokonujesz poprawek bezpośrednio w szablonach i weryfikujesz wyniki. Ważne jest, aby zachować niezmieniony wygląd wizualny i nie zakłócać obecnego zachowania.
Frontend to zwykły HTML, CSS i trochę czystego JavaScript; ciężkie frameworki nie są potrzebne, ale oczekuję przemyślanego podejścia: gdzie ARIA jest odpowiednia, a gdzie lepsza jest semantyka natywna. Wyślij krótki przykład wcześniejszego audytu lub parę przed/po i opisz, jak weryfikujesz, że poprawka faktycznie działa dla technologii wspomagających.
— Audyt zgodnie z WCAG 2.1 AA z narzędziami automatycznymi oraz ręcznym testowaniem klawiaturą i czytnikiem ekranu
— Priorytetowy raport: blokady i drobne problemy, mapowanie kryteriów, kroki reprodukcji
— Naprawa semantyki, kolejności nagłówków, punktów orientacyjnych i etykiet pól formularzy
— Pełna operacja za pomocą klawiatury, widoczne skupienie i logiczna kolejność skupienia w modalach
— Naprawa kontrastu kolorów i dodanie jasnych alternatyw tekstowych
— ARIA tylko tam, gdzie natywny HTML nie wyraża potrzebnego wzorca
Rozwój stron internetowych Gotówka, Przelew bankowy
