L’accessibilité par défaut : ce que cela veut dire chez PanelWave

Dans la plupart des applications de lecture, l’accessibilité est une page de réglages. Dans PanelWave, c’est une propriété du format. La différence semble abstraite jusqu’à ce qu’on voie ce qu’elle apporte : un texte alternatif traduit parce que tout le texte est traduit, des animations réduites qui fonctionnent parce que les transitions sont des données, et un roman graphique lisible du début à la fin au clavier, parce que l’histoire est un graphe qu’un clavier peut parcourir. Ce billet montre comment l’accessibilité traverse les trois couches (manifeste, lecteur, CMS), ce qu’elle apporte au public, ce qu’elle demande aux créateurs, et où sont encore les lacunes.

Tout commence dans le format

Le manifeste porte les informations d’accessibilité dans des champs à part entière, pas dans une annexe facultative. Chaque média du catalogue peut avoir un texte alternatif, une légende, et une transcription pour l’audio et la vidéo ; les trois sont des LocalizedStrings, si bien que la sortie des lecteurs d’écran suit la langue choisie, exactement comme les dialogues (Médias, Localisation). Une case a une description, lue à voix haute à la place de l’illustration, et un bloc d’accessibilité avec une description alternative de la case entière (AccessibilityHints). Une zone interactive porte son propre libellé ARIA : elle annonce ce qu’elle fait plutôt que l’endroit où elle se trouve (Zones interactives).

Les avertissements de contenu se déclarent une fois dans les métadonnées de l’œuvre, avec un libellé localisé et un indicateur defaultBlur ; chaque case concernée y renvoie ensuite par leur identifiant (ContentWarning). Comme la déclaration fait partie du format, n’importe quelle implémentation de lecteur peut la respecter, pas seulement la nôtre. C’est le principe qui revient partout : placer l’information là où tous les outils la voient, et l’accessibilité cesse de dépendre de l’application qui ouvre le fichier.

Ce que le public trouve dans le PanelWave Player

Le lecteur open source transforme ces champs en comportements. Chaque bouton de la barre d’outils porte un aria-label traduit, et les boutons à bascule exposent aria-pressed. La zone d’affichage est une région étiquetée, activable au clavier avec Entrée ou Espace ; en vue page, chaque case placée est un bouton qui peut recevoir le focus, avec un indicateur de focus visible. Les flèches font avancer l’histoire, T affiche ou masque la barre d’outils, Échap ferme les fenêtres modales, et les raccourcis sont ignorés pendant la saisie dans un champ (Accessibilité, Modes de saisie).

Les zones interactives, ces régions dessinées par le créateur, font partie de l’ordre de tabulation : Tab passe de l’une à l’autre, Entrée ou Espace les active, et chacune annonce son libellé localisé. À l’écran, elles se signalent par un contour qui pulse doucement ; avec les animations réduites, la pulsation disparaît et le contour apparaît au survol et au focus (Zones interactives).

Les animations réduites sont respectées à partir de deux sources, le réglage prefers-reduced-motion du système d’exploitation et l’entrée reducedMotion de l’hébergeur, et elles changent plus que la vitesse des animations. Les transitions entre cases sont coupées, les vidéos qui démarrent à l’affichage passent en lecture au clic, et en vue canevas la caméra ne glisse jamais : les recadrages sont instantanés, avec un court fondu enchaîné, sauf si le créateur a défini sa propre transition de repli, qui passe alors en priorité. Les cases non courantes portent aria-hidden et inert : un canevas virtualisé ne piège donc jamais le focus, et les lecteurs d’écran suivent l’ordre linéaire du graphe, le canevas restant purement visuel (Vue canevas, Configuration).

Le public dispose aussi de commandes directes. La fenêtre de réglages propose le mode manga (lecture de droite à gauche), les animations réduites et le contraste élevé, à côté des bulles, de l’audio et du rythme de lecture automatique, avec un bouton pour revenir aux réglages par défaut (Fenêtre de réglages). Changer de langue relève aussi de l’accessibilité, et c’est instantané : textes, bulles, médias localisés et audio se mettent à jour sans rechargement (Localisation dans le lecteur).

Comment nous gardons le cap

Ce genre de promesse s’effrite si rien ne la vérifie. La suite de bout en bout Playwright du lecteur exécute axe-core sur la vue case avec la barre d’outils ouverte, sur la vue page et sur la fenêtre de langue, et échoue en cas de violation grave ; les rapports sont joints à chaque exécution. La navigation au clavier et le comportement en animations réduites ont leurs propres tests. La suite tourne en intégration continue, sur des navigateurs de bureau et mobiles (Développement : tests). Elle ne remplace pas les tests avec un lecteur d’écran, que nous faisons aussi à la main avant les sorties, mais elle empêche les régressions de passer inaperçues.

Ce qu’un créateur doit faire

Le format ne peut porter que ce qu’un auteur écrit : le CMS intègre donc cette écriture au travail courant, au lieu d’en faire un audit à part.

Rien de tout cela n’exige de savoir ce qu’est ARIA. Les champs sont là où se trouve le contenu, la vérification tourne avant la publication, et la correction est à un clic.

