Accessibilité du modèle 3D

Avertissement : Les recommandations suivantes n'ont pas été soumises à des tests d'utilisabilité par des personnes handicapées. Toutes les recommandations de cet article sont purement spéculatives en utilisant mon meilleur jugement et doivent être considérées comme un travail en cours.

Remarque : Les tests ont été effectués à l'origine sur <model-viewer> version 0.1.1 début 2019.

Lorsque j'ai entendu parler pour la première fois du projet de Shopify d'inclure des vidéos et des modèles 3D sur les pages de produits (environ Février 2019 ), j'étais assez excité. "Des vidéos de produits et des modèles 3D ? C'est cool !" Quelques secondes seulement après avoir consommé les nouvelles de cette fonctionnalité en cours de construction (et publiée dans quelques mois), une autre pensée m'a traversé l'esprit :

"Les modèles 3D sur le Web… comment allons-nous les rendre accessibles ? Comment transmettre un "modèle 3D", sans parler de fournir un accès via une technologie d'assistance ?"

Après avoir pris un certain temps pour accepter cette réalisation décourageante, j'ai fait ce que ferait n'importe quel développeur Web professionnel; J'ai posé mes questions à Google.

La recherche de « modèles 3D accessibles » a rapidement confirmé mes soupçons ; pas beaucoup d'informations étaient disponibles. Les modèles 3D sur le web existent depuis un certain temps, oui, mais une solution adaptée aux technologies d'assistance ? Aucun des blogueurs sur l'accessibilité que je suis n'avait écrit sur le sujet, et il n'y avait rien d'applicable du W3C WAI que j'ai pu trouver. Alors, quelle est la prochaine étape après l'échec de Google ? Twitter, bien sûr !

J'ai posé la question si quelqu'un connaissait une solution de modèle 3D accessible . Honnêtement, je ne m'attendais pas à ce que quelqu'un réponde. Je me suis dit : "Cette technologie est si nouvelle. Personne n'a encore vraiment exploré ce domaine du Web. Je suppose que je suis seul pour comprendre cela."

À ma grande surprise, quelques jours plus tard, j'ai reçu une réponse sur Twitter :

Qu'il suffise de dire que j'étais plus que ravi de recevoir cette réponse. Il semblait qu'une solution était possible. Fournir une expérience de modèle 3D accessible aux partenaires Shopify à mettre en œuvre, à nos millions de marchands à servir et à leurs clients à consommer pourrait en fait être une réalité.

Il s'est avéré que le composant Web <model-viewer> de Google était en fait le composant de modèle 3D que l'équipe Rich Media de Shopify avait l'intention de mettre en œuvre. (Je sais, n'est-ce pas? Quelles sont les chances?) Avec cela, j'ai décidé de prendre un peu de temps sur ma liste de tâches sans cesse croissante et de mener plusieurs séries de tests. Afin d'évaluer exactement à quel point les choses étaient accessibles et de faire des recommandations (pour les équipes Google et Shopify), j'avais besoin de tester en profondeur <model-viewer> avec une technologie d'assistance.

Qu'est - ce qu'un modèle 3D ?

Avant de plonger dans les résultats des tests, essayons de définir ce qu'est un modèle 3D et ce qu'il n'est pas. La réponse à cette question sera critique lors de (tentative) de transmettre la présence d'un modèle 3D sur le Web pour la technologie d'assistance. En d'autres termes, "Qu'est-ce que cette chose ? Que fait-elle ? Comment puis-je interagir avec elle ?"

Premièrement, un modèle 3D n'est pas une image (élément HTML img ). Les images sont statiques, représentent une vue unilatérale en 2 dimensions d'un objet ou d'une scène. Les images ne nécessitent pas d'interaction de l'utilisateur (autre que la découverte de l'image et la consommation de son texte alt via un lecteur d'écran.) Par conséquent, un modèle 3D ne doit pas être transmis en tant qu'élément d'image.

Deuxièmement, un modèle 3D n'est pas une vidéo (élément video HTML). Oui, la vidéo est un média dynamique ; il nécessite une interaction de l'utilisateur afin de consommer son contenu. Mais la vidéo est un média passif. Cela signifie qu'une fois que vous avez appuyé sur play, l'utilisateur n'a qu'à s'asseoir et profiter du spectacle. D'autres éléments interactifs sont disponibles (épurateur de chronologie, muet, commandes de sous-titrage, etc.), mais ne sont pas nécessaires pour la majorité de l'expérience utilisateur. Par conséquent, un modèle 3D ne doit pas être transmis comme un élément vidéo.

Alors, qu'est - ce qu'un modèle 3D ? Vous avez peut-être déjà une réponse à cela dans votre esprit. Ma tentative de réponse à cette question est la suivante :

"Un modèle 3D représente un objet physique du monde réel. Un objet qui présente non seulement la largeur et la hauteur mais aussi la profondeur. La visualisation d'un objet dans la troisième dimension permet d'inspecter tous les angles de l'objet."

Très bien, c'est logique (au moins pour moi.) Mais comment décrivons -nous cela en termes de "chose" interactive sur le Web ? Quelle signification sémantique existe pour informer l'utilisateur de l'objet avec lequel il interagit actuellement ? Et comment interagissent-ils avec ledit objet ?

Je pense avoir une bonne réponse à ces questions, mais examinons d'abord quelques hypothèses et attentes sur ce qui peut constituer un modèle 3D accessible.

Qu'est-ce qui rend un modèle 3D "accessible" ?

Voici ma liste de critères pour, ce que je considérerais, une expérience utilisateur de modèle 3D accessible. Bien que ces critères n'aient pas (encore) été testés par les utilisateurs, j'ai l'impression que les informations transmises seraient suffisantes pour qu'une personne utilisant diverses technologies d'assistance comprenne ce qu'est le composant et comment interagir avec lui. Encore une fois, divulgation complète, j'utilise mon meilleur jugement ici.

Attentes/hypothèses d'utilisabilité du modèle 3D

• Un utilisateur de souris doit pouvoir cliquer-saisir/balayer et faire défiler pour la rotation et le zoom du modèle
• Un utilisateur mobile voyant devrait pouvoir balayer et utiliser des gestes de pincement pour la rotation et le zoom du modèle
• Un utilisateur voyant uniquement au clavier devrait voir un état de mise au point visible lorsque le modèle 3D a la mise au point au clavier
• Un utilisateur de clavier doit pouvoir faire pivoter le modèle horizontalement et verticalement uniquement via le clavier
• Un utilisateur de clavier doit pouvoir effectuer un zoom avant et arrière sur le modèle uniquement via le clavier
• Un utilisateur de lecteur d'écran doit entendre un role décrivant le composant en tant que modèle 3D
• Un utilisateur de lecteur d'écran doit entendre une brève description de l'objet du modèle 3D
• Un utilisateur de lecteur d'écran doit entendre un texte d'astuce supplémentaire pour décrire plus en détail comment interagir avec le modèle 3D
• Un utilisateur de lecteur d'écran doit entendre des annonces descriptives de la partie/angle visible lorsque le modèle 3D a été pivoté
• Un utilisateur de lecteur d'écran devrait entendre une annonce sur le zoom décrivant le niveau de zoom actuel
• Un utilisateur de lecteur d'écran mobile doit pouvoir balayer et utiliser des gestes de pincement pour la rotation et le zoom du modèle
• Un utilisateur de dictée vocale, un utilisateur de commutation ou toute personne à mobilité réduite doit pouvoir faire pivoter et zoomer le modèle 3D à l'aide de button de commande dédiés pour chaque élément de fonctionnalité dynamique

Avec cette prise en charge en place, une personne utilisant une souris, un clavier, un appareil mobile, un lecteur d'écran, une activation vocale ou un certain nombre d'autres technologies d'entrée devrait être en mesure de comprendre et d'interagir avec le modèle 3D. C'est la théorie, en tout cas.

