Android: The Next Generation of Accessible Apps for the Enterprise

by
Tags: , , , ,
Category:

The Continuing Mission

In the evolving landscape of Android App development for the Enterprise, there is an aspect that often takes a back seat – accessibility. In brief, this blogpost will cover:

  • Why it is important to prioritize accessibility as a fundamental aspect of the development process, particularly for large-scale and complex organizations
  • What accessibility features and APIs are available to the modern app developer, along with a quick discussion of some common accessibility problems we often see
  • How an inclusive focus should be integrated specifically into each and every phase of App development

Let’s get started!

Why?

In companies both large and small, accessibility is frequently treated as a second- or third-tier concern. The common wisdom is make the app work, then make it work well, then make it secure, then make it accessible. However, this prioritization needs a reevaluation. As of March 2023, the World Health Organization (WHO) estimated that approximately 16% of the world’s population lives with some form of disability (approximately 1.3 billion people), and approximately 26% of the U.S. adult population identifies as having a disability (approximately 86 million people). 91% of people with disabilites use a smartphone or a tablet, according to one 2015-2016 study. This is a sizeable percentage of daily Android users.

Many of these disabled users may use their smart devices as the primary method through which they interact with the world. Screen readers like TalkBack, high-contrast mode, font size adjustments, and new AI vision tools help the blind and visually disabled. The deaf can use live transcription, real-time closed captioning and sound filtering tools to boost hearing and clarity of conversations. For those with mobility issues, facial guestures and Switch Access can make a huge difference in using a smartphone without using the touchscreen. Without comprehensive smartphone support, millions of people will be cut off from a world that is increasingly digital: finance, news, communications, social networking and more are accessed primarily online.

For startups and those entering crowded markets, particularly for governmental clients, full accessibility support can be a strategic differentiator. In the United States, the Americans with Disabilities Act and Section 508 compliance is required for all federally procured apps; the European Accessibility Act ensures much the same for EU governments. Accessibility for many clients and businesses is frequently a hard requirement.

For enterprise Android apps, the stakes are higher. The sheer scale of users and the broad diversity of their backgrounds and abilities necessitate a heightened emphasis on accessibility, as well as to a certain extent greater responsibility on the part of the enterprise. It is not merely a matter of compliance, it is a strategic decision to reach and serve a vast audience, including individuals with disabilities. Accessibility becomes paramount in ensuring that the app resonates (and is usable) with every new user.

What?

Android offers a range of accessibility features and APIs for the App developer. Covering them all is outside of the scope of this blog; however, three of the most common mistakes we see time and again are that touch targets are too small or close together, the content description of visible UI widgets are not set or set incorrectly, and that icon and color combinations don’t work for the colorblind. Examples will be given in Kotlin for Jetpack Compose.

Touch targets

One of the most common errors with accessibility is that touch targets are set to smaller than 48 dp, the recommended minimum size from Google. This can happen because UI designers are not aware or have overlooked these recommendations, or due to layout problems or bugs in development. On a related note, it is also recommended to ensure that multiple touch targets are separated by 8dp or more, to avoid mistapping errors. In Jetpack Compose with Kotlin, this can be as simple as setting the minimum width and height using Modifier.sizeIn, as shown here:

Button(
   modifier = Modifier.sizeIn(minHeight = 48.dp, minWidth = 48.dp)
)

Content description

Another common error with accessibility is failing to set the content description attributes or setting them to a value which is read incorrectly by default by the TalkBack accessibility service. This can be corrected using Modifier.semantics, as shown here:

Text("The account number is 12321", modifier = Modifier.semantics {
   this.contentDescription = "The account number is 1 2 3 2 1" }
)

This is a particularly common problem, for example, with account ids or numbers that should be read as individual characters rather than as a whole number (“Twelve thousand, three hundred and twenty one”). Though TalkBack generally does a reasonable job interpreting data values, a set of text utils are frequently used in the cases where the same set of numeric ids and data values are used throughout the app.

Icons and colors

The last common error that we often see relates to icons and colors. Frequently we see developers using only color to convey state information, for example by changing a “connected” icon from green to red to indicate “disconnected” without changing the icon shape, or changing the background color of rows in a contacts list to blue in a messaging app to indicate “away”. These state changes can be difficult to percieve for the 4.5% of the adult population with some form of color blindness. Color alone should never be used to indicate state; a corresponding change in text or icon should be used as well to make these changes as clear as possible.

Designers and developers should work together to avoid these common mistakes to create a more inclusive and versatile app.

How?

Accessibility integration should not be an isolated phase but an integral part of the entire app development process. From the design phase through development, unit testing, and integration testing, accessibility should be seamlessly integrated at the process level. Designers play a pivotal role by referencing how each new feature will operate for various subsets of the audience. Development leads and developers should keep abreast of new and updated accessibility APIS, integrating them using the semantic properties of Jetpack Compose. Quality assurance ensures that an app is not considered complete until it meets accessibility requirements comprehensively. Project leadership should act as an advocate for the users, building in this accessibility focus from the very beginning stages of the project. In addition, project management in collaboration with UX can directly solicit and integrate feedback from disabled users, either directly or through specialized external consultancies. All team members, working together on each project with accessibility in mind is the goal.

The Final Frontier

Making accessibility a primary focus in enterprise Android app development is not just a best practice but a necessity. By embedding accessibility into the core of the development process and leveraging Android’s diverse features, developers can create applications that are not only functional but truly inclusive. It is time to recognize that an app isn’t complete until it is ready to serve the needs of the entire audience.