Zugänglichkeit von 3D-Modellen

Warnung : Die folgenden Empfehlungen wurden keinem Gebrauchstauglichkeitstest durch Menschen mit Behinderungen unterzogen. Alle Empfehlungen in diesem Beitrag sind nach bestem Wissen und Gewissen rein spekulativ und sollten als laufende Arbeit betrachtet werden.

Hinweis : Die Tests wurden ursprünglich Anfang 2019 mit <model-viewer> Version 0.1.1 durchgeführt.

Als ich zum ersten Mal von Shopifys Projekt hörte, Video- und 3D-Modelle auf Produktseiten (ca Februar 2019 ), ich war ziemlich aufgeregt. "Produktvideos und 3D-Modelle? Das ist cool!" Nur Sekunden nachdem ich die Nachricht über die Entwicklung dieses Features (und die Veröffentlichung in ein paar Monaten) verzehrt hatte, ging mir ein anderer Gedanke durch den Kopf:

„3D-Modelle im Internet … wie machen wir diese zugänglich?

Nachdem ich einige Zeit gebraucht hatte, um mich mit dieser entmutigenden Erkenntnis abzufinden, tat ich, was jeder professionelle Webentwickler tun würde; Ich habe meine Fragen an Google gerichtet.

Die Suche nach „zugänglichen 3D-Modellen“ bestätigte schnell meinen Verdacht; nicht viele Informationen waren verfügbar. 3D-Modelle im Web gibt es schon seit einiger Zeit, ja, aber eine Lösung, die auf assistive Technologien ausgerichtet ist? Keiner der Barrierefreiheits-Blogger , denen ich folge, hat über das Thema geschrieben, noch konnte ich etwas Anwendbares von W3C WAI finden. Also, was kommt als nächstes, nachdem Google Sie im Stich gelassen hat? Twittern natürlich!

Ich habe die Frage gestellt , ob jemand eine Lösung für barrierefreie 3D-Modelle kennt . Ich habe ehrlich gesagt nicht damit gerechnet, dass jemand antwortet. Ich dachte bei mir: „Diese Technologie ist so neu. Niemand hat diesen Bereich des Webs bisher wirklich erforscht.

Zu meiner Überraschung erhielt ich einige Tage später eine Antwort auf Twitter:

Es genügt zu sagen, dass ich mehr als begeistert war, diese Antwort zu erhalten. Eine Lösung schien möglich. Die Bereitstellung eines barrierefreien 3D-Modellerlebnisses für Shopify-Partner zur Implementierung, für unsere Millionen von Händlern zur Bedienung und deren Kunden zur Nutzung könnte tatsächlich Realität werden.

Wie sich herausstellte, war die Webkomponente <model-viewer> von Google tatsächlich die 3D-Modellkomponente, die das Rich Media-Team von Shopify implementieren wollte. (Ich weiß, oder? Wie stehen die Chancen?) Damit beschloss ich, mir etwas Zeit von meiner ständig wachsenden To-do-Liste zu nehmen und mehrere Testrunden durchzuführen. Um genau einzuschätzen, wie zugänglich die Dinge waren, und um Empfehlungen zu geben (sowohl für Google- als auch für Shopify-Teams), musste ich <model-viewer> gründlich mit Hilfstechnologien testen.

Was ist ein 3D-Modell?

Bevor wir uns mit den Testergebnissen befassen, versuchen wir zu definieren, was ein 3D-Modell ist und was nicht. Die Antwort auf diese Frage wird entscheidend sein, wenn (versucht) die Präsenz eines 3D-Modells im Web für Hilfstechnologien zu vermitteln. Mit anderen Worten: „Was ist dieses Ding? Was macht es? Wie interagiere ich damit?“

Erstens ist ein 3D-Modell kein Bild (HTML- img -Element). Bilder sind statisch und stellen eine zweidimensionale, einseitige Ansicht eines Objekts oder einer Szene dar. Bilder erfordern keine Benutzerinteraktion (außer das Bild zu entdecken und seinen alt -Text über einen Bildschirmleser zu lesen). Daher sollte ein 3D-Modell nicht als Bildelement übermittelt werden.