Avec ces critères à l'esprit, plongeons dans certains résultats de test et examinons comment <model-viewer> se compare aux critères ci-dessus.

Premiers résultats des tests

Voici ce que j'ai trouvé en testant <model-viewer> avec diverses combinaisons de navigateur et de lecteur d'écran sur des ordinateurs de bureau et des appareils mobiles . L'environnement de test comprenait la démo par défaut sur Glitch .

Résultats du test de démonstration Glitch

SE	Navigateur	Lecteur d'écran	Remarques
macOS	Safari	Voix off	✅ Sur canvas focus : "Un modèle 3d d'un astronaute, image… Utilisez la souris, le toucher ou les touches fléchées pour contrôler la caméra !" ✅ Utilisation du clavier : ajuste la position du modèle, annonce le quadrant actuellement visible.
macOS	Chrome	Voix off	✅ Sur canvas focus : "Un modèle 3d d'un astronaute, groupe… Utilisez la souris, le toucher ou les touches fléchées pour contrôler la caméra !" ✅ Utilisation du clavier : ajuste la position du modèle, annonce le quadrant actuellement visible.
iOS	Safari	Voix off	❌ Ignore complètement l'élément canvas .
les fenêtres	Internet Explorer 11	MÂCHOIRES	❌ Sur canvas focus : "Vue depuis le devant de la scène." ❌ À l'aide d'un clavier : navigue dans les nœuds de contenu derrière les éléments de canvas .
les fenêtres	Bord	MÂCHOIRES	✅ Sur canvas focus : "Un modèle 3d d'un astronaute, graphique." ❌ À l'aide d'un clavier : navigue dans les nœuds de contenu derrière les éléments de canvas .
les fenêtres	Firefox	NVDA	✅ Sur canvas focus : "Un modèle 3d d'un astronaute, cliquable… Utilisez la souris, le toucher ou les touches fléchées pour contrôler la caméra !" ❌ À l'aide d'un clavier : naviguez dans les nœuds de contenu derrière les éléments du canvas .
Android	Chrome	Répondre	❌ Mise au point sur la canvas : " Vue depuis le devant de la scène, graphique. Tous les modèles 3D de la page ont été chargés." ❌ Mise au point sur la canvas (2e ?) : "Utilisez le toucher, la souris ou les touches fléchées pour contrôler la caméra. Appuyez deux fois pour l'activer." ✅ Double tapotement à deux doigts, balayage à deux doigts : ajuste la position du modèle, annonce le quadrant actuellement visible.

Avec ces résultats, il est clair que VoiceOver avait le meilleur support. Cela est dû au fait que le curseur virtuel de VoiceOver nécessite plus d'une simple pression sur une touche fléchée pour parcourir le contenu. D'autres comme NVDA ou JAWS utilisent simplement les touches fléchées Haut et Bas qui déplacent leurs curseurs devant le modèle au lieu de la rotation verticale attendue. Il existe un moyen de contourner cela dont nous parlerons plus tard.

Recommandations à l'équipe Google

Lors du test de <model-viewer> pour les meilleures pratiques d'accessibilité Web, il était clair tout de suite que l'équipe de Google avait réfléchi et fait des efforts pour rendre ce composant Web accessible. Des fonctionnalités telles que la prise en charge des touches fléchées pour la rotation du modèle et les annonces du lecteur d'écran pour les emplacements des étapes du modèle ont été intégrées par défaut.

Lors des tests, j'ai noté quelques éléments clés qui pourraient rendre le composant encore plus utilisable avec la technologie d'assistance.

1. Inclure une bague de mise au point via :focus-visible

Il manquait à l'élément de modèle un indicateur de focus visible sur le focus du clavier. Bien qu'il puisse être souhaitable de supprimer l'anneau de mise au point par défaut qui apparaît lors d'un clic de souris, un anneau de mise au point doit être présent et visible lorsque les utilisateurs du clavier interagissent avec le modèle. Les utilisateurs voyants doivent savoir où ils se trouvent sur la page lorsqu'ils naviguent dans le contenu.