• Décrivez vos cases. Le titre et la description de l’inspecteur de case se modifient par langue. La description, c’est ce que lisent les lecteurs d’écran : une phrase sur ce qui se passe dans la case rend l’œuvre accessible aux personnes aveugles et malvoyantes (Propriétés de la case).
• Donnez un texte alternatif aux illustrations. Définissez-le une fois sur le média via Edit Metadata, ou sur le calque dans l’onglet A11y de l’inspecteur ; ce même onglet couvre aussi les légendes de l’audio et de la vidéo, et l’accessibilité des éléments interactifs (Texte alternatif et accessibilité, Inspecteur de droite).
• Nommez vos zones interactives. Chaque zone interactive a un champ Label par langue et un champ ARIA Label dans Basic Properties (Nommage et accessibilité).
• Signalez les contenus sensibles. Les avertissements de contenu se règlent case par case, depuis l’arborescence ou la section Content Settings, et l’arborescence affiche un badge W sur chaque case concernée (Pages et cases).
• Lancez Preflight. La catégorie Accessibility signale les calques d’image sans texte alternatif et l’audio sans légende. Un texte alternatif manquant est un avertissement ; une légende manquante, une erreur qui bloque la publication. Chaque problème renvoie à la case qui utilise le média et à la fiche du code (Validation, Texte alternatif manquant, Légende manquante).

L’outil de création doit lui aussi être accessible

Une personne malvoyante ou en situation de handicap moteur devrait pouvoir créer une BD accessible, pas seulement en lire une. L’éditeur applique partout une norme de focus visible, piège le focus dans chaque boîte de dialogue, donne à l’arborescence une sémantique ARIA et une navigation complète aux flèches, et affiche un récapitulatif des raccourcis clavier avec la touche point d’interrogation (Raccourcis). La palette de commandes (Ctrl+K) donne accès à la plupart des actions de l’éditeur sans souris, et un navigateur de calques au clavier annonce chaque calque aux lecteurs d’écran au fil du parcours. Côté thèmes : System, Light, Dark et une palette High Contrast, appliquée à la fois à l’application et à l’habillage du canevas de l’éditeur (Compte : thème). Le thème à contraste élevé est sorti ce mois-ci avec un ensemble de composants d’interface partagés ; c’est celui que nous comptons le plus affiner au fil des retours.

Contrôles d’âge et paywalls, avec égards

Le confort ne tient pas qu’au mouvement et au contraste. Quand une œuvre exige un contrôle d’âge, le lecteur fournit un composant dédié, avec âge minimum et message configurables ; la décision revient à l’adaptateur de droits d’accès de l’hôte, qui peut vérifier l’âge ou se rabattre sur une variable utilisateur en lecture seule injectée au démarrage. Sans l’un ni l’autre, le contrôle refuse plutôt que de deviner (Paywall et droits d’accès). Les surcouches de paywall suivent la même règle : le public sait clairement ce qui est réservé et pourquoi, dans sa langue, et l’histoire ne saute jamais de contenu en silence.

Ce qui reste à faire

Nous les listons parce qu’une promesse d’accessibilité qui cache ses lacunes vaut moins qu’une promesse qui les nomme.

• Preflight n’effectue pas encore tous les contrôles qu’il annonce. L’exhaustivité de la localisation et la couverture audio par bulle apparaissent comme catégories, mais leurs codes de problème sont encore à venir ; les contrôles du texte alternatif et des légendes sont actifs (Codes de validation).
• Trois cases à cocher des réglages sont enregistrées, mais pas encore appliquées. Les bascules Audio et SFX de la barre d’outils, elles, fonctionnent désormais : Audio coupe tout le son du lecteur, vidéo comprise ; SFX coupe le bus des bruitages ; Speech coupe aussi la voix off ; et les trois mémorisent votre choix (Commandes de la barre d’outils). En revanche, les cases mode manga, animations réduites et contraste élevé de la fenêtre de réglages sont enregistrées, mais le shell n’en tient pas encore compte ; les animations réduites sont respectées via le réglage du système d’exploitation et l’entrée de l’hébergeur.
• La présentation des avertissements de contenu dépend de l’implémentation. Le format déclare l’avertissement et indique si une case doit être floutée par défaut ; la façon de demander l’accord du public relève de chaque implémentation, et la nôtre est encore en cours d’affinage sur de vraies œuvres.

Pourquoi dès le premier jour

Ajouter l’accessibilité après coup, c’est toucher à toutes les couches à la fois : le format doit gagner des champs, le lecteur doit les lire, l’outil de création doit les recueillir, et les œuvres existantes restent inaccessibles jusqu’à ce que quelqu’un les reprenne. En l’intégrant dès le départ, nous en avons fait, pour l’essentiel, la conséquence de décisions déjà prises. Le texte alternatif est localisé parce que tout est une LocalizedString. Les animations réduites sont fiables parce qu’une transition est un champ de données qu’un moteur peut ignorer. Le parcours au clavier est complet parce que l’histoire est un graphe avec un suivant et un précédent définis. Graphe narratif, modèle de localisation et champs d’accessibilité ont été conçus ensemble : c’est en ce sens qu’ici, l’accessibilité est un réglage par défaut plutôt qu’une fonctionnalité.

Pour aller plus loin

• Interface de lecture : chaque commande, mode de saisie et comportement d’accessibilité du lecteur.
• Cases et Médias : les champs d’accessibilité du format.
• Validation et Preflight : les vérifications exécutées avant la publication.
• Pourquoi une navigation par graphe ? : le modèle qui rend le parcours au clavier complet.