Zweitens ist ein 3D-Modell kein Video (HTML video ). Ja, Video ist ein dynamisches Medium; Es erfordert eine Benutzerinteraktion, um seinen Inhalt zu konsumieren. Aber Video ist ein passives Medium. Das heißt, sobald Sie auf Play drücken, muss sich der Benutzer nur noch zurücklehnen und die Show genießen. Andere interaktive Elemente sind verfügbar (Timeline-Scrubber, Stummschaltung, Untertitelsteuerung usw.), sind jedoch für den Großteil der Benutzererfahrung nicht erforderlich . Daher sollte ein 3D-Modell nicht als Videoelement vermittelt werden.

Was ist also ein 3D-Modell? Vielleicht haben Sie bereits eine Antwort darauf in Ihrem eigenen Kopf. Mein Versuch diese Frage zu beantworten ist:

„Ein 3D-Modell stellt ein reales physisches Objekt dar. Ein Objekt, das nicht nur Breite und Höhe, sondern auch Tiefe aufweist. Das Betrachten eines Objekts in der dritten Dimension ermöglicht die Inspektion aller Winkel des Objekts.“

Okay, großartig, das macht (zumindest für mich) Sinn. Aber wie beschreiben wir das in Bezug auf ein interaktives "Ding" im Web? Welche semantische Bedeutung gibt es, um den Benutzer über das Objekt zu informieren, mit dem er gerade interagiert? Und wie interagieren sie mit diesem Objekt?

Ich denke, ich habe eine gute Antwort auf diese Fragen, aber lassen Sie uns zunächst auf einige Annahmen und Erwartungen darüber eingehen, was ein zugängliches 3D-Modell ausmachen könnte.

Was macht ein 3D-Modell „zugänglich“?

Hier ist meine Kriterienliste für das, was ich für eine zugängliche Benutzererfahrung mit 3D-Modellen halten würde. Obwohl diese Kriterien (noch) nicht von Benutzern getestet wurden, denke ich, dass die übermittelten Informationen für jemanden ausreichen würden, der verschiedene Hilfstechnologien verwendet, um zu verstehen, was die Komponente ist und wie man damit interagiert. Nochmals, vollständige Offenlegung, ich verwende hier mein bestes Urteilsvermögen.

Erwartungen/Annahmen zur Verwendbarkeit von 3D-Modellen

• Ein Mausbenutzer sollte in der Lage sein, zum Drehen und Zoomen des Modells zu klicken, zu greifen/zu wischen und zu scrollen
• Ein sehender mobiler Benutzer sollte in der Lage sein, zu wischen und Pinch-Gesten zum Drehen und Zoomen des Modells zu verwenden
• Ein sehender Benutzer, der nur die Tastatur verwendet, sollte einen sichtbaren Fokusstatus sehen, wenn das 3D-Modell den Tastaturfokus hat
• Ein Tastaturbenutzer sollte in der Lage sein, das Modell allein über die Tastatur horizontal und vertikal zu drehen
• Ein Tastaturbenutzer sollte in der Lage sein, das Modell allein über die Tastatur zu vergrößern und zu verkleinern
• Ein Screenreader-Benutzer sollte ein entsprechendes hören role , die das Bauteil als 3D-Modell beschreibt
• Ein Screenreader-Benutzer sollte eine kurze Beschreibung des 3D-Modellobjekts hören
• Ein Screenreader-Benutzer sollte zusätzlichen Hinweistext hören, um näher zu beschreiben, wie er mit dem 3D-Modell interagiert
• Ein Screenreader-Benutzer sollte beschreibende Ansagen des sichtbaren Teils/Winkels hören, wenn das 3D-Modell gedreht wurde
• Ein Screenreader-Benutzer sollte eine Ansage zum Zoomen hören, die die aktuelle Zoomstufe beschreibt
• Ein mobiler Screenreader-Benutzer sollte in der Lage sein, zu wischen und Pinch-Gesten zum Drehen und Zoomen des Modells zu verwenden
• Ein Sprachdiktierbenutzer, Switch-Benutzer oder jeder mit eingeschränkter Mobilität sollte in der Lage sein, das 3D-Modell mit speziellen button für jede dynamische Funktionalität zu drehen und zu zoomen

Mit dieser Unterstützung sollte jemand, der eine Maus, eine Tastatur, ein mobiles Gerät, einen Bildschirmleser, eine Sprachaktivierung oder eine Reihe anderer Eingabetechnologien verwendet , in der Lage sein, das 3D-Modell zu verstehen und damit zu interagieren. So jedenfalls die Theorie.

