November 25, 2024
Volume 22, issue 5

Download PDF version of this article PDF

Accessibility Considerations for Mobile Applications

How the Bloomberg Connects app supports accessibility in the product and process

Juanami Spencer

Mobile applications are used by many people to complete their daily digital tasks and transactions. In 2025, the number of mobile users worldwide is projected to reach 7.49 billion, according to Statista.⁴ By another estimate from the World Health Organization and World Bank, 1 billion people, or 15 percent of the world's population, experience a disability that can limit access to information or their participation in various activities.¹³ Despite the potential for digital technology, including mobile apps, to reduce barriers, accessibility is not consistently emphasized in application design and implementation. When accessibility is not considered, it can be difficult or impossible for users with disabilities to complete tasks. A mobile user experience innately includes challenges such as reduced screen real estate, changing environments, and intermittent focus. These challenges can become more pronounced for those with disabilities.

No matter what a mobile application's purpose is, considering accessibility ensures that the product can be used by as wide an audience as possible. Bloomberg Connects is a free mobile app featuring digital guides to more than 600 museums, galleries, sculpture parks, gardens, and cultural spaces, available on both iOS and Android platforms.¹ The app has more than 4 million lifetime users to date. By prioritizing accessibility, Bloomberg Connects supports cultural organizations in providing inclusive, informative, and enjoyable digital experiences for users around the world.

When it comes to accessibility for digital experiences, the Web Content Accessibility Guidelines (WCAG) govern the design and implementation process.⁵ The guidelines define three levels of conformance: A, AA, and AAA. While A is the minimum level, AA includes all level A and AA requirements and is the level that most organizations target. This is what the project team for the Bloomberg Connects app targeted. Though defined for web content, these guidelines extend to all digital experiences, including native mobile applications. When the guidelines are applied in building an accessible application, some aspects of the mobile experience may benefit from unique consideration.

This article explores some of the key accessibility considerations for a mobile application and highlights a few ways the Bloomberg Connects app supports accessibility in both the product and process. Figure 1 shows the design and implementation considerations of the Bloomberg Connects app's "Explore" screen.

The Bloomberg Connects app's 'Explore' screen. Side-by-side smartphone screens show a group of museums displayed as a list and also as a map with red pins

A Mobile Application is Subject to the Constraints of its Framework

When creating a mobile product for both iOS and Android, the use of cross-platform application frameworks such as React Native or Flutter can speed development time and efficiency, but may present additional challenges related to how the framework interacts with the native OS layer or the lack of comprehensive accessibility support in an open source environment.

The Bloomberg Connects app is built using the React Native framework. The developers encountered a problem when attempting to implement focus using a screen reader or keyboard on nested text elements. In the app, certain text blocks within a scroll view contain hyperlinks that need to be focused on and interacted with separately. The default behavior in React Native was to ignore the nested text. To bypass this issue, one viable workaround would have been to use a WebView. This is problematic because it affects performance and makes it harder to control UI rendering in relation to the screen. An alternative would be to separate the nested text and have individual links in "Views," but that would compromise the text UI. The solution was to temporarily use a full-screen WebView. While this does address the users' need to concentrate and act on text, the team plans to find a more seamless resolution when they have access to future enhancements in React Native.³

Orientation considerations

Orientation support is a level AA accessibility criterion.¹¹ Unfortunately, many apps in the marketplace today restrict usage to a single display. While the primary functionality and design of an application may suggest it is best viewed in a particular display orientation, restricting application orientation is problematic. Some users may have their device mounted onto a wheelchair in a fixed orientation, while others may find it easier to navigate using a specific orientation because of limited dexterity. Therefore, it is essential to design mobile applications that support both portrait and landscape orientations for every screen. In some cases, this may require a responsive design to avoid pushing key content "below the fold" where it may not be easily discovered and accessed.

The "Lookup number" input screen in the Bloomberg Connects app has been redesigned to provide users with access to the keypad in landscape orientation. Although this feature is not commonly available for keypads on mobile devices, it was considered an essential accessibility feature and a valuable enhancement. Figure 2 shows the Bloomberg Connects app's number input screen in both portrait and landscape orientations.

The Bloomberg Connects app's number input screen in both portrait and landscape orientations. Side-by-side screens of a number keypad in portrait orientation and in landscape orientation.

Touch interactions and navigation

