GitHub научил скринридеры читать таймлайны issue и PR как списки

GitHub 8 октября 2026 года сообщил в своём changelog, что скринридеры теперь могут перемещаться по таймлайнам issue и pull request как по списку. Когда пользователь движется по ленте, вспомогательная технология может объявить структуру списка, количество элементов и текущую позицию. Анонс короткий: в доступном фрагменте перечисление обрывается на запятой, поэтому полный перечень озвучиваемых параметров лучше сверять с оригиналом.

Что именно изменилось

Таймлайн в GitHub — это основная рабочая поверхность разработчика. Здесь лежат комментарии, ревью, ссылки на коммиты, смены статусов, упоминания и события автоматизации. В активном pull request такая лента легко разрастается до десятков и сотен записей. Зрячий пользователь оценивает её объём одним взглядом, по полосе прокрутки и визуальным разделителям. Пользователь скринридера такой возможности не имеет, ему нужны программные подсказки.

Теперь они есть. Таймлайн размечен как список, и при входе в него скринридер может сообщить, что это список, сколько в нём элементов и на каком из них находится фокус. Так пользователь сразу понимает масштаб обсуждения и не теряет ориентацию при переходе между записями.

Почему семантика списка важна

Список — один из самых давних и хорошо поддерживаемых паттернов веб-доступности. Популярные скринридеры умеют объявлять «список из N элементов», позволяют прыгать между списками и выходить из них. Если лента собрана из набора универсальных блоков, этих возможностей у пользователя нет: ему приходится читать всё подряд или полагаться на заголовки и ориентиры страницы.

Главная польза здесь в экономии времени и когнитивной нагрузки. Код-ревью и разбор багов построены на чтении длинных цепочек событий. Любая неопределённость в навигации умножается на каждый issue и PR, которые разработчик открывает за день.

Для справки, что известно из анонса:

• затронуты таймлайны issue и pull request;
• таймлайн доступен для навигации как список;
• озвучиваются структура списка, число элементов и текущая позиция;
• дата публикации — 8 октября 2026 года;
• источник — GitHub Changelog.

Чего в анонсе нет

Технических подробностей публикация не даёт. Неизвестно, какие именно атрибуты разметки использованы, как поддержка выглядит в NVDA, JAWS, VoiceOver или TalkBack и в каких браузерах поведение стабильно. Нет данных о том, как озвучиваются вложенные события, свёрнутые блоки, подгружаемые порции ленты и длинные цепочки комментариев с ответами. Эти сценарии чаще всего и ломают навигацию, даже когда базовая разметка корректна.

Нет и информации о том, затронуты ли другие списки платформы: обсуждения, уведомления, проверки CI. Судя по формулировке, речь именно о таймлайнах issue и PR.

Что проверить на практике

Командам, у которых есть разработчики с нарушениями зрения, стоит пройти типичный рабочий цикл с их обычной связкой скринридера и браузера. Открыть длинный PR с ревью и автоматическими событиями, пройти ленту сверху вниз, проверить объявление числа элементов и позиции. Отдельно посмотреть, как ведёт себя навигация после подгрузки новых записей и при раскрытии свёрнутых веток.

Тем, кто строит собственные расширения и userscript-надстройки для GitHub, полезно проверить, не нарушают ли они новую структуру: вставка элементов вне списка или замена контейнеров может свести улучшение на нет. Обнаруженные расхождения разумно отправлять в обратную связь GitHub, у платформы для этого есть канал по доступности.

Изменение небольшое, но касается ежедневного инструмента миллионов разработчиков. Подобные правки разметки редко попадают в заголовки, хотя именно они определяют, может ли человек с нарушением зрения полноценно участвовать в код-ревью.