A-Frame Accessibility Evaluation

A-Frame and Accessibility

As a popular open source project, A-Frame has a unique blend of built in features and external components that flesh out it's functionality. Many of these features add the ability to create scatter plots, animations, moving gifs and more.  Others add functionality that falls into the realm of accessibility like speech commands, positional audio and screen reading. Thus I am evaluating A-Frame according to the XR accessibility guidelines to identify potential areas of improvement. 

Testing and Evaluation Methodology

My testing  and evaluation consisted of copious online research about existing A-Frame functionality, potential components, and even workarounds for different requirements.  I also tested many existing components, experimented with combination of features in A-Frame to recreate some of these requirements, and read articles and papers about accessibility. I also considered comparisons to other popular VR development software and headsets. 

Evaluation Rubric

Robust Options: This means that A-Frame has numerous options or possibilities for this kind of functionality. That can include built in features, a wealth of components and more. Thus this functionality should be easy to add to applications and there are no excuses not to include this in your applications. I use this primarily when these features are explicitly addressed by A-Frame or components. If they require a bit of developer creativity and experimentation, they are categorized as Possible instead. 

Possible: This means that A-Frame can have this functionality in some capacity. It may require a bit of a “maker mentality” and tweaking to get it to work but can be added. These often aren’t a defined feature of A-Frame or an explicit component. Instead one would use existing features of A-Frame together to achieve this functionality like using a text component to represent subtitles. 

In Progress: This means that the A-Frame community is experimenting with this type of functionality or that it is in its early stages. I put this instead of Needs Improvement when I have seen active development in this area like recent Github repos and forum posts, 

Needs Improvement: This means that the A-Frame community should really try to focus on adding or refining this technology. This can include now outdated/broken components. This includes areas where there are very crude workarounds. I may also propose potential solutions to these shortcomings. 

No Options: This means I am unable to find any proof of this being associated with A-Frame. In many cases this will be technology that is simply not viable yet or highly theoretical. 

Unknown or Needs Further Evaluation: This means that in my current capacity I am unable to evaluate A-Frame’s ability to have this functionality. This tends to be accessibility features that require external technology or software which I don’t have access to. 

Verdict/ Different Verdict: Sometimes I will put an in between category for cases where I feel that one verdict is not entirely supported but there is still ample enough evidence in its favor. 

Evaluation By Category

Immersive semantics and customization

Need: A user of assistive technology wants to navigate, identify locations, objects and interact within an immersive environment.

Verdict: Possible

Explanation: There is a component that lets a user add aria attributes to A-Frame. Aria or Accessible Rich Internet Applications is web tagging functionality that allows screen readers to communicate what a user is looking at and provide additional input instructions. When a cursor looks at an entity with a supported aria-attribute, the browser will add focus on the HTML element. This allows users to query objects for more information, highlight important objects, navigate the space

This category also includes customizable control and navigation capabilities and filtering objects. There are capabilities to customize A-Frame control types and inputs. Likewise you can add visible navigation meshes to see the trajectory and movement of objects. A developer can also use features like mixins and object types to allow users to filter the objects in space and eliminate certain ones or show others. Thus A-Frame can definitely achieve most of this requirement but it may require quite a bit of effort on the developers part. 

Motion agnostic interactions

Need: A person with a physical disability may want to interact with items in an immersive environment in a way that doesn't require particular bodily movement to perform any given action.

Verdict: Possible

Explanation: This is a challenging verdict to make. A-Frame has a wealth of control schemes and input options. One can easily mix them so that an application has gaze controls, joystick controls and gesture controls all at once. For example, if a user is unable to use their hands to grip or manipulate a controller, they could use their head to view and interact with objects. Thus A-Frame definitely lets its users mix and match and does not make them stick to one control scheme.

That said there may be cases where users who really struggle with all forms of motion interactions may be disappointed. As will be expanded upon further later on, there are very few purely motion agnostic control options available i.e. it is challenging for a user to navigate or control a scene without moving at all. 

Immersive personalization

Need: Users with cognitive and learning disabilities may need to personalize the immersive experience in various ways.

Verdict: Possible 

Explanation: This concerns a user's ability to change the way objects are displayed. For instance adding symbols to buttons so a user knows which button grabs a box versus which one drops a box. It is pretty easy to add colors, logos and more to A-Frame objects for this feature.

Likewise if a user wanted to make all objects only two colors for contrast or eliminate auxiliary objects, this could be added. Animations and audio can also be easily turned off, muted or modified. 

The key to this personalization is creating unintrusive menus or a GUI that allows users to customize their experience. Fortunately A-Frame has several GUI options. 

Interaction and target customization

Need: A user with limited mobility, or users with tunnel or peripheral vision may need a larger 'Target size' for a button or other controls.

Verdict: Possible

Explanation: It is pretty easy to make objects larger or smaller with a bit of tweaking and you can even map this to a gui. There are components that allow for the creation of a resizable and dynamic gui in A-Frame as well as resizable buttons and affordances. In many cases, a point and click gui can be made to handle cases where a user struggles with fine motor control or specific gestures can still perform an action. For instance rather than grabbing, pinching and stretching a box to resizeable it, a user could click a button that automatically grabs the box or a button that automatically resizes the box without a need for multiple different gestures at once. 

Voice commands:

Need: A user with limited mobility may want to be able to use Voice Commands within the immersive environment, to navigate, interact and communicate with others.

Verdict: Needs Improvement

Explanation: This is a major area of weakness for A-Frame and why I felt unsure about declaring A-Frame as having robust control options. There is no built-in speech functionality. Previously there was a speech command component built in the Annyang speech recognition library. However, that component no longer works with modern versions of A-Frame and should be updated or replaced. I did try to work with Annyang specifically and it may be a possible way to implement this in the future. Since this one of the most useful and necessary control types, the fact there isn’t a good implementation is a huge shortcoming. 

Color changes:

Need: Color blind users may need to be able to customise the colors used in the immersive environment. This will help with understanding affordances of various controls or where color is used to signify danger or permission.

Verdict: Robust Options

Explanation: This is a built-in feature in most A-Frame objects. You can easily change item colors with properties like mixin to make a set color for all objects. You can even add gui features to easily change all colors. Most components also come with easy to change color options. 

One area that could use some exploration is the idea of filters or outlines to be applied to an A-Frame objects. Some filters can help enhance contrast and the user experience. One user seems to have experimented a bit with filters this but ultimately abandoned it four years ago. Likewise an outlines component has similarly become out-dated.

Magnification context and resetting

Need: Screen magnification users may need to be able to check the context of their view in immersive environments.

Verdict: Needs Improvement

Explanation: Zoom/Magnification in A-Frame is not really a feature. Most online forums discuss simply enlarging objects in the scene in the place of zoom but zoom in its normal definition is not available. This should be a major area of exploration as zoom is an essential feature for people of all abilities and can definitely enhance the A-Frame user experience. For instance being able to zoom in on an object in the distance rather than move to it. Likewise for visually impaired users, zoom is a essential feature for their enjoyment of VR

Critical messaging and alerts

Need: Screen magnification users may need to be made aware of critical messaging and alerts in immersive environments often without losing focus. They may also need to route these messages to a 'second screen' 

Verdict: Possible

Explanation: You can use HTML alerts to inform the user of critical information like a timer being expired, winning, an error. 

This obviously works better when a user is using a VR application in browser rather than in the headset as the alerts will not be as intrusive. In most instances, if you are in an immersive VR experience, it will kick you out to the Oculus browser. This can be both helpful or frustrating depending on the situation. 

Gestural interfaces and interactions

Need: A blind user may wish to interact with a gestural interface, such as a virtual menu system.

Verdict: In Progress

Explanation: This is a feature that seems like it is in its infancy for A-Frame. There is nothing in A-Frame as sophisticated as Oculus’ gestural interface which lets users conjure a menu by twisting and pinching their hand. Most gesture commands are merely hovering, pinching or tracking a hand making a fist. 

That said users are experimenting with very granular hand tracking technology that extends to individual joints. This could result in an even wider range of gestures. Advances in this will likely be a result of the open source community rather than A-Frame itself. 

Example: https://github.com/gftruj/aframe-hand-tracking-controls-extras

Signing videos and text description transformation

Need: A deaf or hard of hearing person, for whom a written language may not be their first language, may prefer signing of video for text, objects or item descriptions.

Verdict: No Options

Explanation: This is already a very experimental kind of technology which will take years to refine even for the likes of Oculus, Vive and more. Thus there isn’t much likelihood A-Frame will have this any time soon, if ever. Likewise there is research suggesting that signing avatars are less helpful and expressive as trained and qualified translators and interpreters which adds new challenges to the design of digital avatars. 

Safe harbour controls

Need: People with Cognitive Impairments may be easily overwhelmed in Immersive Environments.

Verdict: Possible

Explanation: One could map a button such that the user can easily exit the application or navigate to an A-Frame safe space. I’m defining this as possible since this may take a bit of tweaking and customization. 

Immersive time limits

Need: Users may be adversely affected by spending too much time in an immersive environment or experience, and may lose track of time.

Verdict: Possible

Explanation: A-Frame has the ability to add timed events. You can create visible timers in your scene or interface. Thus there is a possibility to have a timer set for the scene where after a certain duration the scene disappears, or turns black, or resets. In one example, the user is kicked from the A-Frame scene and met with a “Time’s Up” alert upon the expiry of the timer. 

Example: https://medium.com/@kewalkishan/writing-a-simple-timer-component-for-a-frame-81889c863589

Orientation and navigation

Need: A screen magnification user or user with a cognitive and learning disability or spatial orientation impairment needs to maintain focus and understand where they are in immersive environments.

Verdict: Possible/Needs Improvement

