How Time-Consuming Is It to Build an Accessible Mobile App?

Rate this content
Bookmark

The most common misconceptions about accessibility are that it is time-consuming or can be easily left as the last thing to be added. But, of course, this is not the case. We’ll look at how easy and quick adopting accessibility as a First-Class Citizen and, on the contrary, how difficult and time-consuming it is to add accessibility to an existing project.

This talk has been presented at React Advanced Conference 2022, check out the latest edition of this React Conference.

FAQ

Starting with accessibility from the beginning reduces the time and effort needed to fix issues later, minimizes the risk of introducing bugs, and ensures a consistent and predictable user experience.

Building an accessible app is only expensive and time-consuming if accessibility is delayed until later in the development process. Starting with accessibility from the beginning can save time and effort.

Alessandro Lemsenese is a software engineer at Formidable with over four years of experience in accessibility, particularly in creating accessible apps using React and React Native.

Accessibility is the practice of making mobile apps usable by as many people as possible, including those with disabilities.

React Native Armour is a library created by Alessandro Lemsenese that includes components and hooks designed to enforce minimum accessibility requirements in React Native applications.

React Native Armour provides runtime checks for common accessibility issues, displays banners for failed accessibility tests, and prints details in the console. It helps developers fix issues like missing rules, labels, and focus management.

Common issues include unclear accessibility labels, improper focus management, forms that don't announce errors or required fields, and elements that are not accessible to screen readers.

You can ensure accessibility from day one by building shared components that are accessible by default and performing manual tests to ensure screen reader compatibility and proper focus management.

Grouping related content ensures that screen readers read related information together, providing a coherent and understandable experience for users with disabilities.

Manual tests should ensure screen reader compatibility, proper focus order, and that UI changes are announced to screen reader users. It's also important to verify that the behavior and appearance are consistent across the app.

Alessandro Senese
Alessandro Senese
21 min
24 Oct, 2022

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Building an accessible app can be time-consuming but can be divided into two parts: making an existing app accessible and starting an accessible app from scratch. React Native Armour can help with accessibility fixes, but manual checks are still necessary. Accessibility best practices include focusing elements in the correct order, announcing UI changes to screen reader users, and ensuring consistency in behavior and appearance. Building accessible components can streamline the process of making an app accessible.

1. Introduction to Accessibility and Fixing Issues

Short description:

Is it really true that building an accessible app is time consuming and expensive? We are going to divide the agenda in two parts: making an existing app accessible and starting an accessible app from scratch. Accessibility is the practice of making your mobile app usable by as many people as possible. The accessibility issue to fix is an actual report we received, highlighting a serious issue. I used React Native Armour to help with the fixes, which includes components and hooks to enforce accessibility requirements. I replaced imports of pressable from react-native to react-native-ama, resulting in about 200 typescript errors. I had to navigate through the screens to fix problems and ensure clear accessibility labels. Headers were marked as headers for the screen reader. The form presented another problem.

Hi, is it really true that building an accessible app is time consuming and expensive? In order to answer that question we are going to divide the agenda in two parts. The first part we take an existing app and we try to make it accessible. The second part we start an accessible app from scratch.

Before starting, my name is Alessandro Lemsenese and I am a software engineer in Formidable. I started work with accessibility about four years ago. My first work with React on a TV involved creating an accessible app for a bank. I started learning more and more about accessibility and never stopped since then.

Before we carry on, let's remember what we are trying to do. Accessibility is the practice of making your mobile app usable by as many people as possible. So that's our target. We want to make sure that as many people as possible can use our app. So let's start.

Now, the accessibility issue to fix is actually an actual report we got from an excellent company, where they highlighted a serious and critical issue that we had to fix in our app. In my case, I did use React Native Armour to help me with these fixes. And the library is a React Native library I built after I joined Formidable. It does contain a set of components, hooks that are designed to enforce minimum accessibility requirements. So the first thing I did, I did install the library with Yard, I did import the provider provided by the library and wrapped around my application. So to fix rules, labels, states and hints I did replace all the imports of the pressable from react-native to react-native-ama. And once I've done that I got around 200 typescript errors or missing rules and labels. And in this screenshot you can see how Ama works. Basically Ama does some runtime check, but apart from the typescript typing does a runtime check of the common accessibility issue and if it does, it does highlight the component inside the UI and shows a banner and also prints in the console which of the accessibility tests has failed.