J'ai suggéré une solution de contournement possible consistant à implémenter le polyfill focus-visible . L'idée serait d'encapsuler le polyfill dans <model-viewer> afin de fournir un anneau de focus. Avec cela en place, l'équipe serait libre de supprimer le contour pour la souris/le toucher, mais d'afficher le contour pour le clavier uniquement.

2. Une annonce de role plus précise

Le modèle 3D (à l'époque) était dessiné à l'écran via HTML canvas . Lors de l'interaction avec le canvas avec une technologie d'assistance, le role par défaut est "image" ou "graphique" (selon le système d'exploitation/la technologie d'assistance.) Comme indiqué précédemment, cette description de l'élément actuellement ciblé n'est pas précise ; un modèle 3D n'est pas une image statique.

Pour contourner le fait que "modèle 3D" n'est pas un type de média natif avec un rôle organique, ma recommandation à l'équipe Google était d'inclure l'attribut aria-roledescription directement sur l'élément canvas . Cet attribut permet à l'auteur de définir une valeur de "rôle" personnalisée qui sera annoncée comme le role de l'élément - la "chose" avec laquelle vous interagissez actuellement. Dans ce cas, j'ai suggéré d'ajouter l' aria-roledescription="3d model" pour annoncer l'élément canvas comme, "3d model" .

 < canvas … aria-roledescription = "3d model" > </ canvas >

Il convient de noter que l'utilisation d' aria-roledescription peut être un peu destructrice. Cet attribut remplace le role de l'élément natif qui, probablement 100 % du temps, peut ne pas être idéal. Dans le contexte d'un élément de contenu qui n'a pas de rôle natif, je pense que l'utilisation d' aria-roledescription pour aider à décrire un composant de modèle 3D est un cas d'utilisation approprié.

Consultez le titre approprié d'Adrian Roselli, " Evitez aria-roledescription " pour plus de détails sur les pièges de l'utilisation de cet attribut.

3. Fournir des descriptions définies par l'utilisateur par variante d'étape

Lorsque les touches fléchées du clavier ont été utilisées pour régler l'angle du modèle, une annonce a été faite pour alerter l'utilisateur du changement visible.

C'est formidable de voir comment ce besoin a été pensé et inclus par défaut dans le composant Web. Cependant, ma prochaine pensée après avoir fait cette découverte a été : "Cela peut-il être configurable ? Est-il possible d'ajouter plus de description de l'objet sous un angle spécifique ?" Chaque description d'étape pourrait être pensée de la même manière que la description d'un ensemble d'images statiques.

Prenons par exemple un modèle 3D d'une casquette de baseball. Le modèle commencerait dans sa position par défaut, face à l'avant. Lors de sa découverte, il pourrait y avoir une description audible de ses caractéristiques physiques, y compris la couleur, le style de chapeau et peut-être un logo sur le devant. L'utilisateur, à l'aide des touches fléchées du clavier, pouvait faire pivoter le modèle de 180 degrés pour examiner l'arrière du chapeau. Lorsque ce point d'intérêt est atteint, une autre description audible informerait le client potentiel d'un bracelet en cuir marron pour un ajustement de la taille. L'utilisateur espérait en fait un chapeau de style full-back. Avec ces informations, ils pourraient décider de passer à l'examen d'autres produits.

Comment cela pourrait-il être accompli ? Actuellement, afin de fournir une description du modèle, le composant Web <model-viewer> prend lui-même un attribut alt . Par exemple, la démo Glitch propose :

 < model-viewer … alt = "A 3D model of an astronaut" > <!-- … --> </ model-viewer >

Une idée que j'ai eue pour cela pourrait être d'introduire un ensemble d'attributs alternatifs alternatifs alt des descriptions de variantes d'étape. Quelque chose comme:

< model-viewer … alt = "A 3D model of an astronaut" alt-stage-front = "Astronaut wears white space suit with helmet. Backpack straps wrap around its chest." alt-stage-left = "Astronaut shoulder features space logo." alt-stage-back = "Astronaut wears large, white backpack with black highlights." … > <!-- … --> </ model-viewer >

Pourquoi est-ce important? Ces annonces descriptives supplémentaires fourniraient plus de clarté sur le modèle, décrivant sous tous les angles ses caractéristiques physiques. Comme un utilisateur voyant serait en mesure de voir les aspects physiques, un utilisateur aveugle de lecteur d'écran a besoin que ces caractéristiques soient décrites à haute voix. C'est l' expérience utilisateur égale que nous, en tant que créateurs du Web, devrions nous efforcer d'atteindre.

4. Intercepter la saisie au clavier

Les lecteurs d'écran disposent de leurs propres commandes clavier pour parcourir les pages Web et naviguer dans le contenu. Il s'agit généralement du curseur virtuel du lecteur d'écran . Par exemple, lors de l'utilisation de NVDA, appuyer sur les touches fléchées Haut ou Bas permet de naviguer et d'annoncer tous les types de contenu sur la page, pas seulement les éléments focalisables comme les liens ou les contrôles de formulaire.

Dans le cas du modèle 3D, l'élément canvas utilisait les arrow fléchées pour faire pivoter le modèle horizontalement et verticalement. Lors de l'interaction avec le modèle lors de l'exécution d'un lecteur d'écran tel que NVDA ou JAWS (puisqu'ils utilisent des événements de touche fléchée unique pour parcourir le contenu de la page), le contenu dans le DOM <model-viewer> est navigué et annoncé au lieu d'ajuster l'angle du modèle . Ce n'est pas exactement le résultat attendu.

