Outstanding a11y work 2019 Q2 #464
Labels
arc: compatibility
arc: interaction
flag: meta
flag: partner
Issues or PRs opened by an integrating partner, or affecting one in an important way
type: feature
New feature or request
Description
Here's what I've found while testing
<model-viewer>
with various browsers, screen readers, and devices. I tested the default demo on Glitch, and a local demo with the two suggested changes applied as described from #443.Glitch Demo
Current support matrix of
<model-viewer>
on Glitch:(Note:
role="application"
oraria-roledescription
has not been applied.)✅ Using keyboard: adjusts model position, announces currently viewable quadrant.
✅ Using keyboard: adjusts model position, announces currently viewable quadrant.
❌ Using keyboard: navigates content nodes behind canvas element.
❌ Using keyboard: navigates content nodes behind canvas element.
❌ Using keyboard: navigates content nodes behind canvas element.
❌ On (2nd?) canvas focus: "Use touch, mouse, or arrow keys to control the camera. Double tap to activate."
✅ Two finger double tap, two finger swipe: adjusts model position, announces currently viewable quadrant.
Web Components Demo
Current support matrix of
<model-viewer>
web component demo:(Note: Local fork of the GitHub repo, both
role="application"
andaria-roledescription
attributes have been applied.)❌ Using keyboard: "Safari busy"
VoiceOver seems to struggle with "loading" the canvas content. Oddly enough, Cmd + Tab away from Safari while the canvas is in focus and returning back, content is announced:
✅ On canvas focus: "A 3d model of an astronaut, 3d model viewer … Use mouse, touch or arrow keys to control the camera!"
✅ Using keyboard: adjusts model position, announces currently viewable quadrant.
✅ Using keyboard: adjusts model position, announces currently viewable quadrant.
❌ Using keyboard: adjusts model position but does not announce currently viewable quadrant.
✅ Using keyboard: adjusts model position, announces currently viewable quadrant.
✅ Using two-finger double tap, then two-finger swipe: adjusts model position, announces currently viewable quadrant.
It's clear that these attributes do help in the accessibility of the 3D model viewer; VoiceOver and NVDA seem to have the best support by announcing the
aria-label
andaria-roledescription
attribute values as expected. Withrole="application"
set in place, VoiceOver and NVDA users are able to interact with the model.Some issues remain
However, things are far from perfect. Here's an overview of the major issues from the tests outlined above.
iOS
Aside from not being able to test this second demo with IE, it's iOS which has the most issues. It seems like, with either demo, iOS with VoiceOver enabled completely ignores the
canvas
element. When using swipe navigation, even withtabindex
applied, it's bypassed completely.According to HTML5Accessibility.com,
canvas
elements can be made accessible by including child elements withincanvas
. However, in this case of a 3D model viewer accepting events from thecanvas
element directly, including child elements doesn't help.More research, asking for help from the greater community, or perhaps filing a bug with Apple will need to follow suit in order to provide an equal experience for our iOS users.
VoiceOver + Safari on macOS
When paired with Safari browser, VoiceOver on macOS seems to struggle with "loading" the
canvas
content. On focus, VoiceOver would announce, "Safari busy." When using the arrow keys to adjust the model position, "busy." There seems to be a performance issue with this combination as the same cannot be said for Chrome paired with VoiceOver on macOS.Oddly enough, Cmd + Tab away from Safari while the
canvas
is in focus and returning back seems to sometimes help with this; content would be announced as expected.Related tickets
aria-label
should be static:focus-visible
Versions
The text was updated successfully, but these errors were encountered: