accessibility-auditor

Этот навык TerminalSkills помогает проводить прикладной аудит доступности HTML, JSX, Vue и Svelte без привязки к конкретному UI-фреймворку. Его базовая цель — найти нарушения и подготовить исправления в соответствии с WCAG 2.2, обычно на уровне AA. Он подходит для проверки отдельного компонента, страницы или более крупного интерфейса, а перед началом аудита предлагает определить область проверки, требуемый уровень A/AA/AAA и связанные требования вроде EAA, ADA или Section 508. Такой выбор важен: один и тот же результат нельзя автоматически считать проверкой всех нормативных режимов. Проверка начинается со структуры документа. Навык ищет логичную последовательность заголовков h1–h2–h3, корректные landmark-области main, nav, header, footer и aside, настоящие списки вместо стилизованных div и таблицы с заголовками th, scope и при необходимости caption. Отдельно оценивается порядок чтения: он должен совпадать с визуальным и не ломаться из-за CSS или перестановки интерактивных элементов. Эти проверки помогают обнаружить проблемы, которые не всегда видны при обычном просмотре страницы. Для текстовых альтернатив аудит проверяет meaningful alt у изображений, пустой alt или presentation для декоративной графики, title или aria-label у SVG, расширенное описание для сложных диаграмм и наличие captions и transcript у видео и аудио. В цветовой части нужно вычислять реальный контраст: для обычного текста ориентиром служит 4.5:1, для крупного текста 3:1, а для интерфейсных компонентов и графических объектов — 3:1. Информация не должна передаваться только цветом. Поэтому рекомендация должна опираться на конкретный элемент и измерение, а не на субъективное впечатление о том, что цвет выглядит достаточно тёмным. Клавиатурный аудит проверяет достижимость всех интерактивных элементов через Tab, отсутствие ловушек, видимый focus indicator и корректные обработчики Enter, Space и стрелок в кастомных компонентах. Для модальных окон важны захват и возврат фокуса, а skip-to-content помогает быстро перейти к основному содержимому. Отдельная группа правил касается ARIA: роли должны соответствовать поведению, обязательные атрибуты вроде aria-expanded должны присутствовать у управляющих элементов, динамические изменения должны объявляться через подходящие aria-live-области, а избыточные роли не должны маскировать нативный button или другой семантический элемент. Формы проверяются на связанные label, autocomplete для распространённых полей, программную связь ошибок с input, обозначение обязательности не только цветом и объявление ошибок вспомогательным технологиям. Для каждой найденной проблемы навык рекомендует фиксировать номер и название критерия WCAG, тяжесть Critical/Major/Minor, элемент или CSS-селектор, конкретное нарушение, точное изменение кода и затронутую группу пользователей — например, людей со screen reader, клавиатурной навигацией или сниженным зрением. Такой формат превращает список наблюдений в задачу для разработчика, которую можно повторно проверить. Это инструмент аудита, а не сертификат соответствия. Он не запускает автоматически полноценную юридическую экспертизу, не гарантирует доступность всего приложения и не отменяет ручную проверку. Источник отдельно предупреждает, что автоматические проверки находят лишь часть проблем; после исправлений нужны ручная навигация с клавиатуры, проверка реального фокуса, тестирование screen reader и осмотр динамических состояний. Для контрастов следует считать фактические значения, а для ARIA — сверяться с устойчивыми паттернами WAI-ARIA. Итог нужно привязывать к конкретному коду и версии интерфейса, иначе рекомендации быстро потеряют проверяемость.