Lassen Sie uns unter Berücksichtigung dieser Kriterien in einige Testergebnisse eintauchen und überprüfen, wie sich <model-viewer> an den oben genannten Kriterien gemessen hat.

Erste Testergebnisse

Folgendes habe ich beim Testen von <model-viewer> mit verschiedenen Browser- und Screenreader-Kombinationen auf Desktop- und Mobilgeräten gefunden. Die Testumgebung enthielt die Standarddemo auf Glitch .

Glitch-Demo-Testergebnisse

Betriebssystem	Browser	Bildschirmleser	Anmerkungen
Mac OS	Safari	Voice-over	✅ Fokus auf canvas : „Ein 3D-Modell eines Astronauten, Bild … Verwenden Sie die Maus, Touch- oder Pfeiltasten, um die Kamera zu steuern!“ ✅ Über die Tastatur: Passt die Modellposition an, kündigt den aktuell sichtbaren Quadranten an.
Mac OS	Chrom	Voice-over	✅ On canvas focus: "Ein 3D-Modell eines Astronauten, Gruppe … Verwenden Sie die Maus, Touch- oder Pfeiltasten, um die Kamera zu steuern!" ✅ Über die Tastatur: Passt die Modellposition an, kündigt den aktuell sichtbaren Quadranten an.
iOS	Safari	Voice-over	❌ Ignoriert das canvas -Element vollständig.
Windows	IE 11	KIEFER	❌ Fokus auf der canvas : „Blick von der Bühnenfront.“ ❌ Verwenden einer Tastatur: Navigiert durch Inhaltsknoten hinter canvas -Elementen.
Windows	Rand	KIEFER	✅ Fokus auf canvas : "Ein 3D-Modell eines Astronauten, Grafik." ❌ Verwenden einer Tastatur: Navigiert durch Inhaltsknoten hinter canvas -Elementen.
Windows	Feuerfuchs	NVDA	✅ Fokus auf der canvas : "Ein 3D-Modell eines Astronauten, anklickbar … Verwenden Sie die Maus, Touch- oder Pfeiltasten, um die Kamera zu steuern!" ❌ Verwenden einer Tastatur: Navigieren Sie durch Inhaltsknoten hinter canvas -Elementen.
Android	Chrom	TalkBack	❌ Fokus auf canvas : „ Blick von der Bühnenfront, Grafik. Alle 3D-Modelle auf der Seite wurden geladen.“ ❌ On (2nd?) canvas Focus: „Benutze die Berührungs-, Maus- oder Pfeiltasten, um die Kamera zu steuern. Doppeltippen, um sie zu aktivieren.“ ✅ Doppeltippen mit zwei Fingern, Wischen mit zwei Fingern: Passt die Modellposition an und kündigt den aktuell sichtbaren Quadranten an.

Mit diesen Ergebnissen ist klar, dass VoiceOver den besten Support hatte. Dies liegt daran, dass der virtuelle Cursor von VoiceOver mehr als einen einzigen Pfeiltastendruck benötigt, um den Inhalt zu durchlaufen. Andere wie NVDA oder JAWS verwenden einfach die Aufwärts- und Abwärtspfeiltasten , die ihre Cursor anstelle der erwarteten vertikalen Drehung am Modell vorbei bewegen. Es gibt eine Möglichkeit, dies zu umgehen, die wir später besprechen werden.

Empfehlungen an das Google-Team

Beim Testen von <model-viewer> auf Best Practices für die Webzugänglichkeit war sofort klar, dass das Team von Google Gedanken und Mühe darauf verwendet hat, diese Webkomponente barrierefrei zu machen. Funktionen wie die Pfeiltastenunterstützung für die Modellrotation und Screenreader-Ankündigungen für die Standorte der Modellbühnen waren standardmäßig integriert.

Beim Testen sind mir einige Schlüsselelemente aufgefallen, die die Komponente mit Hilfstechnologien noch besser nutzbar machen könnten.

1. Fügen Sie einen Fokusring über :focus-visible hinzu

Dem Modellelement fehlte eine sichtbare Fokusanzeige beim Tastaturfokus. Während es wünschenswert sein kann, den standardmäßigen Fokusring zu entfernen, der beim Mausklick erscheint, muss ein Fokusring vorhanden und sichtbar sein, wenn Tastaturbenutzer mit dem Modell interagieren. Sehende Benutzer müssen wissen, wo sie sich auf der Seite befinden, wenn sie durch Inhalte navigieren.