Touch gestures are the primary mode of interaction for mobile applications. Advanced, hidden, and inconsistent use of gestures, however, can present challenges for all users, especially those with disabilities that affect their dexterity or cognition. Likewise, multi-action gestures, such as press and hold, can present even greater barriers to users with some disabilities and should be avoided for primary functionality. Gestures should be simple and consistent to ensure ease of navigation⁸ and maximum operability.⁹

Some gestural interactions may interfere with key accessibility features. For example, if using a horizontal swipe to expose or perform actions on a list item, remember that users of screen readers depend on those gestures to navigate the screen vertically. Consider a modal interaction or, if possible, making those actions accessible when drilling down to the detail view.

The built-in screen reader functionality in both iOS and Android includes gestural shortcuts used to accelerate common functions and settings. Many people who rely on screen readers are advanced users of these shortcuts. For example, in iOS VoiceOver, a four-finger tap jumps the user's focus to the first item on the page. Repurposing this gesture in an app could result in friction, confusion, or task abandonment. Platform differences may also come into play here: the same four-finger tap on an Android device invokes a tutorial menu. If physical movements (like tilting or shaking) are part of the interaction with your app, offer alternatives so users can simulate this using an on-screen menu or keyboard control.

Finally, keep in mind that gestures are not feasible for or preferred by some users. Other means of navigation include a Bluetooth keyboard or a switch device, which allows users to navigate via an alternative control such as a joystick. Testing your app's navigation with a Bluetooth keyboard attached will help catch common accessibility problems such as unfocusable elements or keyboard traps. Testing with a keyboard can also serve as a general proxy for navigation using a switch device if one is not available.

Focus order considerations

Though navigation inputs may differ between a mobile and desktop application, the WCAG guidance on focus order still applies. It is critical not only to provide a logical and consistent focus order, but also to ensure that the focus indicator is visible at all times.⁶ On mobile devices this deserves particular attention, given the constantly shifting environments and ever-changing lighting conditions for on-the-go users.

The general recommendation is to avoid modifying the default appearance of the visual focus indicator. Instead, it is best to ensure that all screens and screen states have proper contrast and that the focus indicator is clearly visible within them. In some cases, changing on-screen colors can improve perception, especially in bright environments that may cause screen glare.

Reduced screen real estate

Mobile design often leverages practices and patterns that aim to optimize the display of content and functionality in a limited space. Some of them, however, can pose problems for users of assistive technologies.

The carousel, or "horizontal list," is a common pattern in mobile interfaces. (Note, in this article carousel refers to content that can be manually paginated as opposed to auto-advancing, which is generally considered a poor user experience.²) A visually impaired or blind person who uses a screen reader experiences content linearly and relies on clear communication of the content's structure through semantics. For this reason, it is helpful to inform users that they are viewing a group of items rather than an indeterminate, potentially unrelated list of objects. Where possible, the identifying label should be a visual heading immediately above the carousel, describing what it contains. This would also provide a means for those who use a screen reader to skip over the carousel contents by navigating to the next heading on the screen. This is especially useful when carousels contain many items. Where a visual heading is not possible or desirable, consider labeling the carousel using a nonvisible "accessible name" field in the back end, which can be focused on before the first item in the carousel.

It is equally important that users realize the carousel has more than one content item. Common affordances such as a "peek-ahead" of the next item or pagination dots below the carousel group, while a familiar signal to sighted users, may not be easily perceivable by a visually impaired or blind user of a screen reader.¹⁰ To make it easier for someone who uses a screen reader to get a sense of the number of items in a carousel and which item they are currently on, append the item's index number and the total number of items to the accessible name of each focusable object.

Another familiar mobile pattern is the so-called "floating" UI element. One example of this is a primary action button that is positioned forward on the z-axis to allow the bottom layer of content to scroll beneath it. This approach allows important actions to be easily discoverable without using menus or additional chrome to house them. Designers and developers, however, should be aware of what the experience will be for a user of a screen reader. While a sighted user may easily notice an action button layered on top of the current content view, a blind or low vision user must consume screen content one layer at a time. This means that the screen reader would first need to navigate through the entirety of the main layer of content before jumping "forward" to focus on the floating action button. This makes for an extremely taxing interaction.

Although accelerators, like the rotor settings on iOS, can reduce the effort required (by allowing users to selectively focus on one kind of UI element such as controls), they should not be relied upon to efficiently discover primary functionality. Overlays and transparent layers have a tendency to "confuse" screen readers; it can be technically challenging to force a logical focus order around them. Before choosing this pattern, designers and developers should consider the resulting screen-reader experience and whether another, friendlier design for screen readers can achieve the same goal.

