Description de l’image : une salle de conférence avec une diapositive projetée et un ordinateur portable affichant le plan d’ordre de lecture du diaporama — le repère visuel de la production de présentations accessibles.
Temps de lecture : 12 minutes
Les diaporamas restent l’artefact pédagogique le plus partagé de la vie professionnelle moderne — notes de cours, mises à jour pour les conseils d’administration, modules de formation, conférences, réunions générales internes. Ils sont aussi, presque sans exception, l’artefact le moins accessible de ce même pipeline. Une présentation que les lecteurs d’écran ne peuvent pas naviguer, un diaporama dont les valeurs de graphiques n’existent qu’en pixels, un clip vidéo intégré sans sous-titres, une interaction « cliquer pour avancer » ignorant le clavier : chacun de ces défauts est courant, et chacun exclut discrètement le même groupe de personnes du même contenu que reçoit le reste du public. La bonne nouvelle, c’est qu’en 2026 résoudre ce problème n’est plus une question de recherche. C’est un problème de flux de travail de production, avec trois bonnes réponses et un arbre de décision pour choisir entre elles.
Ce guide couvre les trois familles d’outils qu’un présentateur en exercice a réellement sur son bureau — Microsoft PowerPoint, Apple Keynote et Google Slides — ainsi que l’alternative web-first de plus en plus sérieuse (Reveal.js, Slidev, Marp) que les enseignants et les organisateurs de conférences ont commencé à privilégier. Ce n’est pas une comparaison abstraite de fonctionnalités. C’est un guide de production : quelles étapes effectuer, dans quel ordre, dans quel outil, pour livrer un diaporama qu’un étudiant aveugle peut suivre avec NVDA, qu’un collègue malvoyant peut lire à 400 % de zoom, qu’un participant sourd peut lire grâce aux sous-titres intégrés, et qu’un utilisateur limité au clavier peut naviguer sans jamais toucher une souris. Pour le contexte normatif plus large, voir notre guide sur l’adoption de WCAG 2.2 et sur l’Acte européen sur l’accessibilité (EAA), qui s’appliquent désormais aux contenus éducatifs et commerciaux distribués en ligne sous forme de diaporamas.
Ce que doit comporter un diaporama accessible
Avant les flux de travail spécifiques à chaque outil, un niveau de référence. Un diaporama accessible requiert six éléments fonctionnant simultanément, et aucun n’est optionnel. Le premier est un titre unique et descriptif sur chaque diapositive — c’est ce qu’utilise un utilisateur de lecteur d’écran pour naviguer de diapositive en diapositive, et ce sur quoi s’appuie un utilisateur du volet de plan pour trouver la diapositive recherchée. Les diapositives intitulées « Diapositive 4 » ou « Sans titre » sont non navigables. Le deuxième est un ordre de lecture correct. Les diapositives construites en déposant des formes sur une zone de dessin sans utiliser les zones de texte réservées auront un ordre de lecture correspondant à l’ordre d’insertion des formes, et non à l’ordre visuel — ce qui signifie qu’un lecteur d’écran lira une diapositive à l’envers, en commençant par la barre latérale, le pied de page avant le titre, ou dans l’ordre quelconque qu’a produit le processus de production. Le troisième est un texte alternatif pour chaque image, graphique et diagramme non décoratif, rédigé dans un langage qui communique le point que l’image illustre, pas seulement sa description de surface.
Le quatrième est un contraste des couleurs suffisant — texte sur fond de diapositive au seuil AA de WCAG 2.2 (4,5:1 pour le texte courant, 3:1 pour le texte large et les éléments graphiques significatifs), vérifié par rapport aux pixels réels de l’arrière-plan et non par rapport au masque de diapositive. Le cinquième est la navigabilité au clavier — tout élément interactif qu’un présentateur s’attend à voir utilisé par le public ultérieurement (liens vers des sondages intégrés, navigation par branchement, formulaires intégrés) doit être accessible et utilisable avec Tab, Entrée, Espace et Échap uniquement. Le sixième est la gestion des médias — tout clip vidéo intégré comporte soit des sous-titres ouverts incrustés dans le fichier, soit une piste de sous-titres fermés que le lecteur peut activer ; tout clip audio intégré dispose d’une transcription accessible depuis la même diapositive ; toute animation non strictement nécessaire respecte la préférence de réduction de mouvement de l’utilisateur au niveau du système d’exploitation.
Chacun des trois outils de bureau fournit un sous-ensemble de ces six éléments. Aucun d’eux ne les fournit tous automatiquement. Choisir le bon outil implique de comprendre ce que vous devez faire manuellement dans chacun d’eux.
Flux de travail PowerPoint
PowerPoint dispose de l’outillage d’accessibilité le plus mature de toute application de présentation sur le marché, et ce depuis que le cycle de publication Microsoft 365 a commencé à intégrer le vérificateur d’accessibilité dans le ruban. Le point de départ est le vérificateur lui-même, accessible depuis l’onglet Révision sous Windows ou le menu Outils sur macOS. Il affiche une liste contextuelle en temps réel des problèmes — diapositives sans titre, images sans texte alternatif, combinaisons de texte à faible contraste, tableaux sans en-têtes, hyperliens dont le texte visible duplique l’URL — et cliquer sur n’importe quel problème positionne le curseur sur l’élément concerné. Le vérificateur s’exécute à chaque enregistrement par défaut dans les versions récentes, ce qui est le paramètre par défaut le plus utile que Microsoft ait livré dans ce produit. Ne le désactivez qu’après avoir compris quels avertissements vous choisissez d’ignorer.
Les titres de diapositives sont gérés via le mode Plan (Affichage, Plan) et via l’espace réservé Titre du masque de diapositive. Utiliser l’espace réservé plutôt qu’une zone de texte flottante est ce qui donne au titre son rôle sémantique — le vérificateur d’accessibilité et les lecteurs d’écran en aval identifient les diapositives titrées par l’identité de l’espace réservé, pas par le texte visible. Si les titres de votre diaporama sont composés à l’aide de zones de texte flottantes pour des raisons de conception, vous pouvez conserver le design mais ajouter un titre d’espace réservé invisible en déplaçant l’espace réservé hors de la zone de dessin (Volet de sélection, définir la position en coordonnées négatives) — le titre existe toujours dans l’arbre d’accessibilité et compte pour la navigation au lecteur d’écran, même si le public ne le voit jamais. La documentation Microsoft décrit ce procédé comme le modèle du « titre hors diapositive » ; le vérificateur l’accepte.
L’ordre de lecture est le deuxième pilier. Ouvrez le Volet de sélection (Accueil, Organiser, Volet de sélection sous Windows ; menu Organiser sur macOS) et lisez la liste des formes de bas en haut — c’est l’ordre dans lequel un lecteur d’écran les rencontrera. Faites glisser les formes dans le volet pour les réorganiser. PowerPoint 2024 a ajouté un volet Ordre de lecture dédié qui visualise l’ordre numériquement sur chaque forme de la diapositive et permet de réorganiser par glisser-déposer directement sur la zone de dessin ; si votre version de Microsoft 365 est suffisamment récente pour afficher ce volet, utilisez-le de préférence.
Le texte alternatif des images se définit en faisant un clic droit sur l’image, en choisissant Modifier le texte de remplacement, et en rédigeant une à deux phrases de texte alternatif éditorial — le point de l’image, pas son contenu en pixels. Le texte alternatif généré automatiquement par PowerPoint est optionnel et clairement indiqué comme tel dans le volet ; c’est un point de départ, pas un produit fini, et le vérificateur vous avertira si vous livrez une diapositive dont le seul texte alternatif est « Description générée automatiquement ». Pour les graphiques créés dans PowerPoint, le texte alternatif doit résumer l’argument du graphique en une phrase et citer ses deux ou trois valeurs les plus importantes — « Graphique à barres montrant une fréquentation des conférences 2026 en hausse de 18 % par rapport à 2025, portée par les régions EMEA et APAC » est préférable à « Graphique à barres ». Pour les diapositives riches en données, livrez les données sous-jacentes sous forme de tableau masqué mais accessible dans les notes du présentateur, ou sous forme de tableur lié en annexe, afin que l’utilisateur d’un lecteur d’écran puisse lire les chiffres en plus de la synthèse du graphique.
La vidéo intégrée est le défaut de conformité le plus courant dans les diaporamas PowerPoint. Le flux de travail Insertion, Vidéo, Insérer des sous-titres accepte les fichiers WebVTT (.vtt) et les lie au clip intégré ; une fois attachés, les sous-titres s’affichent dans le lecteur intégré de PowerPoint et accompagnent le fichier quand le diaporama est partagé, envoyé par e-mail ou téléchargé. Si votre vidéo source comporte des sous-titres ouverts incrustés, le vérificateur signale tout de même le fichier comme nécessitant une piste de sous-titres — ajoutez quand même un fichier VTT minimal, car c’est ce que liront les outils en aval. Les hyperliens doivent avoir un texte visible décrivant la destination (« Lire le rapport d’application de l’EAA 2026 »), pas l’URL brute.
Le pipeline d’exportation de PowerPoint préserve la plupart des métadonnées d’accessibilité lors de l’export en PDF — à condition d’utiliser Fichier, Exporter, Créer un PDF/XPS (Windows) ou Fichier, Enregistrer sous, PDF avec l’option Idéal pour la distribution électronique et l’accessibilité sélectionnée (macOS). Exporter via Imprimer en PDF supprime les balises et produit un PDF plat inaccessible ; c’est l’échec silencieux le plus courant de l’ensemble du flux de travail.
Flux de travail Keynote
Keynote est livré avec nettement moins d’outillage d’accessibilité que PowerPoint, et cet écart ne s’est pas significativement réduit depuis le cycle de publication 13.x. Il n’existe pas d’équivalent du vérificateur d’accessibilité — Keynote ne réalise pas d’audit diapositive par diapositive, n’affiche pas de volet d’ordre de lecture par diapositive, et n’avertit pas l’utilisateur quand une diapositive n’a pas de titre. Les diapositives elles-mêmes bénéficient d’une meilleure intégration VoiceOver que PowerPoint il y a dix ans, mais le flux de travail de production pour obtenir un diaporama accessible depuis Keynote est plus manuel à chaque étape.
Les titres de diapositives sont ajoutés via l’espace réservé Titre dans le masque de diapositive ou sous forme de zone de texte régulière utilisée de manière cohérente dans tout le diaporama. Le mode plan de Keynote (Affichage, Plan) lit depuis l’espace réservé Titre, donc construire des diaporamas à partir du masque plutôt que depuis des diapositives vierges est le principal levier. L’ordre de lecture est géré via l’inspecteur Disposition — les commandes Arrière/Avant dans le modèle d’empilement de Keynote servent également de commandes d’ordre de lecture, les formes envoyées plus loin en arrière-plan étant lues en premier. Il n’y a pas de volet d’ordre de lecture dédié ; vous devez maintenir un modèle mental de la pile, ou construire les diapositives complexes depuis une base connue correcte.
Le texte alternatif des images dans Keynote se définit via le champ Description de l’onglet Image de l’inspecteur Format — rédigez le même texte alternatif éditorial que dans PowerPoint. Le texte alternatif des graphiques utilise le même mécanisme. Keynote ne signale pas les textes alternatifs manquants. La seule façon de vérifier la couverture en textes alternatifs d’un diaporama dans Keynote est de parcourir chaque diapositive manuellement, ou d’exporter au format PowerPoint (.pptx) et d’exécuter le vérificateur d’accessibilité de Microsoft sur l’export — un flux de travail adopté par plusieurs grandes universités comme étape de validation pour les diaporamas de cours créés dans Keynote.
La vidéo intégrée dans Keynote ne prend pas en charge une piste de sous-titres séparée. Si votre vidéo source ne comporte pas de sous-titres ouverts incrustés, il faut soit réencoder la vidéo avec les sous-titres intégrés avant de l’insérer dans Keynote, soit remplacer l’intégration par une référence externe pointant vers une vidéo sous-titrée hébergée sur une plateforme gérant les sous-titres (YouTube, Vimeo, le serveur multimédia de votre institution). Keynote inclura silencieusement une vidéo non sous-titrée dans un PDF exporté ; le vérificateur inexistant ne peut pas vous en avertir.
Là où Keynote justifie sa place, c’est dans les diaporamas à fort contenu design créés pour des keynotes plutôt que pour une redistribution. Sa qualité de typographie, de mise en page et d’animation reste la meilleure du marché des présentations de bureau — quand le diaporama est essentiellement un accessoire de scène et que le contenu substantiel vit dans un article, une transcription ou une page web distribués séparément, Keynote produit une meilleure expérience en direct et le travail d’accessibilité se reporte sur le document d’accompagnement. Si le diaporama est lui-même le livrable, PowerPoint est le meilleur choix.
Flux de travail Google Slides
Google Slides s’est nettement amélioré depuis la mise à niveau accessibilité 2024 qui a ajouté un menu d’accessibilité par diapositive, des suggestions de texte alternatif alimentées par des modèles d’image de classe Gemini, et une superposition de vérification du contraste accessible depuis Outils, Accessibilité. La mise à niveau 2024 a également ajouté des commandes d’ordre de lecture au menu Disposition — pour la première fois dans l’histoire du produit, les auteurs de Slides peuvent définir un ordre de lecture explicite plutôt que de s’en remettre à l’ordre de création des formes. L’adoption de ces fonctionnalités dans les grandes entreprises clientes a été plus rapide que ce qu’anticipait Microsoft, en partie parce que les diaporamas Slides sont déjà très majoritairement hébergés dans le cloud et bénéficient immédiatement du vérificateur côté serveur.
La mécanique est familière à quiconque vient de PowerPoint. Les titres sont gérés via l’espace réservé Titre de la mise en page du masque. Le texte alternatif se définit via Options de format, Texte alternatif, avec la même règle éditoriale d’une à deux phrases. L’ordre de lecture utilise le menu Disposition, Ordre, avec le nouveau volet d’ordre de lecture 2024 visible depuis Outils, Accessibilité, Ordre de lecture. L’intégration de vidéos depuis Google Drive ou YouTube respecte la piste de sous-titres que la source comporte, et une diapositive contenant une vidéo non sous-titrée génère un avertissement dans le volet d’accessibilité.
Là où Slides est encore en retrait de PowerPoint, c’est dans l’accessibilité des graphiques (le texte alternatif généré automatiquement pour les graphiques est plus court et moins contextualisé), dans l’héritage de masques complexes (les mises en page de masque fortement personnalisées produisent des arbres d’ordre de lecture plus difficiles à déboguer), et dans les flux de travail hors ligne (le vérificateur d’accessibilité nécessite que le document soit en ligne, ce qui pose problème pour les utilisateurs qui travaillent dans des avions ou des environnements restreints). Pour une entreprise de 2026 qui a standardisé sur Workspace et livre principalement des diaporamas sous forme de liens Google Slides partagés plutôt que de fichiers téléchargés, le flux de travail Slides est désormais substantiellement comparable à PowerPoint. Pour une organisation qui livre des diaporamas sous forme de pièces jointes .pptx ou de PDF exportés, PowerPoint conserve l’avantage.
Diaporamas web-first : Reveal.js, Slidev, Marp
Le développement le plus intéressant en matière d’accessibilité des présentations en 2025 et 2026 s’est produit en dehors des trois grandes applications de bureau. Un ensemble de frameworks de présentation web-first — Reveal.js (le framework JavaScript de longue date), Slidev (un outil basé sur Vue destiné aux développeurs) et Marp (un générateur Markdown-first qui compile vers HTML, PDF ou PPTX) — produisent des diaporamas sous forme de documents HTML, ce qui signifie que les propriétés d’accessibilité du HTML sont héritées plutôt qu’émulées. La structure sémantique est réelle, pas synthétisée ; la navigation au clavier est celle du navigateur, pas de l’application de diaporama ; et la sortie du lecteur d’écran est ce que NVDA, JAWS ou VoiceOver produiraient pour n’importe quelle page web bien construite.
Les implications sont pratiques. Un diaporama Reveal.js servi depuis une URL est, par défaut, navigable avec les touches fléchées, Tab, Entrée, Espace et les mêmes raccourcis navigateur qu’un utilisateur voyant connaît déjà. Chaque diapositive est un élément section avec un titre — H1 pour le diaporama, H2 pour chaque titre de diapositive — de sorte qu’un utilisateur de lecteur d’écran peut sauter de titre en titre comme sur n’importe quelle page web. Les images portent des attributs alt rédigés dans la source Markdown ou HTML. Les graphiques rendus avec Chart.js, D3 ou toute bibliothèque SVG portent les rôles ARIA et les annonces de régions live que la bibliothèque de graphiques expose ; pour les bibliothèques de graphiques accessibles comme Highcharts Accessibility ou amCharts, cela inclut des tableaux de données lisibles par les lecteurs d’écran générés automatiquement à côté du graphique visuel.
L’audience développeurs de Slidev a produit un ensemble de paramètres d’accessibilité par défaut inhabituellement solides : sémantique des titres héritée du Markdown, texte alternatif requis au niveau du fichier source (le compilateur avertit sur les balises d’image sans attribut alt), et une couche de navigation au clavier fonctionnant sans configuration. La force de Marp réside dans les diaporamas en Markdown pur compilés vers HTML ou PDF — la même source produit à la fois un diaporama web navigable par lecteur d’écran et un PDF balisé, sans passe de création secondaire. Reveal.js se situe entre les deux : le plus flexible, le plus grand écosystème de plug-ins, le plus grand réservoir de plug-ins d’accessibilité tiers (Reveal Accessibility, reveal-a11y, le thème publié de conformité WCAG 2.2).
Les compromis sont réels. Les diaporamas web-first nécessitent un navigateur pour être présentés — pas de double-clic sur un fichier local, pas de flux de travail « envoyer le .pptx par e-mail », pas de solution de repli hors ligne sur ordinateur portable qui ne nécessite pas de configuration. Ils récompensent les auteurs à l’aise avec le contrôle de version et le déploiement continu ; ils pénalisent les auteurs qui veulent faire glisser un graphique depuis Excel dans une diapositive et considérer le travail terminé. Pour une présentation unique partagée sous forme d’URL après coup, c’est un avantage clair. Pour une mise à jour trimestrielle du conseil d’administration qui va être envoyée par e-mail à un directeur qui l’ouvrira dans un avion, c’est le mauvais outil.
Là où les diaporamas web-first ont commencé à s’imposer, c’est dans les contextes récurrents. Séries de cours universitaires qui publient tout un semestre de diapositives sous forme d’un seul site navigable. Programmes de conférences où le diaporama de chaque intervention est lié à l’agenda et vit à une URL permanente. Présentations techniques d’ingénierie où le dépôt source est lui-même la version de référence. Dans chacun de ces contextes, la sémantique HTML est préservée — les moteurs de recherche indexent le contenu des diapositives en texte, les lecteurs d’écran le traversent comme un document, et la charge de maintenance pour rester accessible au fil de la série incombe au framework plutôt qu’à chaque auteur individuel.
Un arbre de décision
Les trois familles d’outils ont chacune leur place dans un contexte de production différent. La version la plus simple de la décision est un choix à trois voies selon l’usage réel du diaporama.
Pour une présentation unique devant être envoyée par e-mail, ouverte sur l’ordinateur portable d’un collègue ou exportée en PDF balisé pour distribution, choisissez PowerPoint. Le vérificateur d’accessibilité est mature, le pipeline d’export préserve les balises, et les outils côté audience (la visionneuse web PowerPoint, l’application iPad, le lecteur Office Mobile) lisent tous correctement les présentations PowerPoint balisées. Prévoyez quatre-vingt-dix minutes d’audit par heure de diaporama ; budgétez le temps et utilisez-le.
Pour une série de cours récurrente, un programme de conférence, ou tout contexte où la collection de diaporamas vit à une URL et est consultée comme un corpus, choisissez un framework web-first. Slidev pour les audiences de développeurs et les auteurs à l’aise avec Markdown ; Marp pour les équipes en Markdown pur qui ont besoin à la fois d’HTML et de PDF balisé depuis la même source ; Reveal.js pour l’écosystème de plug-ins le plus large et la plus grande flexibilité de design. Les propriétés d’accessibilité sont héritées du navigateur, pas émulées, et la charge de maintenance incombe au framework plutôt qu’à chaque auteur.
Pour une présentation keynote à fort contenu design où le diaporama fonctionne comme accessoire de scène et où le contenu substantiel vit dans un document distribué séparément, choisissez Keynote, acceptez l’outillage d’accessibilité plus limité, et consacrez votre budget d’audit au document d’accompagnement. Parcourez chaque diapositive manuellement pour les textes alternatifs. Exportez au format .pptx et exécutez le vérificateur en passe finale. Livrez le document d’accompagnement (un article, une transcription, un résumé web) comme version accessible canonique.
Pour les organisations cloud-first collaboratives qui vivent déjà dans Google Workspace, Google Slides est désormais une alternative viable à PowerPoint pour les mêmes cas d’usage. La mise à niveau accessibilité 2024 a comblé la majeure partie de l’écart historique ; les écarts restants concernent le texte alternatif des graphiques, les masques complexes et l’édition hors ligne. Pour les diaporamas livrés sous forme de liens partagés plutôt que de fichiers téléchargés, le flux de travail est comparable à PowerPoint.
Réflexions finales
Le modèle sous-jacent à chaque recommandation de ce guide est le même : l’outil fixe le plancher d’accessibilité, mais l’auteur fixe le plafond. Le vérificateur de PowerPoint détectera le texte alternatif manquant ; il ne le rédigera pas à votre place. L’absence de vérificateur dans Keynote ne vous empêchera pas de créer un diaporama entièrement accessible — elle vous empêchera seulement d’être informé quand vous avez échoué. Les frameworks web-first héritent des propriétés d’accessibilité du HTML — ils ne les imposent pas. Chaque outil de ce guide vous laissera livrer un diaporama qui exclut une partie de votre audience. Le choix de l’outil change quelles erreurs sont faciles à commettre, pas lesquelles sont possibles.
Si vous introduisez un nouveau flux de travail d’accessibilité dans une équipe qui n’en a pas, commencez avec l’outil qu’utilise déjà l’équipe, activez son vérificateur, et auditez un diaporama existant avec ce vérificateur comme exercice d’étalonnage. Ne changez d’outil que lorsque l’équipe a intégré les six exigences de référence — titres, ordre de lecture, texte alternatif, contraste, clavier, médias — et réclame des capacités que l’outil actuel ne peut pas fournir. Le coût de changer d’outil en cours de route est élevé ; le coût de rester sur un outil dont vous avez dépassé le flux de travail est plus élevé encore.