Ich habe eine mögliche Problemumgehung vorgeschlagen, indem Sie die Fokus-sichtbare Polyfüllung implementieren. Die Idee wäre, das Polyfill innerhalb von <model-viewer> zu kapseln, um einen Fokusring bereitzustellen. Wenn dies vorhanden ist, kann das Team den Umriss für Maus/Berührung entfernen, aber nur den Umriss für die Tastatur anzeigen.

2. Eine genauere role

Das 3D-Modell wurde (damals) per HTML- canvas auf den Bildschirm gezeichnet. Bei der Interaktion mit canvas mit role ist die Standardrolle „Bild“ oder „Grafik“ (je nach Betriebssystem/Hilfstechnologie). Wie bereits erwähnt, ist diese Beschreibung des aktuell fokussierten Elements nicht genau; Ein 3D-Modell ist kein statisches Bild.

Um die Tatsache zu umgehen, dass „3D-Modell“ kein nativer Medientyp mit einer organischen Rolle ist, empfahl ich dem Google-Team, das Attribut aria-roledescription direkt in das canvas -Element aufzunehmen. Mit diesem Attribut kann der Autor einen benutzerdefinierten „Rollen“-Wert festlegen, der als Element role bekannt gegeben wird – das „Ding“, mit dem Sie gerade interagieren. In diesem Fall habe ich vorgeschlagen, das Attribut aria-roledescription="3d model" hinzuzufügen, um das canvas -Element als "3d model" anzukündigen.

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

Es ist erwähnenswert, dass die Verwendung von aria-roledescription ein wenig destruktiv sein kann. Dieses Attribut überschreibt die role des nativen Elements, die wahrscheinlich zu 100 % nicht ideal ist. Im Zusammenhang mit einem Inhalt, der keine native Rolle hat, halte ich die Verwendung von aria-roledescription zur Beschreibung einer 3D-Modellkomponente für einen geeigneten Anwendungsfall.

Sehen Sie sich Adrian aria-roledescription vermeiden “ an, um weitere Einzelheiten über die Fallstricke bei der Verwendung dieses Attributs zu erfahren.

3. Geben Sie benutzerdefinierte Beschreibungen pro Stufenvariante an

Wenn die Pfeiltasten der Tastatur verwendet wurden, um den Winkel des Modells einzustellen, wurde eine Ansage gemacht, um den Benutzer auf die sichtbare Änderung aufmerksam zu machen.

Es ist großartig, wie dieser Bedarf berücksichtigt und standardmäßig in die Webkomponente aufgenommen wurde. Mein nächster Gedanke nach dieser Entdeckung war jedoch: „Kann das konfigurierbar sein? Ist es möglich, eine weitere Beschreibung des Objekts in einem bestimmten Winkel hinzuzufügen?“ Jede Stufenbeschreibung könnte auf die gleiche Weise betrachtet werden wie die Beschreibung eines Satzes statischer Bilder.

Nehmen Sie zum Beispiel ein 3D-Modell einer Baseballmütze. Das Modell würde in seiner standardmäßigen, nach vorne gerichteten Position starten. Bei der Entdeckung kann es eine hörbare Beschreibung seiner physischen Merkmale geben, einschließlich Farbe, Hutstil und vielleicht ein Logo auf der Vorderseite. Der Benutzer könnte das Modell unter Verwendung der Pfeiltasten der Tastatur um 180 Grad drehen, um die Rückseite des Hutes zu überprüfen. Wenn dieser Punkt von Interesse erreicht ist, würde eine weitere hörbare Beschreibung den potenziellen Kunden über ein braunes Lederband zur Größenanpassung informieren. Der Benutzer hoffte eigentlich auf einen Hut im Full-Back-Stil. Mit diesen Informationen entscheiden sie sich möglicherweise, andere Produkte zu überprüfen.

Wie könnte dies bewerkstelligt werden? Derzeit nimmt die <model-viewer> -Webkomponente selbst ein alt -Attribut an, um eine Beschreibung für das Modell bereitzustellen. Die Glitch-Demo bietet zum Beispiel:

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

Eine Idee, die ich dazu hatte, könnte darin bestehen, eine Reihe alternativer alt -Attribute einzuführen, die Beschreibungen von Stufenvarianten bereitstellen. Etwas wie:

< 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 >

