GitHub apprend aux lecteurs d'écran à lire les timelines des issues et des PR comme des listes

Le 8 octobre 2026, GitHub a indiqué dans son changelog que les lecteurs d'écran peuvent désormais parcourir les timelines des issues et des pull requests comme une liste. Lorsque l'utilisateur se déplace dans le fil, la technologie d'assistance peut annoncer la structure de la liste, le nombre d'éléments et la position courante. L'annonce est brève : dans le fragment disponible, l'énumération s'interrompt sur une virgule. Mieux vaut donc consulter l'original pour connaître la liste complète des paramètres annoncés.

Ce qui a changé

La timeline de GitHub est la principale surface de travail du développeur. Elle regroupe commentaires, revues, liens vers des commits, changements de statut, mentions et événements d'automatisation. Dans une pull request active, ce fil peut facilement atteindre des dizaines, voire des centaines d'entrées. Un utilisateur voyant en mesure l'ampleur d'un seul coup d'œil, grâce à la barre de défilement et aux séparateurs visuels. L'utilisateur d'un lecteur d'écran ne dispose pas de cette possibilité : il lui faut des repères programmatiques.

Ils existent désormais. La timeline est balisée comme une liste. À l'entrée, le lecteur d'écran peut signaler qu'il s'agit d'une liste, combien d'éléments elle contient et sur lequel se trouve le focus. L'utilisateur saisit ainsi immédiatement l'ampleur de la discussion et ne perd pas ses repères en passant d'une entrée à l'autre.

Pourquoi la sémantique de liste compte

La liste est l'un des patterns d'accessibilité web les plus anciens et les mieux pris en charge. Les lecteurs d'écran courants savent annoncer « liste de N éléments », permettent de sauter d'une liste à l'autre et d'en sortir. Quand le fil est construit à partir de blocs génériques, l'utilisateur perd ces possibilités : il doit tout lire à la suite ou s'appuyer sur les titres et les repères de la page.

Le principal bénéfice tient à l'économie de temps et à la réduction de la charge cognitive. La revue de code et l'analyse de bugs reposent sur la lecture de longues chaînes d'événements. Toute incertitude dans la navigation se multiplie par chaque issue et chaque PR que le développeur ouvre dans la journée.

Pour mémoire, voici ce que l'on sait de l'annonce :

• les timelines des issues et des pull requests sont concernées ;
• la timeline est navigable comme une liste ;
• la structure de la liste, le nombre d'éléments et la position courante sont annoncés ;
• la date de publication est le 8 octobre 2026 ;
• la source est le GitHub Changelog.

Ce que l'annonce ne dit pas

La publication ne donne aucun détail technique. On ignore quels attributs de balisage ont été utilisés, comment la prise en charge se présente dans NVDA, JAWS, VoiceOver ou TalkBack, et dans quels navigateurs le comportement est stable. Aucune donnée n'indique comment sont annoncés les événements imbriqués, les blocs repliés, les portions de fil chargées à la demande et les longues chaînes de commentaires avec réponses. Ce sont pourtant ces scénarios qui cassent le plus souvent la navigation, même quand le balisage de base est correct.

On ne sait pas non plus si d'autres listes de la plateforme sont concernées : discussions, notifications, vérifications CI. À en juger par la formulation, il s'agit bien des seules timelines des issues et des PR.

Que vérifier en pratique

Les équipes qui comptent des développeurs malvoyants ou aveugles gagneraient à parcourir un cycle de travail typique avec leur combinaison habituelle de lecteur d'écran et de navigateur. Il s'agit d'ouvrir une longue PR comprenant des revues et des événements automatiques, de parcourir le fil de haut en bas, puis de vérifier l'annonce du nombre d'éléments et de la position. Il faut aussi observer séparément le comportement de la navigation après le chargement de nouvelles entrées et lors du dépliage de branches repliées.

Pour ceux qui développent leurs propres extensions et surcouches userscript pour GitHub, il est utile de vérifier qu'elles ne perturbent pas la nouvelle structure : insérer des éléments en dehors de la liste ou remplacer des conteneurs peut annuler l'amélioration. Il est judicieux de transmettre les écarts constatés à GitHub, la plateforme disposant d'un canal de retours dédié à l'accessibilité.

Le changement est modeste, mais il touche l'outil quotidien de millions de développeurs. Ce type de correction de balisage fait rarement la une, alors que c'est précisément lui qui détermine si une personne malvoyante ou aveugle peut participer pleinement à la revue de code.