Now in my case I had about 200 errors and the big problem I had I could not assume that everything was a button. And in fear from the code which I wrote to use was not always straightforward so the option I had was to actually navigate through the screen to fix the problem. The same was with accessibility label. I had to make sure that the accessibility label was clear for the screen reader user and also I had to check if it was enough because we had some cases like the one in the screenshot where the button did contain x information, in this case 5 messages, unread messages. So I had to communicate this information to the screen reader user using accessible hint. Also because I haven't worked on all the parts of the app I wasn't sure how many screens we actually had so the only option I had was to actually go through the entire app by myself and figure it out, all the information that was missing. For headers, it was easier. Just make sure that each screen had a header and everything that looked like a header was actually read, marked as a header for the screen reader. The form, there was another problem we had.

2. Fixing Form and Bottom Sheet Accessibility Issues

Short description:

The user couldn't focus the form label and input as separate fields. The return key on the keyboard didn't function correctly. The form submission didn't focus on the first field with an error. We used React Native ARMA to fix these issues. We also addressed the accessibility problem with the bottom sheet by using a built-in component from ARMA. The entire process, including bug fixes, took over 5 weeks. To build an accessible app, we can create shared components that handle accessibility properties. However, manual checks are still necessary to ensure compatibility with screen readers.

The bigger problem was the user wasn't able to focus the form label and the form input as two different fields. The required option was not read and the message was not read as part of the field. Another problem was that by default React Native does show a keyboard with the return key, but that return key doesn't do anything. The right behavior was to allow the user to navigate through the fields using the next button if needed and allow to submit the form with return 1.

The last problem was that if the form gets submitted and there is an error, the first field that does contain an error should gain the focus, this was not happening for us. So to fix this I did use React native ammo, especially the form field is a wrapper that handles the form submit. So if the in this case handle submit fails, the form that contains a reference to all the inner field will try to focus the first field that we marked as that contains an error. And also yeah the form itself is used internally by the text field and the use text field hook to figure out which keyboard button to show.

For the text field we had to share the components so what I had to do was wrap. We had to use the text input use text input hook where the ref is used to allow focusing the field internally and let's see if the field had no validation if had no errors or the various attributes and pass that properties back to the text input. Also we have a form field like check box or combo in this case I had to wrap in the generic form that field provided by Ama and this field is able to actually get receive a screen focus from the screen reader. For the bottom sheet this show we had the one we were using, did not get any focus the user was still able to select anything underneath the overlay the bottom sheet itself. So we had to replace that and in this case I used one built in Ama that did address the accessibility issue. Also, this one has the benefit of disabling the animation, the sliding and slide-out animation if the user sets the disabled animation in the device. The time of the action, in this case if you add an attempt to the card, we show a message that for a few seconds and the report that it was supposed to behave more or less like a bottom sheet, it was supposed to gain the focus, allow the user enough time to actually interact with it and the user was not supposed to select anything, be able to focus anything underneath. In this case we did use the bottom sheet provided by React Native ARMA, so we add all the focus feature and the focus feature, and we used in conjunction with the useTimeout action. This hook basically allows trigger the function we give according to the status of the screen reader and the device, for example in iOS if the screen reader is on the timeout is never triggered, while on Android we use the time to take action settings from the device.

So that was the critical and the serious issue we fixed, so how long did it take? To this I did also add bug fixes, because during the process we had to replace some libraries with others that were accessible. So we introduced some bugs, some of them we were not aware, because for example the bottom sheet does use model, but React Native at the moment does not support opening multiple models unless they are nested and so we had to change also a bit of logic around that to make it work in the app. And the whole process took more than 5 weeks to fix. So let's build an accessible app as first class citizen. How do we do that? How can we make sure our app is accessible by day 0? The solution is easy, we can build shared components that are accessible by default. So wherever you have buttons with different states, with different hints, we just create one or multiple shared components that handle all the required properties we need. The same we can do for a header, the same we can do for forms, we just make sure the fields are accessible already. Bottom sheet, overlay if needed, and carousel, in our case we added carousel, we had to make it accessible. So whatever component we actually need in our app we can create once and make it accessible. So what we're going to use is already accessible by default. We need a bit, just a bit extra time to make sure that everything works. Because accessible out-of-box doesn't mean that your app is going to be fully accessible, there are some checks that are needed to be done manually that we cannot automate. For example, we still need to make sure that whatever feature we build can be done with the screen reader.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Accessibility at Discord
React Advanced Conference 2021React Advanced Conference 2021
22 min
Accessibility at Discord
This Talk discusses the accessibility efforts at Discord, focusing on keyboard navigation and the challenges faced with implementing focus rings and outlines. The speaker showcases a unified focus ring system and a saturation slider to address accessibility concerns. They also highlight the implementation of role colors and the use of CSS filters for accessibility improvements. The Talk concludes with insights on runtime accessibility checking and the development of a performant core runtime system for checking accessibility issues.
Configuring Axe Accessibility Tests
TestJS Summit 2021TestJS Summit 2021
30 min
Configuring Axe Accessibility Tests
Top Content
AXe is an accessibility engine for automated web UI testing that runs a set of rules to test for accessibility problems. It can be configured to disable or enable specific rules and run based on tags. Axe provides various options, but axe linter does not support all options. The importance of investing time and resources in accessibility is emphasized, as it benefits not only those with disabilities but improves the web for everyone. Manual testing is also highlighted as a necessary complement to automated tests for addressing accessibility issues.
Limitless App Development with Expo and React Native
React Advanced Conference 2021React Advanced Conference 2021
27 min
Limitless App Development with Expo and React Native
Today's Talk discussed building cross-platform apps with React Native and Expo, addressing challenges such as setting up the native runtime and managing dependencies. Expo provides a pre-built runtime, native APIs, fast iteration speed, and integrated cloud services. EAS build simplifies app deployment by handling native code signing and validation. Over-the-air updates allow instant updates to JS and assets. Custom native code can be added using auto-linking and config plugins, and Expo supports both Managed and Bare workflows.
Nested Interactive Elements: An Nightmare in Accessibility
React Advanced Conference 2023React Advanced Conference 2023
23 min
Nested Interactive Elements: An Nightmare in Accessibility
Watch video: Nested Interactive Elements: An Nightmare in Accessibility
Nested interactive elements can cause accessibility issues on websites, and the speaker shares a personal experience with an accessibility bug involving a list component. Mitigating nested interactive structures involves limiting these patterns during development and restructuring existing elements. The speaker provides recommendations for improving accessibility, such as adjusting role properties and gathering user feedback. The conclusion emphasizes the importance of accessible solutions and encourages sharing resources to build more inclusive experiences.
Dialog Dilemmas and Modal Mischief: A Deep Dive Into Pop-Ups
JSNation 2023JSNation 2023
10 min
Dialog Dilemmas and Modal Mischief: A Deep Dive Into Pop-Ups
The Talk discusses the use of dialogues and popovers in web development. Dialogues can be modal or non-modal and are now accessibility-supported. Popovers are versatile and can be added to any element without JavaScript. They provide suggestions, pickers, teaching UI, list boxes, and action menus. Modal and non-modal dialogues and popovers have different behaviors and dismissal methods. Browser support for these features is expanding, but there are still open questions about positioning, semantics, and other use cases.
How to Share Code between React Web App and React Native Mobile App in Monorepo
React Summit 2022React Summit 2022
7 min
How to Share Code between React Web App and React Native Mobile App in Monorepo
This presentation focuses on sharing code between React web and React native mobile apps. The speaker demonstrates how to achieve feature parity using a Monorepo with NX. They highlight the importance of sharing non-UI code, such as business logic and state management, through shared libraries. This approach allows the apps to focus on UI code while keeping non-UI code separate. For more details, refer to the speaker's blog post.

Workshops on related topic

Web Accessibility for Ninjas: A Practical Approach for Creating Accessible Web Applications
React Summit 2023React Summit 2023
109 min
Web Accessibility for Ninjas: A Practical Approach for Creating Accessible Web Applications
Workshop
Asaf Shochet Avida
Eitan Noy
2 authors
In this hands-on workshop, we’ll equip you with the tools and techniques you need to create accessible web applications. We’ll explore the principles of inclusive design and learn how to test our websites using assistive technology to ensure that they work for everyone.
We’ll cover topics such as semantic markup, ARIA roles, accessible forms, and navigation, and then dive into coding exercises where you’ll get to apply what you’ve learned. We’ll use automated testing tools to validate our work and ensure that we meet accessibility standards.
By the end of this workshop, you’ll be equipped with the knowledge and skills to create accessible websites that work for everyone, and you’ll have hands-on experience using the latest techniques and tools for inclusive design and testing. Join us for this awesome coding workshop and become a ninja in web accessibility and inclusive design!
Bringing Your Web App to Native With Capacitor
JSNation 2023JSNation 2023
111 min
Bringing Your Web App to Native With Capacitor
WorkshopFree
Mike Hartington
Mike Hartington
So, you have a killer web app you've built and want to take it from your web browser to the App Store. Sure, there are a lot of options here, but most will require you to maintain separate apps for each platform. You want your codebase to be as close as possible across Web, Android, and iOS. Thankfully, with Capacitor, you can take your existing web app and quickly create native iOS and Android apps for distribution on your favorite App Store!
Contents: This workshop is aimed at beginner developers that have an existing web application, or are interested in mobile development. We will go over:- What is Capacitor- How does it compare to other cross-platform solutions- Using Capacitor to build a native application using your existing web code- Tidying up our application for distribution on mobile app stores with naming conventions, icons, splash screens and more
Hands-On With SwiftUI, GraphQL, & Neo4j AuraDB
GraphQL Galaxy 2022GraphQL Galaxy 2022
156 min
Hands-On With SwiftUI, GraphQL, & Neo4j AuraDB
WorkshopFree
William Lyon
William Lyon
Bring the power of graphs to iOS mobile app development in this hands-on workshop. We will explore how to use the Neo4j GraphQL Library to build GraphQL APIs backed by Neo4j AuraDB and how to integrate GraphQL into an iOS app using SwiftUI and the Apollo iOS GraphQL library as we build a news reader mobile app.
Table of contents:- Intro to Neo4j AuraDB- Building GraphQL APIs with the Neo4j GraphQL Library- Intro to SwiftUI- SwiftUI + GraphQL
PrerequisitesTo follow along during the workshop attendees will need a Mac laptop with a recent version of Xcode installed. Some familiarity with Swift and iOS app development will be helpful, although not required.
Automated accessibility testing with jest-axe and Lighthouse CI
TestJS Summit 2021TestJS Summit 2021
85 min
Automated accessibility testing with jest-axe and Lighthouse CI
Workshop
Bonnie Schulkin
Bonnie Schulkin
Do your automated tests include a11y checks? This workshop will cover how to get started with jest-axe to detect code-based accessibility violations, and Lighthouse CI to validate the accessibility of fully rendered pages. No amount of automated tests can replace manual accessibility testing, but these checks will make sure that your manual testers aren't doing more work than they need to.
Bringing your React Web App to native with Capacitor
React Summit 2022React Summit 2022
92 min
Bringing your React Web App to native with Capacitor
WorkshopFree
Mike Hartington
Mike Hartington
So, you have a killer React app you've built and want to take it from your web browser to the App Store. Sure, there are a lot of options here, but most will require you to maintain separate apps for each platform. You want your codebase to be as close as possible across Web, Android, and iOS. Thankfully, with Capacitor, you can take your existing web app and quickly create native iOS and Android apps for distribution on your favorite App Store!
This workshop is aimed at intermediate developers that have an existing React application, or are interested in mobile development with React. We will go over:
What is CapacitorHow does it compare to other cross-platform solutionsUsing Capacitor to build a native application using your existing web codeTidying up our application for distribution on mobile app stores with naming conventions, icons, splashscreens and more.
Web Accessibility in JavaScript Apps
React Summit 2022React Summit 2022
161 min
Web Accessibility in JavaScript Apps
Workshop
Sandrina Pereira
Sandrina Pereira
Often we see JavaScript damaging the accessibility of a website. In this workshop, you’ll learn how to avoid common mistakes and how to use JS in your favor to actually enhance the accessibility of your web apps!
In this workshop we’ll explore multiple real-world examples with accessibility no-nos, and you'll learn how to make them work for people using a mouse or a keyboard. You’ll also learn how screen readers are used, and I'll show you that there's no reason to be afraid of using one!
Join me and let me show you how accessibility doesn't limit your solutions or skills. On the contrary, it will make them more inclusive!
By the end, you will:- Understand WCAG principles and how they're organized- Know common cases where JavaScript is essential to accessibility- Create inclusive links, buttons and toggleble elements- Use live regions for errors and loading states- Integrate accessibility into your team workflow right away- Realize that creating accessible websites isn’t as hard as it sounds ;)