Warum ist das wichtig? Diese zusätzlichen beschreibenden Ankündigungen würden mehr Klarheit über das Modell schaffen und alle Winkel seiner physischen Merkmale beschreiben. Da ein sehender Benutzer in der Lage wäre, die physischen Aspekte zu sehen, muss ein blinder Bildschirmlesebenutzer diese Merkmale laut beschreiben. Dies ist die gleiche Benutzererfahrung, die wir als Schöpfer des Internets anstreben sollten.

4. Abfangen von Tastatureingaben

Screenreader verfügen über eigene Tastaturbefehle zum Durchlaufen von Webseiten und Navigieren in Inhalten. Dies wird normalerweise als virtueller Bildschirmleser-Cursor bezeichnet. Wenn Sie beispielsweise NVDA verwenden, werden durch Drücken der Aufwärts- oder Abwärtspfeiltaste alle Arten von Inhalten auf der Seite navigiert und angekündigt, nicht nur fokussierbare Elemente wie Links oder Formularsteuerelemente.

Beim 3D-Modell nutzte das canvas -Element die arrow , um das Modell horizontal und vertikal zu drehen. Wenn Sie mit dem Modell interagieren, während Sie einen Bildschirmleser wie NVDA oder JAWS ausführen (da sie einzelne Pfeiltastenereignisse zum Durchlaufen von Seiteninhalten verwenden), wird der Inhalt innerhalb des <model-viewer> DOM navigiert und angesagt, anstatt den Winkel des Modells anzupassen . Das ist nicht gerade das erwartete Ergebnis.

Um dieses Dilemma zu umgehen, schlug ich dem Google-Team vor, das Attributrole="application" direkt in das canvas -Element aufzunehmen. Durch das Einschließen dieses role können die Ereignisse beim Drücken der Pfeiltaste den Bildschirmleser vollständig umgehen und die Ereignisse direkt an die zugrunde liegende Anwendung senden. In diesem Fall <model-viewer> .

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

In meinen mehr als 10 Jahren in der Barrierefreiheits-Community war dies der einzige reale Anwendungsfall, auf den ich für die application gestoßen bin. Ich bin mir auch bewusst, diesen role mit Vorsicht zu empfehlen, da er sich stark auf die Tastaturnavigation auswirkt, wenn ein Screenreader verwendet wird. Die ARIA 1.1-Spezifikation besagt:

Wenn ein Element mit einem Interaktionsmodell erstellt werden muss, das von keiner der WAI-ARIA-Widget-Rollen unterstützt wird, KÖNNEN Autoren diesem Element eine Rollenanwendung zuweisen. Und wenn ein Benutzer zu einem Element mit Rollenanwendung navigiert, SOLLTEN Hilfstechnologien, die Standardeingabeereignisse abfangen, in einen Modus wechseln, der die meisten oder alle Standardeingabeereignisse an die Webanwendung weiterleitet.

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

Léonie Watson hat einen großartigen Überblick über role="application" in dem Beitrag " Understanding Screenreader Interaction Modes ".

Testergebnisse mit einigen angewendeten Empfehlungen

Ich habe meine Empfehlungen zum Hinzufügen von role="application" und aria-roledescription , um die Empfehlungen zu bestätigen (und für meine eigene Nerd-Neugier für Barrierefreiheit). Sehen wir uns die Ergebnisse an.

Webkomponenten-Demo mit role="application" und aria-roledescription Applied

