In today’s world, accessibility is far more than just a ‘nice-to-have’. It’s essential if you want to promote inclusivity and reach a wide audience.
“Making applications accessible not only ensures equal access to the roughly 1 billion people in the world with disabilities, but also benefits people without disabilities by allowing them to customize their experiences,” writes Google in their accessibility resources for developers and publishers.
Let’s start from the very beginning: Accessibility is important every step of the way, not only in the end product of your app!
Where does that actually start? When your company’s product is an API or software, it begins with making that accessible to developers first and foremost — and that means creating accessible documentation.
Since High Fidelity has an API (and licensing options for native apps) for developers to integrate real-time spatial audio to various web apps, we’ve given a lot of thought to this. Documentation and guides are frequently hosted on the web, too, which highlights the importance of web accessibility — here are some important guidelines for that.
In a 2018 survey done by StackOverflow, it was found that 1 out of every 200 developers identified as being blind or hard of sight. Carolyn Stransky spoke at GDG DevFest about A11y-Friendly documentation: “Even if we think about how narrow the participant set was for this survey, we can imagine there are probably so many people who were not accounted for in this… People who are probably trying to read our documentation.” And in the 2021 StackOverflow survey of 80,000 developers, 2,960 participants responded they identify as blind or have difficulty seeing. That’s 3.7% or 1 out of 27 respondents.
Let's go over the two most important document accessibility standards.
Ensure Documentation is Clear and Readable For All
High Fidelity uses Fable, an online testing platform that connects us to a diverse group of people with disabilities who use various assistive technologies. To examine our documentation, we conducted interviews with developers attempting to navigate through a beginner guide: “Build a Simple Web App with Spatial Audio”.
In our first interview, the developer using a screen reader provided positive feedback. Everything seemed accessible on the surface: They were able to navigate the guide with their keyboard and screen reader with no issue. Heading levels were correct (a quick nod to the importance of web accessibility!). Everything appeared to be read aloud accurately…
But then we realized: Important key terms are presented in a different color — and those key terms clearly stand out for sighted users — but they didn’t register as anything special for those using screen readers! Information wasn’t presented equally.
Similarly, the “project complexity” of the guide was represented visually as stars (★☆☆☆☆), and was not read aloud by the screen reader. In both of these cases, it’s important to remember that if text or images have specific visual connotations or emphasis, you’ll need to incorporate information that assistive technologies can parse as well. One example of this would be adding ARIA to highlight (with the screen reader) that such text is a key term.
In a second interview, we did another pass through the “How to Build a Simple Web App” guide where the same developer used a braille display instead of a screen reader. It connects to the computer and text on the screen is rendered on the device as braille. Using that technology, he was able to learn what words have special capitalization. For example, the braille display indicated “getUserMedia” has no spaces, along with a capital U and M. In this case, the screen reader may not have made that clear.
Simply put: The most important thing in creating accessible documentation for APIs comes down to making sure the web page, text, and any visual representations or images are accessible to various assistive technologies. That means they are clear, and can be read — by all.
"Clear" documentation also follows web accessibility guidelines. As a quick review, that includes proper headings, correct labeling for links and buttons, readable text with good contrast, and making sure it can be navigated with a keyboard. Here is a more in depth post of web accessibility guidelines for developers.
In the end, the tester at Fable was able to successfully follow the instructions on our guide for building a simple web app.
Ensure Documentation is Inclusive
There’s more to think about beyond usability, too — language is also quite important. Google’s developer documentation style guides have some great guidelines and examples that illustrate best practices to keep diversity and inclusion in mind. For instance, avoid ableist language, unnecessarily gendered language, and unnecessarily violent language.
Include specifically diverse and inclusive examples, such as using gender-neutral pronouns. When writing documentation, write about features and users in inclusive ways: “For example, instead of referring to people as native speakers or non-native speakers of English, consider whether your document needs to discuss this at all, and revise it to discuss the feature in terms that are relevant to anyone regardless of what languages they know.” Avoid bias and harm when discussing disability and accessibility. Google writes, “Take the time to educate yourself about the ways that the communities that you're writing about prefer to be identified and described before writing about them in your documentation.”
Jennifer Sutton also wrote an awesome 40 page guide to making documents accessible to people who are blind or visually impaired, covering a huge variety of aspects.
Accessible Documentation Leads to Accessible Apps
A world with more diverse creators builds a world with more diverse content and products available — and that benefits us all!
Our overall goal is to make the pipeline for making apps that use spatial audio accessible: Developers who use assistive technologies should be able to easily access our documentation and use our API. We’re excited to see what is already being built with our spatial audio.
In recent news, Clubhouse integrated High Fidelity’s Local Spatializer, facilitating more natural and immersive conversations on their social audio app. Research actually shows that spatial audio can help those who are blind better orient themselves in virtual environments, among other benefits. In fact, on Twitter, several people have already commented on Clubhouse’s new spatial audio improving the experience for the visually impaired...
OMG. I just updated the app and now hear @Clubhouse townhall in spatial audio. This is actually amazing!— Mohit Arora / @9 on #Clubhouse (@_MohitArora) August 29, 2021
This is definitely going to be a big help for the visually impaired to better follow when different people are speaking
Listening now, and if you’re in the audience it really helps separate out new voices when someone starts to speak, will be good for accessibility— Morgan Evetts (@morqon) August 29, 2021
As they talk the voice is gradually phased to a more central position, so you don’t have someone “stage left” for the entire time
Of course, there are many accessibility practices to keep in mind that we’ve outlined above, particularly in web accessibility, documentation, and guides.
But if you’re building any app that uses audio, try implementing spatial audio and testing it with your users for accessibility! You can create a free developer account below.