Explanation: For this case, it is pretty easy to set a default position or settings for a user's camera. Thus if someone got lost in a space, one could set a hotkey that brings a user back home. One could also program specific objects to emit audio like an object at the starting point or home so a user knows how to get back to the starting position. 

That said, one potential addition/future component could be a map of the A-Scene. This could be displayed as an overlay in the top corner of the user’s vision and could prove information like location within the A-Scene, camera direction, even the position of objects. I feel like since A-Frame’s objects, camera, scene, sky all rely on positional coordinates and A-Scene’s tend to be pretty simplistic, this is very possible and an area for future development. 

Second screen devices

Need: Users of assistive technology such as a blind, or deaf-blind users communicating via a RTC application in XR, may have sophisticated 'routing' requirements for various inputs and outputs and the need to manage same. 

Verdict: Unknown/Needs Further Testing

Explanation: I was unable to test this one as I don't have any second screen devices. However, since second screen devices work with modern web browsers and A-Frame is HTML and browser based, I assume there would be some overlap. 

Interaction speed

Need: Users with physical disabilities or cognitive and learning disabilities may find some interactions too fast to keep up with or maintain.

Verdict: Possible

Explanation: This specific need applies more so to games and interactive applications rather than visualization. That said, most animations in A-Frame are customizable. Thus if you make an application where a user has to chase and grab a moving object, you could easily set that object’s behavior to move slower or be bigger. Likewise if a user added quick time events that need a quick reaction or an event where a user needs to “mash” a button. Make sure to add alternative setting like a singular button press, forgiving timing windows

Avoiding sickness triggers

Need: Users with vestibular disorders, Epilepsy, and photo sensitivity may find some interactions trigger motion sickness and other affects. This may be triggered when doing teleportation or other movements in XR.

Verdict: Robust Options 

Explanation: There are several options to prevent sickness triggers in A-Frame. The biggest sickness trigger that I found was in the camera movement, particularly when it moved quickly and unnaturally. Obviously a solution to this is changing the camera movement speed. A-Frame also has built in and component teleportation functionality which has also been proven as a way to avoid sickness in VR. Other control schemes like gaze controls can also be a way to view content in a natural and progressive range of motion. In terms of epilepsy and photosensitivity, efforts can be made to change colors, brightness, lightning and more to ease the user experience. 

Spatial audio tracks and alternatives

Need: Hard of hearing users may need accommodations to perceive audio.

Verdict: Robust Options 

Explanation: Audio in A-Frame is positional and immersive which is a huge help for accessibility. It is very easy to have objects emit a sound and in my tests, users were able to navigate to objects through this method. You can control aspects like volume, sound roll off, turn sound on and off, set reference distances and even control sound distance models. It is easy to get multiple sounds to play at once and even have sounds play on events like interacting or selecting an object. 

That said, alternatives to sound like text describing important audio is not necessarily a feature of the audio component but could be added by the developer using the text component. 

Spatial orientation: Mono audio option

Need: Users with spatial orientation impairments, cognitive impairments or hearing loss in just one ear may miss information in a stereo or binaural soundscape.

Verdict: Needs Improvement

Explanation: There is no distinct setting in the audio component for mono vs stereo audio. Likewise, positional audio relies heavily on being able to hear with both ears, thus applications that rely on positional audio may be disappointing to users who rely on only one ear. 

Captioning, Subtitling and Text: Support and customization

Need: Users may need to customise captions, subtitles and other text in XR environments.

Verdict: Needs Improvement/Possible

Explanation: There aren’t really any specific caption or subtitle components. There was some experimentation with captions for React 360 videos a few years ago but there isn’t much now.

You can put A-Frame text on the scene and set timers, colors, size etc. There are ways to get geometry to scale to text and text to scale to geometry. You can also select specific fonts. But this requires tweaking and may be challenging to sync up with audio tracks. 

Thus while A-Frame definitely has robust text options, this is an area that can always use a bit of improvement as its pretty essential to all kinds of A-Frame applications. 

Conclusions

Ultimately there isn't much accessibility functionality that A-Frame completely lacks as evidenced by the number of "Possible" ratings. Some features are easy to implement and some requires experimentation and engineering. There were only two cases where there were "No Options" or "Unknown". The open source community should definitely consider developing functionality for captions, speech commands, zoom/magnification and navigation. I encourage future Wiki users to also add and update this evaluation as they see fit. 

Regardless, A-Frame is in a strange position. As an open source project, it is maintained by both Supermedium and Google as well as the larger enthusiast community. However,  A-Frames momentum seems to have slowed.  A-Frame's "gold rush" was about five years ago which led to an explosion of component development, a number of which are now outdated, deprecated and abandoned projects including valuable and vital components like Speech Commands. That said there are still numerous projects in development covering concepts like Super Hands and Gesture Commands which can really aid accessibility in A-Frame. Hopefully further expansion and adoption of VR technology will lead to a renewed interest in A-Frame and WebXR as a whole and inspire users to continue developing accessibility features.