Betriebssystem	Browser	Bildschirmleser	Anmerkungen
Mac OS	Safari	Voice-over	❌ Fokus auf canvas : „Safari beschäftigt“ ❌ Verwendung der Tastatur: „Safari beschäftigt“ VoiceOver scheint Probleme mit dem „Laden“ des canvas -Inhalts zu haben. Seltsamerweise, Cmd + Tab weg von Safari, während die canvas im Fokus ist und zurückkehrt, wird der Inhalt angekündigt: ✅ On canvas focus: "Ein 3D-Modell eines Astronauten, 3D-Modell … Verwenden Sie Maus, Touch oder Pfeiltasten, um die Kamera zu steuern!" ✅ Über die Tastatur: Passt die Modellposition an, kündigt den aktuell sichtbaren Quadranten an.
Mac OS	Chrom	Voice-over	✅ On canvas focus: "Ein 3D-Modell eines Astronauten, 3D-Modell … Verwenden Sie Maus, Touch oder Pfeiltasten, um die Kamera zu steuern!" ✅ Über die Tastatur: Passt die Modellposition an, kündigt den aktuell sichtbaren Quadranten an.
iOS	Safari	Voice-over	❌ Ignoriert das canvas -Element vollständig.
Fenster	IE 11	KIEFER	❌ N/A (Demo konnte nicht geladen werden)
Fenster	Rand	KIEFER	✅ Fokus auf canvas : "Ein 3D-Modell eines Astronauten, Grafik" ❌ Über die Tastatur: Passt die Modellposition an, kündigt jedoch nicht den aktuell sichtbaren Quadranten an.
Fenster	Feuerfuchs	NVDA	✅ Fokus auf canvas : „Ein 3D-Modell eines Astronauten … Verwenden Sie die Maus, Touch- oder Pfeiltasten, um die Kamera zu steuern!“ ✅ Über die Tastatur: Passt die Modellposition an, kündigt den aktuell sichtbaren Quadranten an.
Android	Chrom	TalkBack	❌ Fokus auf der canvas : „Ansicht von der Bühne [Winkel], Anwendung. Doppeltippen zum Aktivieren.“ ✅ Doppeltippen mit zwei Fingern, dann Wischen mit zwei Fingern: Passt die Modellposition an und kündigt den aktuell sichtbaren Quadranten an.

Es war klar, dass diese Attribute bei der Zugänglichkeit des 3D-Modell-Viewers hilfreich waren. VoiceOver und NVDA schienen die beste Unterstützung zu haben, indem sie wie erwartet die Attributwerte aria-label und aria-roledescription ankündigten. Wenn role="application" eingerichtet ist, können JAWS- und NVDA-Benutzer das Modell mit den Pfeiltasten drehen.

Probleme bleiben

Hier ist ein Überblick über die wichtigsten Probleme aus den oben beschriebenen Tests.

iOS ignoriert canvas

Abgesehen davon, dass diese zweite Demo nicht mit IE oder Edge getestet werden konnte, hatte iOS die meisten Probleme. Es schien, als hätte iOS mit aktiviertem VoiceOver bei beiden Demos das canvas Element vollständig ignoriert. Bei Verwendung der Swipe-Navigation wurde sie sogar mit angewendetem tabindex vollständig umgangen.

Laut HTML5Accessibility.com können canvas -Elemente barrierefrei gemacht werden, indem untergeordnete Elemente in canvas eingefügt werden. Im Falle eines 3D-Modellbetrachters, der Ereignisse direkt vom canvas -Element akzeptiert, wäre das Einbeziehen von untergeordneten Elementen jedoch nicht hilfreich.

Probleme mit der Desktopleistung von VoiceOver + Safari

In Verbindung mit dem Safari-Browser unter macOS schien VoiceOver mit dem „Laden“ des canvas -Inhalts zu kämpfen. Bei Fokus würde VoiceOver ankündigen: „Safari beschäftigt“. Beim Verstellen der Modellposition mit den Pfeiltasten wurde wieder „busy“ gemeldet. Während es bei dieser Kombination eindeutig Leistungsprobleme gab, konnte dies nicht für Chrome in Verbindung mit VoiceOver unter macOS gesagt werden. überhaupt keine Perf-Probleme.

Seltsamerweise half dies manchmal bei der Ladeleistung, wenn Fenster von Safari weggeschaltet wurden, während die canvas im Fokus war, und dann zurückkehrten.

Chrome für Android fehlende Modellbeschreibung

Beim canvas -Fokus hat Chrome für Android standardmäßig den Winkel/die Phase des Modells in seinem aria-label anstelle der Modellbeschreibung angekündigt. Dadurch wurde im Wesentlichen die Ankündigung umgangen, womit der Benutzer interagieren würde.

Dieses Problem wurde bestätigt, indem der Chrome-Remote-Inspector verwendet und der Wert des Attributs „ aria-label “ beim Laden der Seite überprüft wurde.

Empfehlungen an das Shopify-Team

Bisher haben wir Testergebnisse und Empfehlungen überprüft, die das "Backend" des 3D-Modells betreffen. Dies ist der Teil, den das Google-Team beeinflussen würde, um <model-viewier> zugänglicher zu machen.

Bei der Implementierung der Benutzererfahrung oder dem „Frontend“ kommt das Shopify-Team ins Spiel. Für jedes Shopify-Design, das 3D-Modellunterstützung bietet, ist zusätzliche Arbeit erforderlich, um <model-viewer> in das Design zu integrieren .

