This post originally appeared on the Connected blog.
As product builders, we all know that accessibility is important. It’s vital that our products work for everyone who uses them. But do we place the necessary emphasis on accessibility that it deserves in our product development process? Unless it is part of your earliest considerations, the answer is no.
Studies show that 15% of the world’s population suffers from some kind of disability or impairment. As products and mobile applications play an increasingly significant role in our daily lives, it’s a huge problem that over 1B people might not be able to access and use the products and tools that many of us take for granted. Too often accessibility is considered a “nice to have” but for these users and for brand perception, it is crucial in today’s world.
At Connected, accessibility has always been considered a vital part of the product development lifecycle. By making it an integral phase in our process, we are more equipped to build better products by increasing the usability of products for everyone. During a recent project, the Connected team and I were tasked with ensuring that the new smart home product we had helped build with the client met all the accessibility guidelines. As a social media giant with over 1B users, the potential impact of incorporating accessibility into the product was massive.
During the project, we identified three key areas that required additional focus to ensure we built a product that works for everyone.
No. 1: Process
Modify delivery process: We modified our feature delivery process by generating a11y tasks for every feature master task. Adding this step made sure that every feature developed moving forward is accessible and can be easily tracked by the QA teams. Also, because we were a large team with many developers, this process helped keep everyone informed about adding and handling accessibility for every new feature implementation.
Create a dedicated audit team: We learned that it’s beneficial to have a dedicated team that audit code and make sure accessibility is handled across the product. The team would be responsible for laying out accessibility guidelines that designers and developers could use as a reference.
Conduct user research: We worked closely with accessibility experts and conducted user research with people with accessibility challenges to understand what is required of our product to meet people’s unique needs.
No. 2: Consistency
Build for every sense: One of the important aspects of making a product accessible is consistency, not just across screens but also providing a consistent experience across interfaces. Whether the product is a sight, touch, or hearing experience every user should have the same UX experience.
Be aware of custom views: A common issue we noticed across the product was that many of our custom views such as spannable text, page indicators, icons without text, etc., were not accessible out of the box, unlike textviews and buttons with text. In simple terms, custom views didn’t work well with touch-specific interactions (such as text highlighting and text-to-speech). We ensured consistency in this regard by refactoring our base views in order to make our custom views accessible out of the box. A couple of ways of solving this was by using Android-provided properties such as android:contentDescription, android:importantForAccessibility, android:focusable, and android:focusableInTouchMode.
Inform the user during transitions: It is important to make sure that on the screen transition the appropriate title of the page is read out so that the user is well informed of what is on the screen. We achieved this by refactoring our code to add generalized code that automatically works with new UI/screens out of the box, in order to reduce redundant code.
No. 3: Design
Factor in font size: Accommodating various font sizes for different UI elements was difficult. We often came across screens on our product that had overlapping text or text that was cut off when larger font sizes were selected. By designing with accessibility in mind from day one, the challenge of font size can be dealt with in a way that doesn’t affect the experience.
Ask whether self-refreshing screens are necessary: A common issue we noticed with different self-refreshing screens in accessibility mode was that the accessibility focus would disappear on every refresh of the screen. For example, when users were on the wifi page, the accessibility focus would disappear when the scan result came in while you’re midway through the list of possible connections. For a user, this experience would be off-putting and frustrating. This issue only became clear later in the development process, at which point we formed a couple of potential solves: We could either increase the delay for every scan result or turn off the ongoing scanning feature when accessibility mode was on — the user would have to go back and forth to see scan results or we would add a UI element such as a button that could be used to do a manual refresh.
Make accessibility mode easy to turn on and off: For most products, turning on the accessibility feature is done through settings. But that begs the question: How do we switch on accessibility mode from a flow that doesn’t have access to settings (e.g. the on-boarding flow on a device)? A common shortcut to enable accessibility mode is by pressing both the volume keys for three seconds to start the talkback feature (on Android) and triple-click the home button (on iPhones). Initially, we opted for long-pressing the screen with two fingers but later realized that this could lead to accidental activation, and many beta users complained of ending up in the accessibility mode unintentionally.
To rectify the problem, we used a confirmation dialog, where the user could opt out of accessibility mode with just one click of a button. What we learned from beta testing was that ensuring that the feature is easily available for users that need it, but doesn’t ruin the experience for users who don’t is critical.
Use the right tools: The tools you use are also very important when building a product for accessibility. A very useful tool we used to resolve and understand many accessibility issues was Flipper. Flipper’s layout inspector includes an accessibility panel for selected views. This panel helps you investigate and debug common issues, such as unfocusable views, views that are unintentionally receiving focus, unlabelled views, and more.
Thanks to our dedication to creating product impact for every user—irrespective of the changes they face—there now lives a smart home device with universal application. For our client, they have seen first-hand how much more effective accessible development is when it is factored in from the first day of a product’s development process. Without building with accessibility as a front-of-mind consideration, the client would have missed out on an opportunity to delight scores of users and as a result, would have missed out on the ability to maximize their revenue from the product.
As a product builder, empathy is a must. The products I build at Connected aren’t designed to meet the requirements that I have or what the product team has. We believe in designing impactful experiences for everyone, stepping outside of our own desires, and ensuring that no one’s experience is inhibited. Having the license to champion accessibility in products and knowing that our client now builds for accessibility is the real-world impact I strive for every day.
Changing accessibility from a “nice to have” to a core requirement has the power to transform the product experience for over 1B people, which begs the question: Who wouldn’t want to make that kind of difference?
