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.

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.

Available in Español

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
Configuring Axe Accessibility Tests
TestJS Summit 2021TestJS Summit 2021
30 min
Configuring Axe Accessibility Tests
Top Content
Axe-core is a popular accessibility testing engine that is used Google, Microsoft, and hundreds of other companies to ensure that their websites are accessible. Axe-core can even integrate into many popular testing frameworks, tools, and IDEs. In this advanced session, we'll be learning how to configure axe and its integrations to fine tune how it runs and checks your pages and code for accessibility violations.
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
App development is hard, React and Expo make it easy!It's never been simpler to build and deploy powerful mobile apps with incredible features to both Android and iOS users all over the world.We’ll discuss building and deploying mobile apps seamlessly from the cloud using EAS, creating powerful dev clients (like browsers but for mobile app development) for testing your app, pushing OTA updates instantly to users, and much more — no native experience required!
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
Usually creating web and mobile apps require different tech stacks, and it is pretty hard to share code. This talk will show how I added a React web app and a React Native mobile app in the same monorepo using Nx, and how I optimized codeshare between react web app and react native mobile app.
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
Our design systems commonly feature components that show on top of other content: tooltips, date pickers, menus and teaching UI, to name just a few. Proposed updates to the web platform are about to make building these a whole lot easier. You might not even need JavaScript. In this talk, you’ll learn all about the upcoming ‘popover’ attribute, modality and the top layer.
a11y and TDD: A Perfect Match
JSNation 2022JSNation 2022
24 min
a11y and TDD: A Perfect Match
Accessibility has been web development's ugly duckling for quite some time now. I often get asked, "when should you test for a11y in your apps?" My answer is simple, "right from the start!". Regardless of the framework considered - React, Svelte, Vue, YourOwn™️ - as developers we are in a privileged position to help the ugly duckling grow into a beautiful swan. How? By diving deep into the pond and harnessing the power of Javascript APIs to build the right components for your web apps. And how can do you know you are building them right? By pairing Test Driven Development with the Testing Library family. Ready to grow your web apps into swans?

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!
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 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.
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 ;)
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.