GitHub представила плагин для GitHub Accessibility Scanner, который помогает оценивать и улучшать качество атрибутов alt у изображений на веб-страницах. Инструмент сочетает детерминированные проверки строк и опциональное использование модели компьютерного зрения через GitHub Models.
Поводом для работы над плагином стали данные отчета WebAIM Million 2026. По оценке WebAIM, у 16,2% изображений на главных страницах миллиона самых посещаемых сайтов вообще отсутствует alt-текст. Еще у 10,8% изображений он формальный и бесполезный — например, alt=”image”, имя файла или дублирование описания соседнего изображения.
Разработчики подчеркивают, что существующие автоматические проверки хорошо находят полностью отсутствующий alt-текст, но почти не помогают с его качеством. Большинство инструментов лишь проверяют наличие доступного имени, а не то, насколько оно информативно. Это осознанное решение: строгие правила с большим числом ложных срабатываний команды обычно отключают.
В плагине GitHub Accessibility Scanner проверки разделены на две группы: детерминированные правила, работающие только со строкой alt, и опциональное правило с участием модели, которая получает изображение вместе с контекстом страницы. Пять правил первой группы включены по умолчанию и не требуют сетевых запросов или доступа к ИИ. Модель используется отдельно и только по настройке.
Сначала команда решила, какие изображения вообще анализировать. Для этого применяется role-based локатор Playwright, а не простой перебор всех тэгов <img>. Элементы, которые не попадают в дерево доступности браузера, отбрасываются, включая изображения с alt=””. Пустой alt рассматривается как явный сигнал автора о декоративном характере иллюстрации, и плагин его сознательно не отмечает как ошибку.
Одна из детерминированных проверок ищет неинформативный alt-текст. Строка нормализуется и сравнивается с заранее подготовленным списком слов и фраз, которые сами по себе не несут полезного описания. Срабатывание происходит только при точном совпадении. Такой подход пропускает часть плохих описаний, но заметно снижает риск ложных срабатываний, что, по мнению авторов, важнее для реального использования.
Другой сценарий — повторяющийся alt-текст, например, пять иконок со звездами подряд, у каждой из которых alt=”3/5 stars”. Пользователь скринридера в таком случае слышит одно и то же сообщение несколько раз. Первая версия правила просто шла по изображениям в порядке документа и отмечала последовательности одинаковых alt. Это приводило к ошибкам: логотип GitHub в подвале и в шапке мог оказываться рядом в списке, хотя визуально элементы находятся в разных частях страницы.
В обновленной версии учитывается расположение на экране, а не только порядок в разметке. Плагин анализирует границы элементов (bounding boxes) и расширяет цепочку повторов только тогда, когда расстояние между соседними изображениями мало по сравнению с их размерами.
Для комплексной оценки качества alt-текста требуется контекст страницы, так как корректность описания зависит от окружения. Например, alt=”улыбающийся человек” может быть приемлем для фонової фотографии, но окажется слишком общим под заголовком, где упомянуто конкретное лицо. В опциональной проверке alt-text-qualitycheck плагин собирает для каждого изображения заголовок страницы, ближайший заголовок на странице, содержимое <figcaption>, до 600 символов соседнего текста, а также информацию о том, находится ли картинка внутри ссылки или кнопки.
Признак ссылки важен, потому что когда изображение — единственный контент ссылки, его alt становится доступным именем этой ссылки и должен описывать назначение перехода, а не саму картинку. Сейчас плагин фиксирует только факт нахождения внутри ссылки и не различает случай, когда картинка — единственное содержимое, поэтому для модели эти ситуации выглядят одинаково.
Собранный контекст вместе с alt-текстом и самим изображением отправляется в vision-модель через GitHub Models. По словам разработчиков, основные проблемы были связаны не с распознаванием изображений, а с тем, как модель оценивает текст. Первая версия склонялась предлагать альтернативные варианты даже для уже корректных описаний, так как на вопрос «можно ли сделать лучше» языковая модель почти всегда отвечает утвердительно. В итоге почти каждое изображение превращалось в предупреждение, и сигнал терял ценность.
Для настройки правил создан офлайн-инструмент оценки, построенный на базе материалов WebAIM, учебников W3C по изображениям и ресурса POET. Правило и этот тестовый контур используют один и тот же промпт, поэтому поведение в CI соответствует результатам офлайн-настройки. При этом инструмент проверяет только суждения модели, а не всю цепочку обработки, и идеальный результат в тестах не гарантирует, что конкретный случай дойдет до модели в реальном прогоне сканера.
Подключение внешней модели к анализу данных страницы потребовало продуманного дизайна потоков данных. Внешнему сервису отправляются только необходимые фрагменты, а исходный URL страницы и оригинальная HTML-разметка остаются внутри инфраструктуры сканера, чтобы разработчики могли найти и исправить проблемное изображение. При подключении Azure AI Vision для опционального OCR-предобработки байты изображений отправляются в дополнительный сервис, и это также учитывается в анализе потоков данных.
Отдельно команда отмечает стоимость вызовов модели. В типичном сценарии выполняется один запрос к модели на изображение в каждом прогоне, и на сайтах с большим количеством картинок именно это тратит основную часть ресурсов. Поэтому для таких проверок рекомендуют использовать расписание запусков, а не запускать их на каждый коммит.
Авторы формулируют общий подход: разделять проверки, которые могут строго доказать наличие проблемы, и проверки, которые лишь подозревают ее. Первая группа должна быть дешевой, предсказуемой и включенной по умолчанию. Вторая — опциональной, с формулировками в духе рекомендации, а не окончательного вердикта. При этом важно ориентироваться на фактический пользовательский опыт, а не только на структуру DOM: многое в плагине еще не учитывает, как именно человек без зрения воспринимает функциональность конкретного изображения.
Разработчики подчеркивают, что никакая модель не снимет с человека ответственность за финальную оценку смысла изображения. Автоматизация помогает выделить картинки, которые заслуживают повторной проверки специалистом по доступности, и уменьшить объем ручной работы.
Команда GitHub приглашает разработчиков попробовать alt-text-плагин в своих процессах сканирования доступности и просит сообщать о некорректных срабатываниях через issue с примером находки и, при возможности, ссылкой на затронутую страницу. Над плагином работали бывшие стажеры команды доступности GitHub Таарик Ашенафи и Кинан Чжоу.
Источник: инженерный блог GitHub.