Beim Testen der Implementierung für das Standarddesign von Shopify, Debut , sind mir einige zusätzliche Barrierefreiheitsprobleme aufgefallen. Hier sind einige Highlights der Empfehlungen, die ich an das Team gesendet habe.

1. Wischgesten sollten nicht erforderlich sein

Auf einem mobilen oder Touchscreen-Gerät erforderte die Drehung von <model-viewer> Wischgesten, um das Modell zu drehen. Je nach mobiler Plattform und aktiviertem Screenreader wären hierfür Wischgesten mit zwei oder drei Fingern erforderlich . Infolgedessen könnte dies zu einer schwierigen oder frustrierenden Benutzererfahrung für Benutzer mit eingeschränkter Mobilität führen, z. B. für jemanden, der Sprachdiktiersoftware verwendet.

Meine Empfehlung war, eine Ein- button -Steuerung für die Modellrotation zu implementieren; rauf runter links rechts. Dies würde eine optionale Eingabemethode bereitstellen und eine einfache Verwendung der 3D-Modellrotation ermöglichen (dedizierte Steuerelemente für Zoom und Vollbild waren bereits vorhanden).

Es ist auch erwähnenswert, dass in der bevorstehenden Veröffentlichung von WCAG 2.2 das neue Erfolgskriterium 2.5.1 Zeigergesten besagt:

„Alle Funktionen, die Mehrpunkt- oder pfadbasierte Gesten für die Bedienung verwenden, können mit einem einzigen Zeiger ohne pfadbasierte Geste bedient werden, es sei denn, eine Mehrpunkt- oder pfadbasierte Geste ist wesentlich.“

Vor diesem Hintergrund würde ich argumentieren, dass die Rotation eines 3D-Modells für seine Benutzerfreundlichkeit von wesentlicher Bedeutung ist .

2. Zoom gibt kein Ergebnis bekannt

Bei Verwendung der dedizierten Steuerelemente zum Vergrößern oder Verkleinern des 3D-Modells, dessen Ergebnis den Bildschirmleserbenutzern nicht mitgeteilt wurde.

Für dieses Problem habe ich empfohlen, dem DOM ein role="status" -Element hinzuzufügen, um die aktuelle Zoomstufe anzukündigen. Wenn entweder auf die Zoom-in- oder Zoom-out-Steuerung geklickt wird, würde eine Ankündigung erfolgen, die den Benutzer auf die aktuelle Zoomstufe als Prozentsatz aufmerksam macht.

Um zu verhindern, dass Screenreader-Benutzer diesen Inhalt aus dem Zusammenhang reißen, müsste das Attribut aria-hidden bei der Ankündigung von true auf false und dann wieder auf true umgeschaltet werden.

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

3. Steuerelemente nur beim Hover sichtbar

Die Steuerelemente des 3D-Modells für Zoom und Vollbild waren nur beim Überfahren mit der Maus sichtbar. Dies führte zu einer schwierigen Benutzererfahrung beim Erreichen der Steuerelemente für sehende Nur-Tastatur-Benutzer, Zoom-Text-Benutzer mit Sehbehinderung, Sprachdiktierbenutzer oder alle, die keine Maus verwenden konnten.

Die Empfehlung hier war, die Steuerelemente im Tastaturfokus verfügbar und sichtbar zu machen. Offensichtlich erfüllt dies immer noch nicht alle Benutzeranforderungen, wie z. B. dass Sprachdiktierbenutzer in der Lage sind, das Klicken auf eine Schaltflächensteuerung zu rufen, die sie nicht sehen können. Andere Problemumgehungen müssen in Betracht gezogen und rechtzeitig implementiert werden.

APG-Überblick und Live-Demo

Hier versuche ich, eine ARIA Authoring Practices-Stilskizze für ein 3D-Modellmuster zu erstellen. Wenn Sie nicht vertraut sind, bietet die ARIA Authoring Practices -Site Best Practices für Tastatur- und aria-* Attribute für dynamische, nicht native Komponenten. Lesen Sie es auf jeden Fall, wenn Sie das nächste Mal ein nicht natives UI-Muster erstellen.

Okay, lass uns das ausprobieren …

---

3D-Modelle

