Что именно произошло за год
GitHub сообщает о нескольких конкретных шагах. В октябре 2025 года в Роли, Северная Каролина, прошёл первый Open Source Accessibility Summit совместно с конференцией All Things Open — однодневное мероприятие, объединившее специалистов по доступности, disability-активистов и open source-разработчиков. В мае 2026 года в штаб-квартире компании в Сан-Франциско прошёл хакатон по открытым ассистивным технологиям: участники работали над проектами от тактильных дисплеев Брайля до доступных маршрутизаторов и произношения слов в скринридерах.
Помимо мероприятий, GitHub запустил набор практических инструментов и документов:
- Open Source Accessibility organization — общая площадка для дорожной карты и коллаборации.
- Руководство по лучшим практикам — включает рекомендацию вести файл
ACCESSIBILITY.mdв репозитории и интегрировать проверки доступности в CI. - Accessibility Annotation Toolkit — открытый набор инструментов для Figma, который помогает дизайнерам аннотировать макеты с учётом доступности и передавать эти требования разработчикам.
- GitHub Accessibility Scanner — AI-сканер на основе GitHub Actions и GitHub Copilot, который ищет проблемы доступности, создаёт Issues и предлагает исправления.
Важная деталь: документация GitHub по доступности создаётся при участии людей с реальным опытом использования ассистивных технологий, включает инструкции по работе со скринридерами и объясняет, как использовать Copilot с учётом accessibility.
Как устроен AI-сканер — и что он не умеет
GitHub Accessibility Scanner — наиболее технически конкретный из анонсированных инструментов. По сути это GitHub Action, который сканирует страницы сайта или репозитория на наличие accessibility-барьеров, создаёт отслеживаемые Issues и может поручить GitHub Copilot предложить исправления в виде pull request.
Механика прямолинейна: сканер запускается вручную или автоматически по расписанию, обходит указанные URL-адреса, использует движок Axe для поиска нарушений, фиксирует находки в Issues. Если Issues закрыты и найдены снова при следующем прогоне, сканер их переоткрывает — если только разработчик не пометил их меткой wontfix, сознательно отказавшись от исправления.
Разработчики сами предупреждают в документации: сканер находится в публичной бете, и он «не может гарантировать полностью доступный код». Это честное предупреждение, и оно важно. Автоматические инструменты проверки доступности в принципе способны обнаружить лишь часть проблем — те, что поддаются формализации: отсутствующий атрибут alt, неправильная семантика, нехватка подписей у форм. Но они не способны оценить, насколько удобен интерфейс при навигации только с клавиатуры, логична ли последовательность элементов для пользователя скринридера или понятен ли контент человеку с когнитивными особенностями. Это требует ручного тестирования — с реальными инструментами и реальными людьми.
Инструменты в CI помогают ловить регрессии раньше: если разработчик случайно сломал что-то, что раньше работало, сканер это заметит. Но это другая задача, нежели «сделать продукт доступным». Разница между «не ухудшать» и «сделать хорошо» — существенная.
Что GitHub делает для accessibility и где у этого подхода пределы
| Инструмент / практика | Какую проблему решает | Чего не умеет |
|---|---|---|
| Accessibility Scanner (AI + CI) | Автоматически ловит формализуемые нарушения WCAG, создаёт Issues, предлагает черновые исправления | Не заменяет ручное тестирование со скринридером и реальными пользователями; находит только часть проблем |
| Annotation Toolkit для Figma | Помогает дизайнерам явно описывать требования доступности при передаче макетов разработчикам | Не гарантирует, что требования будут выполнены при реализации; требует дизайн-культуры в команде |
| ACCESSIBILITY.md и best practices | Снижает порог входа: даёт командам структуру для описания их позиции по доступности | Не создаёт культуру инклюзии сам по себе; зависит от того, читает ли его кто-то реально |
| Документация GitHub | Помогает людям с инвалидностью пользоваться самим GitHub; содержит рекомендации по Copilot | Охватывает только экосистему GitHub, не проекты сторонних разработчиков |
| Саммиты и хакатоны | Объединяют людей, создают живые связи между accessibility и open source сообществами | Разовые события; сами по себе не меняют практику тысяч независимых команд |
Где платформенный подход упирается в свои пределы
Всё перечисленное выше решает реальную проблему: трение. Если команде нужно настраивать сканер с нуля, писать документацию по доступности без шаблонов, разбираться с инструментами Figma самостоятельно — многие просто этого не делают. Снижение трения имеет ценность.
Но между «снизить барьер» и «решить проблему» — пропасть. Open source-проекты зачастую работают на нижних слоях технологического стека: библиотеки, фреймворки, дизайн-системы. Если они закладывают плохую базу доступности, сотни сайтов и приложений унаследуют эти проблемы вне зависимости от того, есть ли у них сканер в CI. Здесь платформенные инструменты бессильны без культурного сдвига внутри сообществ, которые эти проекты поддерживают.
Доступность по-прежнему оценивается через WCAG — набор рекомендаций, а не через единый показатель. Один и тот же интерфейс может формально «не нарушать» WCAG и при этом оставаться практически непригодным для реального пользователя с нарушением зрения или двигательными ограничениями. Инструментарий GitHub помогает командам работать с формальной стороной. Практическая сторона остаётся ответственностью людей.
Ещё один открытый вопрос: неизвестно, сколько сторонних open source-команд реально внедрили предложенные практики — файл ACCESSIBILITY.md, проверки в CI, аннотации в Figma. Отчёт GitHub говорит о прогрессе внутри его собственной экосистемы и на его мероприятиях. Это честно, но это не то же самое, что измеримое улучшение доступности в независимых проектах.
Что остаётся
Самое честное прочтение происходящего: GitHub пытается перевести доступность с уровня декларации на уровень инфраструктуры. Это не магия и не PR — это набор скучных, но полезных решений: шаблоны документов, Actions, Figma-тулкиты, организационные страницы для коллаборации. Такой подход может реально помочь командам, которые хотят работать над доступностью системно, но не знают, с чего начать.
Пределы здесь встроены в саму природу задачи. Автоматизация не снимает ответственности с людей. Инструмент, который предлагает исправление через Copilot, всё равно требует человека, который понимает, правильное ли это исправление. Мероприятие, которое объединяет сообщество, всё равно требует, чтобы это сообщество после него продолжало работать.
Accessibility в open source — это не задача, которую можно «решить» с помощью платформы. Это непрерывная культурная и техническая практика. GitHub делает часть этой практики дешевле и доступнее. Это хорошо. Но это только часть.
