Roland Dubois and I recently started weekly meetings where we are working collaboratively to investigate and advance the state of accessibility in Web XR experiences.
How many of the well-established and heavily used accessibility features on web-browsers can be translated into the immersive web ecosystem?
We have begun our project focusing on Roland’s aframe-gui component, a graphical user interface (GUI) component library for A-Frame. We applied the Accessible Rich Internet Application API to his GUI component library with the goal of exploring how current assistive technologies respond and perform on Windows, macOS, Android, and iOS. We will start a dialogue with the primary manufacturers (Microsoft, Google, Mozilla, and Apple) to understand what can be done to ensure better access to XR for people with disabilities.
The immersive web is a medium extension of the open web and therefore should continue leading in inclusive and accessible technology.
Trying ARIA
Our first project was exploring the simplest of components in any UI framework. We implemented an example of a button and a link.
We recommend using a button role inside of WebVR to indicate that someone can click the item.
In this example, we can use our voice to issue commands with Android / Chrome / Voice Access. This demonstration shows that the interface can be controlled with the user’s voice only.
In this example, the screen reader announces the name and role of the interface element with macOS / Safari / VoiceOver. This demonstration shows the interface can be navigated and controlled with the keyboard only.
Accessibility Specific Code Additions
- Setting the
roleattribute. Explored setting bothrole="button"androle="linkon the interactive element - Add an
aria-label. For example the first link hasaria-label="Change Color" - Adding
tabindex="0"to get the element to receive focus - Adding
onfocusandonblurhandlers to display a visual red focus rectangle when the GUI element receives keyboard focus - Adding
onkeyuphandler to listen for ENTER and SPACE so that the component can be controlled from the keyboard.
| Platform | Tool | Notes |
|---|---|---|
| iOS / Chrome | VoiceOver | Neither the aria-label or the role attribute is announced |
| iOS / Safari | Voice Control | Neither the button or the link is detected as an interactive element for the voice parser |
| Android / Chrome | TalkBack | Neither the aria-label or the role attribute is announced |
| Android / Chrome | Voice Access | Able to control both role="link" and role="button" |
| macOS / Safari | VoiceOver | Both the aria-label and the role attribute are announced and the control can be interacted with. |
| macOS / Firefox | VoiceOver | Both the aria-label and the role attribute are announced and the control can be interacted with. |
| macOS / Safari | Voice Control | Neither the button or the link is detected as an interactive element for the voice parse |
| Windows / Chrome | NVDA | Both the aria-label and the role attribute are announced and the control can be interacted with. |
| Windows / Chrome | Speech Recognition | Neither the button or the link is detected as an interactive element for the voice parse |
This is our first post in a series of ongoing experiments. While we currently focus on desktop and mobile/touch devices, we are planning to explore immersive web browsers on VR and AR headsets.
Please share with us your thoughts and feedback, we are looking forward to incorporating your thoughts on inclusive and accessible use cases.
References
- Live Demonstration: A-Frame Accessibility Experiment
- Using the Link role