Ein 3D-Modell repräsentiert ein reales physisches Objekt. Ein Objekt, das nicht nur Breite und Höhe, sondern auch Tiefe hat. Das Betrachten eines Objekts in der dritten Dimension ermöglicht die Untersuchung aller Winkel des Objekts.

Beispiel

3D-Modellbeispiel : zeigt ein 3D-Modell eines realen Artikels auf einer Produktseite eines Demo-E-Commerce-Shops.

Bedingungen

Die folgenden Begriffe werden verwendet, um Komponenten eines 3D-Modells zu beschreiben.

3D-Modell

Ein einzelner Inhaltscontainer, der den Inhalt enthält, der von der 3D-Modellkomponente dargestellt werden soll.

Rotationssteuerung

Ein interaktives Element, das mit der Rotation des 3D-Modells beginnt.

Zoomsteuerung

Ein interaktives Element, das das 3D-Modell zoomt.

Vollbildsteuerung

Ein interaktives Element, das die 3D-Modellansicht als Vollbild einstellt.

Live-Ankündigungen

Ein verstecktes Element, das Stufenbeschreibungen und Aktualisierungsmeldungen enthält.

Tastaturinteraktion

Wenn die 3D-Modellkomponente den Tastaturfokus hat:

• Eingabe oder Leertaste : Gibt die aktuelle Bühnenposition mit Beschreibung (falls verfügbar) an.
• Tab : Verschiebt den Fokus auf das nächste fokussierbare Element in der Tab -Sequenz der Seite.
• Shift + Tab : Verschiebt den Fokus auf das vorherige fokussierbare Element in der Tab -Sequenz der Seite.
• Esc : Setzt das Modell auf seine standardmäßige Startposition und Zoomstufe zurück.
• Pfeil nach links : Schwenkt das Modell horizontal.
• Rechtspfeil : Schwenkt das Modell horizontal.
• Pfeil nach oben : Schwenkt das Modell vertikal.
• Abwärtspfeil : Schwenkt das Modell vertikal.
• + : Vergrößert das Modell.
• - : Verkleinert das Modell.

WAI-ARIA Rollen, Zustände und Eigenschaften

• Das 3D-Modell hat eineapplication .
• Für das 3D-Modell ist die Eigenschaft aria-roledescription auf 3D model festgelegt.
• Das 3D-Modell verfügt über die Eigenschaft aria-label , um einen zugänglichen Namen bereitzustellen.
• Optional wird die Eigenschaft aria-describedby für das 3D-Modell festgelegt, um anzugeben, wie mit der Komponente interagiert werden soll.
• Das Element Live-Ankündigung hat den status .
• Das Vollbild-Steuerelement hat einen aria-pressed Zustand. Wenn die Schaltfläche eingeschaltet ist, ist der Wert dieses Zustands true , und wenn sie ausgeschaltet ist, ist der Zustand false .

---

Fazit, vorerst

An diesem Punkt haben wir uns intensiv mit dem Testen von <model-viewer> für verschiedene Screenreader-Umgebungen befasst, aber dies ist nur die Spitze des Eisbergs der Hilfstechnologie. Wir müssen auch potenzielle Probleme berücksichtigen und angehen für:

• Sehende Nur-Tastatur-Benutzer
• Benutzer mit eingeschränktem Sehvermögen
• Braille-Leser
• Sprachdiktiersoftware
• Zugriff wechseln
• Und mehr…

Um eine genaue und komfortable Benutzererfahrung für alle zu schaffen, sind Usability-Tests mit echten Menschen ein Muss . (Es ist bedauerlich, dass dies nicht vor dem Start stattgefunden hat, aber dies ist in Zukunft auf unserem Radar.)

Als Schöpfer und Betreuer des Webs liegt es in unserer Verantwortung, auf die Bedürfnisse der Menschen zu achten, die Schaffung von Zugangsbarrieren zu vermeiden und damit das beste Design zu beseitigen.

Mit den hier gezeigten Testergebnissen glaube ich, dass die Infrastruktur vorhanden ist, um barrierefreie 3D-Modelle für Menschen mit Behinderungen bereitzustellen. Sowohl das Google- als auch das Shopify-Team freuten sich über die Testergebnisse, um gemeinsam daran zu arbeiten, die zugänglichste Benutzererfahrung zu schaffen. Ich bin zuversichtlich, dass sich die Benutzerfreundlichkeit und Zugänglichkeit von 3D-Modellen mit der Zeit verbessern wird.