Pour contourner ce dilemme, ma suggestion à l'équipe Google était d'inclure l'attributrole="application" directement sur l'élément canvas . L'inclusion de cette valeur de role permet aux événements d'appui sur les touches fléchées de contourner entièrement le lecteur d'écran et d'envoyer les événements directement à l'application sous-jacente. Dans ce cas, <model-viewer> .

< canvas … role = "application" > </ canvas >

Au cours de mes plus de 10 ans dans la communauté de l'accessibilité, cela a été le seul cas d'utilisation réel que j'ai rencontré pour le rôle d' application . Je suis également conscient de recommander cette valeur de role avec prudence car elle affecte considérablement la navigation au clavier lors de l'utilisation d'un lecteur d'écran. La spécification ARIA 1.1 indique :

Lorsqu'il est nécessaire de créer un élément avec un modèle d'interaction qui n'est pris en charge par aucun des rôles de widget WAI-ARIA, les auteurs PEUVENT donner à cet élément le rôle d'application. Et, lorsqu'un utilisateur navigue dans un élément avec application de rôle, les technologies d'assistance qui interceptent les événements d'entrée standard DEVRAIENT passer à un mode qui transmet la plupart ou tous les événements d'entrée standard à l'application Web.

w3.org/TR/wai-aria-1.1/#application

Léonie Watson a un excellent aperçu de role="application" dans le post, " Comprendre les modes d'interaction des lecteurs d'écran ".

Résultats des tests avec quelques recommandations appliquées

