Creating Accessible Android Products at LinkedIn

April 11, 2017

This post provides an overview of how I began the journey to improve accessibility in LinkedIn’s Android apps. I spent the last year leading this effort as a member of our Accessibility Team. Hopefully, this post will inspire others with ideas for how to help make your own Android applications accessible and inclusive.

LinkedIn’s core vision is to create economic opportunity for every member of the global workforce. It is our shared sense of purpose, and it inspires the things we create.

When we talk about every member of the global workforce, we are also talking about the more than one billion people in the world who have some sort of disability. This includes people who may lack fine motor control or have some sort of mobility impairment, are deaf or hard of hearing, are colorblind, have a learning disability such as dyslexia or ADHD, have seizure disorders, have low vision or are visually impaired, or are totally blind.

The reality is that people with disabilities are often unemployed or underemployed. Given our core vision and the challenges people with disabilities face when it comes to unemployment, it is clear that it’s very important to make our products digitally inclusive and accessible to people with disabilities. If we can help people with disabilities find jobs, grow their professional network, stay on top of their industry with our flagship app, or even learn new skills with LinkedIn Learning, then we will be closer to our guiding principle by moving the needle on creating economic opportunity for everyone.

The principle behind digital accessibility is the design and development of user experiences that everyone, including people with disabilities, can independently consume and interact with. If someone with any type of disability needs to rely on someone else to consume the experience, then we consider the experience to be not accessible.

How many times have you had problems activating a very small button on your smartphone, or trying to read through texts with either very small font size or with color contrast that is barely visible to you? These are common examples of problems we can find in many mobile applications that could have been avoided if these apps were made accessible from the start. This blog post provides an overview of basic steps you can take to begin improving accessibility in your own Android applications.

Why is the Android platform so important?

One of the biggest benefits of the Android platform is that it is an affordable option in many different countries. This is one of the reasons why Android is currently the most popular platform on mobile devices in the world. As a result, with our focus on Android accessibility, we can help create new opportunities for people with disabilities globally.

In order to make our Android apps at LinkedIn more accessible, I first met with different engineering teams to raise general awareness about the full range of accessibility features available on the Android platform, as well as how they could build their experiences for better accessibility. The interesting part of this process is that you often discover accessibility champions along the way. These are people who will advocate for accessibility directly with their colleagues. For example, Chao Zhang and Nathan Hibner went above and beyond to make the LinkedIn news feed friendlier for screen-reader users. They’ve refactored the card widget to require the implementation of accessibility actions specifically for TalkBack users, and this work allowed for not only the creation of new features to become more screen-reader usable by default, but also could be leveraged in other parts of the app.

Screenshot of accessibility actions in LinkedIn news feed on Android

I also had to create technical documentation and other support, because the level of detail required by our engineers was not available elsewhere. This included an accessibility reference app with examples of common UI controls and interactions, so developers and designers have a place to go whenever an issue is raised either via tools or an accessibility review. The app lets our developers glance through the code and understand how to implement various features in an accessible way, from simple examples like buttons or images to complex components and interactions like charts, view pagers, and focus navigation.

Image of accessibility reference app showing a list of examples and a chart example

One of the biggest challenges I faced when dealing with an existing product was performing an initial accessibility assessment. An assessment is not only meant to point out accessibility problems (based on international and Google accessibility guidelines and standards), but also to recommend solutions. It becomes even more challenging when you have to do the assessment while the product could still be changing or evolving, which was the case for me.

As much as an assessment may prove time-consuming, it is nevertheless very important to give you a complete overview of the accessibility state of your existing application. Assessments also enable you to familiarize yourself with many aspects of digital accessibility and its pragmatic application, as well as the platform capabilities.

Time is a matter of priorities

Even after raising awareness, providing training, and offering plenty of documentation about accessibility, it may still feel like an uphill battle sometimes to make improvements. A product might already be in production, for example, with new features coming in all the time, making accessibility updates difficult to keep track of. There’s an analogy that some people like to use that talks about changing the wheels of a train while it is still running.

While in an ideal world I would love to see all accessibility problems being addressed all at once, it’s also important to understand the resources and constraints of each team. In a more pragmatic approach, it’s important that teams reserve time to work on a prioritized list of accessibility tickets every sprint. Steady progress is more important than having no progress at all.

Tools of the trade

If we had to make all developers memorize every accessibility guideline, we wouldn’t be able to achieve much progress. Luckily, Google has built an Accessibility Testing Framework just for the purpose of catching issues that can only be caught during runtime, such as:

Calculating the bounding box of each clickable view and checking if they meet the minimum touch size area of 48dp (density-independent pixels) or if they overlap other views.

Calculating the color contrast between foreground and background colors.

Checking if a non-textual view is missing speakable text (similar to alternative texts for images) or if the screen has multiple views with the same content description.

These checks present a very low risk of being false positives and can safely fail your instrumented tests.

If you find it challenging to have the accessibility checks enabled in your product because it will fail a lot of tests, consider adding failure suppressions for the existing failures and then addressing the issues one by one. This will prevent new features from being shipped with accessibility issues while allowing you to work on existing failures one at a time.

In addition to this, Google also includes some accessibility rules in Android Lint, which is shipped by default in Android Studio. These linting rules shouldn’t fail tests, since things can be set dynamically during runtime somewhere else and there’s only so much a static analysis can do. They are, however, extremely fast and helpful to catch potential issues very early in development.

We use these tools as part of our continuous integration build pipeline, allowing us to automate a lot of checks that would otherwise require many manual tests. Google also provides an Android app called Accessibility Scanner, which you can use to scan for issues on every screen of your app.

Despite the tools, it’s important to note that not all accessibility issues can be detected automatically. This is true for issues that require some level of cognitive reasoning, such as providing unique and meaningful content descriptions for non-textual content or even making sense of an experience as a whole. Although advancements in machine learning may one day help with automating some of these steps, we’re still far from achieving good results in this area. Manual testing is still always necessary to validate the experience.

The path forward

Since I began this journey, Google and the tech industry have been increasingly creating more materials about Android accessibility. I’m very glad that there’s been a growing interest in the area. If you are interested in learning more, you can find plenty of materials on Android’s accessibility website. Additionally, you can check out my previous article on this topic if you are interested in quick tips to make your apps more accessible.

At LinkedIn, Android accessibility is an important ongoing effort, and there is still a lot more to be done. By combining awareness talks, technical trainings, development support, and tools for efficient development and testing, we can make our Android apps more accessible and provide new economic opportunities for people with disabilities around the world.