Minimal UI

Some readers of this article might remember the early versions of mobile user interfaces that relied heavily on chunky, "skeuomorphic" visual metaphors and contained comparatively less visual information hierarchy. In those interfaces, on-screen elements seemed to compete with each other for users' attention. Since then, the visual language of mobile interfaces has gradually shifted toward a flatter, more nuanced approach that aims to give priority to key information, reduce on-screen clutter, and improve the so-called signal-to-noise ratio of elements on the screen at one time.

While a clean and simple interface is essential to good design, it should not be applied at the cost of clarity and ease of use. A user interface that lacks enough explicit affordances and labels to be distinguishable can present challenges for all users, but it can be especially difficult for users with one or more disabilities.⁷ For example, people with certain disabilities may find it particularly hard to discover and interact with controls that are too small, lack sufficient contrast, or are placed too close to other interactive elements. Therefore, it is crucial to use labels that are easy to understand, ensure that interactive elements are explicitly afforded, and use headings and proper scaling of content to impart a clear information hierarchy and promote understandability. The UI design of the Bloomberg Connects app uses a consistent layout, explicit labeling and controls, and appropriate color contrast to ensure a user-friendly and accessible experience.

Intermittent connectivity and feedback

Providing system feedback is crucial to help users understand the status of their processes and actions, and whether or not they have been successful.¹² Because mobile users are more likely to encounter slow or intermittent connectivity, or even a complete lack of it, it's important to consider feedback mechanisms with accessibility in mind.

Progress indicators, whether determinate or indeterminate, are visual cues. This means low-vision or blind users may miss some of the details that sighted users receive at a glance. To address this, it's essential to assign the correct accessibility roles and labels to indicators and to provide periodic updates to keep users informed of the status of the process. It's also important to indicate when the process has been completed. Whenever possible, progress information should be provided to users without their needing to move the screen reader's focus to the indicator, so that they can continue using the app, if applicable. Consider using additional sensory cues such as sound or haptic vibrations to help communicate status.

If you select a digital guide when using the Bloomberg Connects app, the content of the guide is downloaded in the background in case the connection is lost. On the guide's home screen, the status of the download is visually indicated with a progress bar. To ensure that users of screen readers have access to the same information, the app periodically announces the progress of the download and provides an announcement when the download is complete, without having the progress module in focus. Figure 3 shows the download module of a digital guide's home screen, providing status announcements about its progress.

The download module of a digital guide's Home screen provides status announcements about its progress. A screen reader focused on text at the top of the screen: 'You can start using the guide now. It will continue downloading in case you go offline.'

Process considerations

Accessibility is not a one-time task that has a definite beginning and end. Rather, it is a continuous process that should be integrated into every aspect of a platform, application, or feature's lifecycle. This approach ensures that accessibility remains a top priority and that responsibility for it is not limited to a single part or member of the team.

Design specs

Whether design specifications are discussed in realtime or documented in separate deliverables, specifying the accessibility details of a feature will help drive a shared understanding and support engineering. The design team for Bloomberg Connects delivers design specs in Figma that incorporate accessibility details for screen reader/keyboard behavior, text scaling, orientation, and contrast. For example, when designing a screen reader experience, the design spec includes the following behaviors:

Default focus placement when a view is instantiated
The screen reader's order of progression through focusable elements and screens in a flow
The exact announcement of elements when in focus, including roles, labels, state (where applicable), and any "accessible hints" used to provide additional information and context.

Once an accessible component is built, its accessible attributes can be applied everywhere that it is used, but detailed specifications support the accessible implementation of new features as the app continues to grow. Figure 4 shows a design spec for articulating screen-reader behavior, and figure 5 shows a design spec for scalability.

A design spec articulating screen reader behavior. A screen with numbered sections for headings, buttons and labels

A design spec for scalability. A screen with labeled sections for text size and spacing.

Accessibility in user research

Testing with users is an essential part of creating a successful product. This is particularly true when it comes to ensuring accessibility. At present, several automated tools can inspect code to ensure that elements are correctly labeled, have suitable contrast, and include media alternatives such as alt text for images, transcripts, and captions. It is important to emphasize, however, that the only way to verify a product's accessibility is by actually testing its features with users who have a range of disabilities and use accessible technologies. "Compliance" with accessibility guidelines doesn't necessarily guarantee a good user experience. Conducting research with users who have disabilities can reveal gaps in a product's accessibility that may have been otherwise overlooked.