J'ai testé mes recommandations d'ajout de role="application" et aria-roledescription afin de confirmer les recommandations (et pour ma propre curiosité de nerd d'accessibilité.) Passons en revue les résultats.

Démo des composants Web avec role="application" et aria-roledescription appliqués

SE	Navigateur	Lecteur d'écran	Remarques
macOS	Safari	Voix off	❌ Sur canvas focus : "Safari occupé" ❌ Utilisation du clavier : "Safari occupé" VoiceOver semble avoir du mal à "charger" le contenu du canvas . Curieusement, Cmd + Tab s'éloigne de Safari alors que le canvas est au point et revient, le contenu est annoncé : ✅ Sur canvas focus : "Un modèle 3d d'un astronaute, modèle 3d… Utilisez la souris, le toucher ou les touches fléchées pour contrôler la caméra !" ✅ Utilisation du clavier : ajuste la position du modèle, annonce le quadrant actuellement visible.
macOS	Chrome	Voix off	✅ Sur canvas focus : "Un modèle 3d d'un astronaute, modèle 3d… Utilisez la souris, le toucher ou les touches fléchées pour contrôler la caméra !" ✅ Utilisation du clavier : ajuste la position du modèle, annonce le quadrant actuellement visible.
iOS	Safari	Voix off	❌ Ignore complètement l'élément canvas .
les fenêtres	Internet Explorer 11	MÂCHOIRES	❌ N/A (la démo a refusé de se charger)
les fenêtres	Bord	MÂCHOIRES	✅ Sur canvas focus : "Un modèle 3d d'un astronaute, graphique" ❌ À l'aide du clavier : ajuste la position du modèle mais n'annonce pas le quadrant actuellement visible.
les fenêtres	Firefox	NVDA	✅ Sur canvas focus : "Un modèle 3d d'un astronaute… Utilisez la souris, le toucher ou les touches fléchées pour contrôler la caméra !" ✅ Utilisation du clavier : ajuste la position du modèle, annonce le quadrant actuellement visible.
Android	Chrome	Répondre	❌ Mise au point sur la canvas : "Vue depuis la scène [angle], application. Appuyez deux fois pour activer." ✅ Utilisation d'un double tapotement à deux doigts, puis d'un balayage à deux doigts : ajuste la position du modèle, annonce le quadrant actuellement visible.

Il était clair que ces attributs contribuaient à l'accessibilité de la visionneuse de modèles 3D. VoiceOver et NVDA semblaient avoir le meilleur support en annonçant les valeurs des attributs aria-label et aria-roledescription comme prévu. Avec role="application" mis en place, les utilisateurs de JAWS et NVDA pourront faire pivoter le modèle à l'aide des touches fléchées.

Des problèmes subsistent

Voici un aperçu des principaux problèmes des tests décrits ci-dessus.

iOS ignore le canvas

A part ne pas pouvoir tester cette deuxième démo avec IE ou Edge, c'est iOS qui a eu le plus de problèmes. Il semblait que, avec l'une ou l'autre démo, iOS avec VoiceOver activé ignorait complètement l'élément canvas . Lors de l'utilisation de la navigation par balayage, même avec tabindex appliqué, il a été complètement contourné.

Selon HTML5Accessibility.com , les éléments canvas peuvent être rendus accessibles en incluant des éléments enfants dans canvas . Cependant, dans le cas d'un visualiseur de modèle 3D acceptant directement les événements de l'élément canvas , l'inclusion d'éléments enfants ne serait pas utile.

Problèmes de performances de bureau VoiceOver + Safari

Lorsqu'il est associé au navigateur Safari sur macOS, VoiceOver semble avoir du mal à "charger" le contenu du canvas . Sur la mise au point, VoiceOver annoncerait "Safari occupé". Lorsque vous utilisez les touches fléchées pour ajuster la position du modèle, encore une fois, "occupé" a été annoncé. Bien qu'il y ait clairement des problèmes de performances avec cette combinaison, on ne pouvait pas en dire autant de Chrome associé à VoiceOver sur macOS ; aucun problème de perf.

Curieusement, lorsque vous éloignez les fenêtres de Safari alors que le canvas était au point, puis revenez en arrière, cela a parfois contribué aux performances de chargement.

Description du modèle manquante dans Chrome pour Android

Sur le canvas , Chrome pour Android a annoncé l'angle/l'étape du modèle dans son aria-label par défaut, au lieu de la description du modèle. Cela a essentiellement contourné l'annonce de ce avec quoi l'utilisateur interagirait.

Ce problème a été confirmé en utilisant l' inspecteur à distance de Chrome et en examinant la valeur de l'attribut aria-label lors du chargement de la page.

Recommandations à l'équipe Shopify

Jusqu'à présent, nous avons examiné les résultats des tests et les recommandations qui affectent le "back-end" du modèle 3D. C'est la pièce sur laquelle l'équipe Google aurait un impact pour rendre <model-viewier> plus accessible.

L'implémentation de l'expérience utilisateur, ou "front end", est l'endroit où l'équipe Shopify entre en jeu. Pour chaque thème Shopify qui prend en charge le modèle 3D, un travail supplémentaire est nécessaire pour intégrer <model-viewer> dans le thème .

Lors du test de l'implémentation du thème par défaut de Shopify, Debut , j'ai remarqué quelques problèmes d'accessibilité supplémentaires. Voici quelques faits saillants des recommandations que j'ai envoyées à l'équipe.

1. Les gestes de balayage ne devraient pas être nécessaires

Sur un appareil mobile ou à écran tactile, la rotation de <model-viewer> nécessitait des gestes de balayage pour faire pivoter le modèle. Selon la plate-forme mobile, avec un lecteur d'écran activé, cela nécessiterait des gestes de balayage à deux ou trois doigts . Par conséquent, cela pourrait créer une expérience utilisateur difficile ou frustrante pour les utilisateurs à mobilité réduite, comme quelqu'un qui utilise un logiciel de dictée vocale.

Ma recommandation était d'implémenter un contrôle à button unique pour la rotation du modèle ; haut bas Gauche Droite. Cela fournirait une méthode de saisie facultative et permettrait une utilisation facile de la rotation du modèle 3D (des commandes dédiées pour le zoom et le plein écran étaient déjà en place.)

Il convient également de souligner que dans la prochaine version de WCAG 2.2 , les nouveaux critères de réussite 2.5.1 Pointer Gestures stipulent :

"Toutes les fonctionnalités qui utilisent des gestes multipoints ou basés sur le chemin pour le fonctionnement peuvent être utilisées avec un seul pointeur sans geste basé sur le chemin, à moins qu'un geste multipoint ou basé sur le chemin ne soit essentiel."

Dans cet esprit, je dirais que la rotation d'un modèle 3D est essentielle à sa convivialité.

2. Zoom n'annonce pas de résultat

Lors de l'utilisation des commandes dédiées pour zoomer ou dézoomer le modèle 3D, dont le résultat n'a pas été communiqué aux utilisateurs de lecteurs d'écran.

Pour ce problème, j'ai recommandé d'ajouter un élément role="status" au DOM afin d'annoncer le niveau de zoom actuel. Lorsque les commandes de zoom avant ou de zoom arrière sont cliquées, une annonce est faite pour alerter l'utilisateur du niveau de zoom actuel sous forme de pourcentage.

Afin d'éviter que les utilisateurs de lecteurs d'écran ne découvrent ce contenu hors contexte, l'attribut aria-hidden devrait être basculé de true à false lors de l'annonce, puis de nouveau à true .

< div class = "visually-hidden" role= "status" aria-hidden= "true" > Zoomed 50 %. </ div >

3. Commandes visibles uniquement au survol

Les commandes du modèle 3D pour le zoom et le plein écran n'étaient visibles qu'au survol de la souris. Cela a créé une expérience utilisateur difficile pour atteindre les commandes pour les utilisateurs voyants au clavier uniquement, les utilisateurs de zoom texte malvoyants, les utilisateurs de dictée vocale ou toute personne incapable d'utiliser une souris.

La recommandation ici était de rendre les commandes disponibles et visibles sur le focus du clavier. De toute évidence, cela ne répond toujours pas à tous les besoins des utilisateurs, tels que les utilisateurs de dictée vocale pouvant appeler en cliquant sur un bouton de contrôle qu'ils ne peuvent pas voir. D'autres solutions de contournement devront être envisagées et mises en œuvre à temps.

Aperçu APG et démo en direct

Voici où j'essaie de créer un aperçu de style ARIA Authoring Practices pour un modèle de modèle 3D. Si vous n'êtes pas familier, le site ARIA Authoring Practices fournit les meilleures pratiques en matière de clavier et d'attribut aria-* pour les composants dynamiques non natifs. Lisez-le certainement la prochaine fois que vous créerez un modèle d'interface utilisateur non natif.

Bon, essayons ça…

---

Modèles 3D

Un modèle 3D représente un objet physique du monde réel. Un objet qui présente non seulement la largeur et la hauteur mais aussi la profondeur. La visualisation d'un objet dans la troisième dimension permet d'inspecter tous les angles de l'objet.

Exemple

Exemple de modèle 3D : illustre un modèle 3D d'un article du monde réel sur une page de produit d'une boutique de commerce électronique de démonstration.

Conditions

Les termes suivants sont utilisés pour décrire les composants d'un modèle 3D.

modèle 3D

Un conteneur de contenu unique contenant le contenu à présenter par le composant de modèle 3D.

Contrôle de la rotation

Un élément interactif qui commence la rotation du modèle 3D.

Contrôle du zoom

Un élément interactif qui zoome le modèle 3D.

Contrôle plein écran

Un élément interactif qui définit la vue du modèle 3D en plein écran.

Annonces en direct

Un élément masqué qui contient des descriptions d'étape et des messages de mise à jour.

Interaction clavier

Lorsque le composant de modèle 3D a le focus clavier :

• Entrée ou Espace : Annonce la position actuelle sur scène avec description (si disponible.)
• Tabulation : Déplace le focus vers l'élément pouvant être sélectionné suivant dans la séquence de tabulation de la page.
• Shift + Tab : Déplace le focus vers l'élément focusable précédent dans la séquence de tabulation de la page.
• Esc : réinitialise le modèle à sa position de départ et à son niveau de zoom par défaut.
• Flèche gauche : panoramique horizontal du modèle.
• Flèche droite : Déplace le modèle horizontalement.
• Flèche vers le haut : Déplace le modèle verticalement.
• Flèche vers le bas : Déplace le modèle verticalement.
• + : Agrandit le modèle.
• - : effectue un zoom arrière sur le modèle.

Rôles, états et propriétés WAI-ARIA

• Le modèle 3D a un rôle d'application .
• Le modèle 3D a la propriété aria-roledescription définie sur 3D model .
• Le modèle 3D a la propriété aria-label définie pour fournir un nom accessible.
• Facultativement, la propriété aria-describedby dedicatedby est définie sur le modèle 3D pour indiquer comment interagir avec le composant.
• L'élément Annonce en direct a status rôle .
• Le contrôle Plein écran a un état aria-pressed . Lorsque le bouton est activé, la valeur de cet état est true , et lorsqu'il est désactivé, l'état est false .

---

Conclusion, pour l'instant

À ce stade, nous avons creusé profondément dans les tests de <model-viewer> pour divers environnements de lecteur d'écran, mais ce n'est que la pointe de l'iceberg de la technologie d'assistance. Nous devons également prendre en charge et résoudre les problèmes potentiels pour :

• Utilisateurs voyants du clavier uniquement
• Utilisateurs de zoom basse vision
• Lecteurs braille
• Logiciel de dictée vocale
• Changer d'accès
• Et plus…

Afin de produire une expérience utilisateur précise et confortable pour tous, des tests d'utilisabilité avec de vraies personnes sont indispensables . (C'est dommage que cela n'ait pas eu lieu avant le lancement, mais c'est sur notre radar pour aller de l'avant.)

En tant que créateurs et mainteneurs du Web, il est de notre responsabilité d'être conscients des besoins des gens, d'éviter de créer des barrières d'accès et, par extension, d'éradiquer la conception la plus habile.

Avec les résultats des tests présentés ici, je pense que l'infrastructure existe pour fournir des modèles 3D accessibles aux personnes handicapées. Les équipes Google et Shopify étaient toutes deux heureuses et impatientes de recevoir les résultats des tests afin de travailler ensemble à la création de l'expérience utilisateur la plus accessible. Je suis convaincu que la convivialité et l'accessibilité des modèles 3D s'amélioreront avec le temps.