Аудит доступності сайту за WCAG і виправлення проблем

У нас працює діючий сайт із кількома інтерактивними блоками (форми, каталог із фільтрами, модальний кошик), і ми жодного разу не перевіряли його на доступність. Нещодавно клієнт, який користується програмою читання з екрана, написав, що не зміг оформити замовлення, — і це змусило нас узятися за тему серйозно. Шукаю фахівця, який проведе аудит за WCAG 2.1 AA, чесно покаже слабкі місця й не просто віддасть перелік претензій, а реально виправить знайдене в наших шаблонах.

Робота ділиться на два зрозумілі етапи. Спершу структурований аудит: автоматичне сканування плюс ручна перевірка з клавіатури та хоча б одним справжнім скрінрідером на ключових сторінках (головна, каталог, картка товару, контентна сторінка і весь сценарій оформлення замовлення). Хочу отримати пріоритизований звіт, де блокери відокремлені від дрібниць, кожна проблема прив'язана до конкретного критерію успіху й має кроки відтворення, щоб розробники зрозуміли суть. Потім впровадження: ви вносите правки прямо в шаблони й підтверджуєте результат. Важливо зберегти зовнішній вигляд без змін і не зламати поточну поведінку.

Фронтенд — звичайний HTML, CSS і трохи ванільного JavaScript, важкі фреймворки не потрібні, але чекаю зваженого підходу: де доречний ARIA, а де краще нативна семантика. Надішліть короткий приклад минулого аудиту або зв'язку «до/після» й опишіть, як ви перевіряєте, що виправлення справді працює для допоміжних технологій.

— Аудит за WCAG 2.1 AA з автоінструментами та ручною перевіркою з клавіатури і скрінрідером
— Пріоритизований звіт: блокери й дрібниці, прив'язка до критеріїв, кроки відтворення
— Правка семантики, порядку заголовків, орієнтирів і підписів до полів форм
— Повна робота з клавіатури, видимий фокус і логічний порядок фокуса в модалках
— Виправлення колірного контрасту й додавання зрозумілих текстових альтернатив
— ARIA лише там, де нативний HTML не виражає потрібний патерн