The Bloomberg Connects team conducted usability testing with 15 users with a range of disabilities and assistive technology needs. Although the findings were generally positive, the testing revealed several places where flows that were compliant technically still presented usability issues for disabled participants.

One such example was within the audio player component of the app. This component appears in-line on content views and allows a user of the app to play or pause an audio track embedded in the screen. When the audio module was placed in focus, those who used a screen reader first heard the title and duration of the audio, followed by the role and label announced as "Play audio. Button." As implemented, all controls had the proper roles and labels, the actionable elements were individually focusable, and the status of the button ("Play" or "Pause") was announced. However, several screen reader users who tested the app noted that front loading information about the content of the audio clip ahead of its role obscured its purpose, making it easy to miss that it was a button. The issue was addressed simply by announcing the role ahead of the accessible name. This resulted in a better experience for those who use screen readers. Figure 6 shows the audio button with an updated screen-reader announcement: "Play audio. Curator Jessica Barrie talks about this painting by Sir James Guthrie in Gallery 1."

The audio button with an updated screen reader announcement: 'Play audio. Curator Jessica Barrie talks about this painting by Sir James Guthrie in Gallery 1.' A screen reader focused on the audio section of a screen which explains a painting.

Conclusion

Considering accessibility is essential when creating mobile applications to ensure they are usable and enjoyable for as broad an audience as possible. Mobile accessibility has unique considerations compared with desktop experiences, but it provides immense value to those users who rely on mobile devices in their day-to-day activities. By keeping these considerations in mind, mobile product development teams can better support and enhance the lives of all users.

References

1. Bloomberg Connects; https://www.bloombergconnects.org.

2. Nielsen, J. 2013. Auto-forwarding carousels and accordions annoy users and reduce visibility. Nielsen Norman Group; https://www.nngroup.com/articles/auto-forwarding/.

3. React Native. GitHub: [a11y] Accessibility for nested text components; https://github.com/facebook/react-native/issues/32004.

4. Statista. 2024. Forecast number of mobile users worldwide from 2020 to 2025; https://www.statista.com/statistics/218984/number-of-global-mobile-users-since-2010/.

5. WCAG (Web Content Accessibility Guidelines) 2.2. 2023. W3C Recommendation; https://www.w3.org/TR/WCAG22/#abstract.

6. WCAG (Web Content Accessibility Guidelines) 2.2. 2023. W3C Recommendation. Focus order (Level A); https://www.w3.org/WAI/WCAG22/Understanding/focus-order.html.

7. WCAG (Web Content Accessibility Guidelines) 2.2. 2023. W3C Recommendation. Guideline 1.4 Distinguishable; https://www.w3.org/TR/WCAG22/#distinguishable.

8. WCAG (Web Content Accessibility Guidelines) 2.2. 2023. W3C Recommendation. Guideline 2.4 Navigable; https://www.w3.org/TR/WCAG22/#navigable.

9. WCAG (Web Content Accessibility Guidelines) 2.2. 2023. W3C Recommendation. 2. Operable; https://www.w3.org/TR/WCAG22/#operable.

10. WCAG (Web Content Accessibility Guidelines) 2.2. 2023. W3C Recommendation. 1. Perceivable; https://www.w3.org/TR/WCAG22/#perceivable.

11. WCAG (Web Content Accessibility Guidelines) 2.2. 2023. W3C Recommendation. Success criterion 1.3.4 Orientation; https://www.w3.org/TR/WCAG22/#orientation.

12. WCAG (Web Content Accessibility Guidelines) 2.2. 2023. W3C Recommendation. Success criterion 4.1.3 Status Messages; https://www.w3.org/TR/WCAG22/#status-messages.

13. World Health Organization and World Bank. 2011. World report on disability 2011; https://iris.who.int/handle/10665/44575.

Juanami Spencer (she/her) is a UX designer with more than 15 years of experience in the field. At Bloomberg, she specializes in Mobile Design and Accessibility, and is passionate about working with arts and culture organizations. She lives in Queens, New York, with her family and their two cats.

Originally published in Queue vol. 22, no. 5—
Comment on this article in the ACM Digital Library