An app for everything, but can everyone use it?

Anne Spencer Ross
HCI & Design at UW
Published in
6 min readMay 26, 2020

As I turn off my phone’s alarm in the morning, I run through my list of chores: check my email, read the news, pay some bills, and get directions to the store. I get up, play some music, do a short workout, and sneak in a little scroll through social media. My day seems to revolve around my phone. Mobile apps let me do these and countless other daily tasks conveniently and on-the-go. Apps are essential in my day-to-day life.

Unfortunately, many apps fail to be fully accessible to people with disabilities or those who rely on assistive technologies. As one blind app user noted, using an inaccessible app is “a constant feeling of being devalued. It doesn’t matter about the stupid button that I can’t press in that moment. It’s that it keeps happening. … And the message that I keep receiving is that the world just doesn’t value me.”

I want apps to be usable by everyone. As a PhD Candidate in computer science and accessibility, I work on understanding and improving app accessibility. In this post, I will share the state of app accessibility and ways that you can help make apps work for everyone. More details about my work, including full publications, can be found on my website.

Although multiple federal policies mandate app accessibility, the problem persists, as reflected in lawsuits (e.g., BECU lawsuit, Greyhound lawsuit) and research surveys (e.g., Yan & Ramachandran, my large-scale analyses). App accessibility barriers affect diverse groups. For example, some people use assistive technologies to interact with their phone; people who are blind or have low vision population may use screen readers, people with motor impairments may use voice commands or external keyboards as an alternative to touching a phone screen. If apps are not built correctly, they will not work properly with assistive technologies. Other accessibility barriers include buttons that are too small to touch, low contrast colors that are difficult to read, and videos without captions.

Significant accessibility barriers have been found in essential apps including apps for banking (e.g., Wells Fargo and BECU), social media (e.g., Instagram and Facebook), and transportation (e.g., Greyhound). These industry sectors, with substantial financial resources, continue to release apps with barriers that prevent independent access to pressing needs. A National Federation of the Blind president said this about a lawsuit against Greyhound’s inaccessible website and mobile app: “Without the ability to drive, blind people need travel alternatives like Greyhound. It’s mystifying, not to mention unlawful, that Greyhound makes it impossible for us to book trips in the same ways everyone else can”. Inaccessible apps also impose a heavy social burden, as a screen reader user of a Facebook app noted, “I really feel so left out. I know that sounds silly, but everyone else is able to share their ‘friendversaries’ and all that stuff that they put there, and I never can.”

The severity and impact of these app accessibility barriers has driven public outcry and lawsuits. We have heard and read much about app inaccessibility. To extend and deepen that knowledge, I ask the following: (1) How often are accessibility barriers encountered? (2) Where do barriers tend to occur? (3) What obstacles prevent designers from creating accessible apps?

My research focuses on answering such questions. For more information on this work, see my peer-reviewed papers at ASSETS 2018, and TACCESS 2020. We tested 9,999 free Android apps for seven specific accessibility barriers. Missing labels was one of the most frequent barriers. For images and icons, app developers must add information to tell screen readers what to say; otherwise the screen reader will say “unlabeled button.”

The Freegal audiobook app has many unlabeled buttons.
A screenshot of an audiobook app playing a book. Another shot covers the unlabeled buttons with large, red question marks
In this audio book app, the back button, album covers, repeat, forward, play, backward, and shuffle buttons are all missing labels, making these functions inaccessible to app users.

Across 8,901 apps, we found that 2,008 (23%) had more than 90% of their images and icons missing labels.

% icons and images in app missing labels. 23% apps have <10% elements missing labels, 23% apps >90%, 54% apps uniform 10–90%
Missing labels on images and icons was one of the most frequent barriers in our data set of the seven barriers we tested for.

Delving into where the barriers tend to occur, we identified certain types of screen elements that were missing labels more frequently such as floating action buttons. Floating action buttons are the large, usually circular buttons that “float” on a screen and perform its most important action. For example, floating action buttons are often used to start a new email or get directions.

Three screenshots with examples of floating action buttons
Creating an alarm on a clock app, getting directions on a navigation app, and making a call on a phone and in contacts app are actions represented with floating action buttons.

Given that these buttons represent the most important action on the screen, designers should surely guarantee that app users understand what that button does. Nevertheless, of the 6,389 floating action buttons we tested (taken from 590 apps), 92% lacked labels.

Why do so many floating action buttons lack labels? Let’s look first to official Android documentation. We reviewed the documentation that helps developers learn to design and implement floating action buttons. There was accessibility-specific documentation that taught labeling. However, the general documentation for floating action buttons lacked any mention of labeling. Moreover, example code on the floating action button page was unlabeled. Any developer copying that code directly would need additional knowledge and effort to label it. In an exciting direct impact of our work, I worked with Google’s accessibility team in 2019 to update some of their documentation to follow best practices and add labels to sample code. While we do not yet know the impact of these additions for app developers or users, it is heartening to know that the information is more readily available.

A screenshot of example code for a floating action button in Google’s documentation. The code for the label is highlighted
I worked with Google accessibility teams to update their documentation to add labels to their example floating action button code.

Other accessibility barriers, not as common as missing labels, still exact a huge impact. For example, some app screens cannot be used with assistive technologies, including screen readers, Bluetooth keyboards, voice commands, and other alternative interactive devices. This experience is like opening your favorite app to a blank screen that doesn’t appear to do anything no matter how many times you tap on it.

The Sand Draw app is completely inaccessible with a screen reader and other assistive technologies.
Screenshot of an app with on-screen text and rows of buttons. Beside it, the screen is covered with a red question mark
No text or buttons on this sand drawing app can be used with assistive technologies.

We discovered that 815 apps (8% of tested apps) had screens that could not be used with assistive technologies. This problem appeared to have a larger impact on educational games than on other types of apps. Education apps made up 7% of apps overall and 19% of completely unusable apps.

How do problems as significant as this happen? We found that occasionally the tools used to build apps can greatly affect their accessibility. 100% of screen elements we identified as coming from the Unity tool and 53% of screen elements from the Cocos2dx game engines were completely unusable. We must identify ways to support the building of more robust tools or help designers and developers find existing tools that support creating accessible apps.

This study unearthed the still substantial accessibility problems that prevent people using assistive technologies from making full use of needed apps. We plan to use this data to guide our efforts to make apps more accessible. We also hope this data can make people like you more mindful of the need to design accessibility into tools and apps and more knowledgeable advocates for app designers to do better.

How Can You Help?

Knowing better is doing better, right? Well, here’s what you can now do to promote the creation of more accessible apps:

Make your social media posts accessible. Do you share pictures or videos on social media? Check out these tutorials on how to add labels to your pictures in Twitter, Facebook, Instagram. The list goes on; websites, documents, and really any electronic photo needs a label.

Caption your videos. YouTube has captioning tools, and the captions can be uploaded to social media and websites as well.

Follow accessible app design and development practices. Do you make apps? Check out these resources from Google and Apple for making accessible apps. Some steps are as easy as adding a single attribute to a label (in Android, look at the contentDescription attribute) or picking slightly different colors for higher contrast.

Test apps. Many tools can test an app’s accessibility including Google’s Accessibility Scanner, Apple’s Accessibility Inspector, and axe. Test your own apps or test popular apps and message developers if something does not work.

Spread the word! The more we, as a community, spread the word about app accessibility, the more companies will make accessibility a priority.

--

--

Anne Spencer Ross
HCI & Design at UW

PhD Candidate in computer science at the University of Washington working on accessibility. homes.cs.washington.edu/~ansross