Accessible by Default: Building Apps That Everyone Can Use

This talk is about something that's often treated as an afterthought in app development, accessibility. But if we want to build for scale, for inclusion, and for longevity, accessibility can't be optional. I once heard a really brilliant speaker say, we're all pre-disabled. That phrase really stuck with me because the truth is, whether through aging or injury or just life itself, every one of us will likely experience some kind of limitation at some point.

Think about it. Maybe a broken arm or try holding a baby while checking your phone, struggling to see your screen in bright light. Those are all situational disabilities. Accessibility isn't just for other people, it's for all of us. Not everyone interacts with technology the same way. Some people use screen readers, some navigate entirely with keyboards, and some have their font size turned way up just to read.

Accessibility covers a whole spectrum. Permanent disabilities like low vision or motor impairments. Temporary ones like breaking your arm or using your phone with your non-dominant hand. And even situational ones like holding a baby or reading in sunlight or maybe even dealing with poor internet. Accessibility isn't a feature, it's the foundation for good design. So accessibility isn't just for other people. It's for you, your coworkers, your parents, your future self. And whenever we build apps with that mindset, we're not just meeting checkboxes, we're creating experiences that are more usable, more thoughtful, and more inclusive for everyone.

So here's our roadmap. Today, we're going to talk about why this is important, what React Native offers currently, a demo of a broken app, we're going to fix some features there, go over some tools you can use, and by the end, I want you to have some practical takeaways that you can act on right away. First and foremost, who am I? My name's Carly Lam. I've worked at startups and enterprise and I've built apps that have scaled from scrappy MVPs all the way to Fortune 1 acquisition. What I've seen across industries is that apps that scale share one thing in common. They're built for more than just the ideal user. They're built with quality and clarity and compliance already baked in. And this is the recipe.

So we start with that technical clarity, clean boundaries, modularity, and scalable architecture. Then we can build in that resilience with observability and error handling. But when you really want to scale, when you're being evaluated by enterprise, government, or even just really high traffic use, you hit this top tier, and that's that security and compliance.

Accessibility, it's not just a UX nicety. It sits right here under compliance. It's required under the WCAG and it's enforced by the ADA. And it's your ticket into the serious business. One in four adults in the United States have some form of disability that impacts how they're interacting with technology. That's a fourth of your potential user base.

Skipping accessibility, it doesn't just hurt your users. It puts your company at some serious risk. Legally, financially, reputationally, lawsuits tied to accessibility are really on the rise right now. The ADA and WCAG are being actively enforced. Your app might not even be allowed in some countries if it fails to meet accessibility requirements. For example, the European Union's Digital Markets Act now requires apps to meet stronger accessibility standards just to stay listed in EU app stores.

It puts your company at some serious risk. Legally, financially, reputationally, lawsuits tied to accessibility are really on the rise right now. The ADA and WCAG are being actively enforced. And here's the part that most teams overlook. Your app might not even be allowed in some countries if it fails to meet accessibility requirements. Now we're not talking about just losing a quarter of your audience in the U.S. That's entire countries or even continents that your product may never even reach. For example, the European Union's Digital Markets Act, it now requires apps to meet a lot stronger accessibility standards just to stay listed in EU app stores.

So that means features like voice navigation or adjustable contrast and captions, they aren't just nice to have, they're actually mandatory. So failing to comply, your app could possibly be removed from those markets entirely. So whenever we skip accessibility, we're not just ignoring users, we're quietly closing that door on a whole global opportunity. Domino's. They got dragged into a six-year lawsuit over a user with visual impairments not being able to order pizza on their app. Target, they had to pay out $6 million. Nike, they lost trust in users whenever screen readers failed. Banking apps under pressure broke completely when users scaled text. These aren't just corner cases, they're pretty common cases.

The word accessibility literally means easy to reach or use. So when apps are designed that way, users stay longer because things simply work. Big tap targets, clear labels, readable fonts, these don't just help people with disabilities, they improve usability for all of us. It also helps boost your user retention. Users really like whenever apps are easy to use, and you even get some SEO benefits. So let's look at a quick example that shows just how universal accessibility really is. When all the stalls in a public restroom are open, I bet most of us go straight for that accessible one. Why? Because it's bigger, it's easier to move around in, and just more comfortable. This last stall was designed for people with disabilities, but it ends up working better for everyone. Parents with kids, traveling with luggage, or anyone who just doesn't want their knees touching the door. That's the heart of accessible design. It's not only inclusive, it's simply just better design.

And there's a goofy photo from ChatGBT whenever I asked, how does it feel to use the small stall versus the handicap stall? So let's talk about why React Native is such a great place to start this conversation with app development. Well, it's one of the fastest growing mobile frameworks in the world, powering apps by millions from Meta to Coinbase to Shopify. Because it's cross platform, one accessibility improvement instantly helps users on both iOS and Android. So accessibility in React Native, it's still evolving, but that means that we have the opportunity to shape how it grows. So if you're going to start tackling accessibility, start where your reach is the biggest. Start where the tools are mainstream, start where your fixes really matter fast. React Native gives us that reach and that responsibility.

So first things first, let's talk about semantics. Semantics are really important in your app's code. Semantics give your app meaning beyond what it looks like. In React Native, most things are built with views, but a view is just a box. You can make it look like a heading or a button, but assistive technology doesn't really know what it is unless you tell it, right? So if you're not using a button component, instead you're building a custom one using a view, the assistive technology doesn't know that you're portraying that view as a button. So that's where we use our accessibility props. For example, the accessibility rule could really come into use here because it tells the screen reader what the element is, not just how it looks. This gives your app some real structure, makes navigation easier for everyone.

Let's see a quick example. So this is a simple example here. So you can see on the left, we have a style text element that looks like a heading, but it doesn't behave like one. And then on the right, we've got this accessibility role that we've assigned as a header. So now it actually acts like a heading for screen reader users. That tiny change right there makes a huge difference. It improves navigation and gives your app some real structure. So defining roles is one of the simplest and most overlooked ways that you can make your React Native apps a lot more accessible. And here's some common roles. You don't need a huge list to start. Just these roles here will cover about 90% of what you need. Whenever we assign these roles, we're telling the assistive technology, hey, this is a button. This is a header, just a really small change in your code that you can make, but a massive improvement in experience. So we're going to take a look here at an application as an example. Very simple application.

It's a to-do app. So features are very simple. You can add different tasks. You can check them on and off. If you've completed them, delete them, edit them. Very simple application.

But our users with disabilities, there may be some hidden bugs that make this app overly complex and really frustrating to use. So we're going to take a look at this application here. And it's going to click through the app using a screen reader.

So first and foremost, if you've never used a screen reader when testing your application, if you're using iOS, you're going to be using a tool called VoiceOver, and you just go to your settings, accessibility, and VoiceOver. If you're running Android, you're going to use a tool called TalkBack, where you just have to go to accessibility and then turn on TalkBack.

So I'm going to click through this app here, and you're going to hear the VoiceOver, and you're going to hear the screen reader click through the application. My tasks. Text. You are currently on a text element. Simple title list. Text. You are currently on a text element. So right off the bat, it lets us know it's a text element, but we don't necessarily know that these are headers so far. Today's task. Text. You are currently on a text element. Enter new task. Insertion at beginning of text. Edit text. So this is a big one here. It let us know that we're on a text field and we can type it to start typing text, but we don't necessarily know what kind of text to put in here. Now, this is a really simple application, so we could assume that the information that we type in here is going to be a task for our to-do list, but imagine that this was a really large form with lots of user input. That would be nearly impossible if we didn't tell them what the input was for and what to put in there.

You are currently on a text field. To enter text in this field, type. Another big one here. Right now we're highlighted over this plus button to add our task. Now, we just have an icon in there. There's no text, so the screen reader has nothing to read to the end user, so it's completely silent. The user has no idea about this button here because we haven't labeled it with some sort of accessibility label. Here's another one. Right now we are highlighted over the check box for one of our tasks. This is buy groceries here. It's not letting us know what the status of that check box is, which is pretty big because that's basically the entire feature of this application is being able to check off our to-do list items and see what we've gotten done. Buy groceries.

Text. You are currently on a text element. There we are. We know that we have one of the tasks, but we don't know what the status of it is. We know buy groceries is on tasks, but maybe we can't remember if we got that done yet or not. Well, that's the whole point of this task list is making sure that we get the items on our to-do list completed. Again, you can see we're highlighted on the edit button here, which is an icon. It's not able to read to us what that button is. Same with the delete button there.

Let's start taking a look at where we can start to fix this app here. This is a really great place to start here. Every interactive element gets a label and a role. This alone can transform a screen reader experience. Not to mention, it only takes about 10 seconds to start adding to your application. Let's take a look at this closer in the code and talk about it.

On this slide, you can see a side-by-side comparison of our to-do app before and after adding those accessibility props. On the left, you can see that text input and the touchable opacity button looks fine. They work visually, but they give no meaningful feedback to someone who's using a screen reader. On the right over here, you're going to see that we've added just three props that completely change the experience. First is the accessibility label. This gives the element a really clear, readable name, like enter new task or add new task. That way, users know exactly what they're interacting with. Then we have our accessibility hint. This is where we add the guidance, such as double-tap to add the task to your list or explaining what happens when the user takes action here. The last one is this accessibility role. That's how we tell the assistive technology what this element is. Is it a text field? Is it a button? Is it a header? This lets navigation make sense. These three simple lines of code, and suddenly, your app has a voice. That's what makes it truly usable for everyone. Next, let's talk about dynamic content.

Dynamic content, whenever we change the status of checking and unchecking items on our list, this is how we can do it here. On the left, we're just looping over some to-dos and rendering them visually. Looks fine, but voiceover doesn't know what a checkbox is, what a completed task is, or which button does what. There's no semantic meaning there.

On the right, we've enhanced every item with accessibility props. Now the screen reader doesn't have to guess. They're guided. That's the difference between accessible code and that invisible frustration. Let's take a closer look here. We can see that the entire to-do item has this accessibility label. That's how we announce the task name and whether it's completed.

Then we have the accessibility role. This is a checkbox for the toggle. This makes it clear to the screen readers what kind of control it is. Then we've added this new one here, this accessibility state. This is how we get that dynamic rendering. It gives the current state whether it's checked or unchecked, just like a native checkbox would. For edit and delete buttons, we've also added that accessibility role of a button. These clear labels allow you to interact with the application better.

Now the app can read, this is a checkbox. This is the buy groceries task. It's checked, basically. The app can work correctly now.

Let's take a look at our app after we've made some changes here. You can see what our voiceover is saying here. We enter a new task, tap here to add a new task to your list. You're currently on a text element.

Add new task button, so now it clicks it. It lets us know this is the add new task button. There will be a hint here to let us know to double tap to add the task to your list. You're currently on a button.

Now we've got a lot more information as we're using the application. Now we're on the checkbox here. It lets us know that it's unchecked. Edit task, buy groceries. Edit task, buy groceries. Now our icon buttons are giving us more information. Overall, the app is a lot more easy to use now, just from a few lines of code.

Here's another thing to talk about here, and that's text scaling. This is something that a lot of developers forget. Developers can and do increase their system font size. If your app doesn't support that, things break.

In fact, in my last role, we had a user that reached out because they literally couldn't get into the application. The first screen was a permissions page asking them to allow their location, but the font size was so large, and the agree button was pushed way off screen, and we didn't wrap it in a scroll view, so they had no way to move down the page, click the accept button, and enter into the application. That's not just a minor styling bug.

That's an actual user blocked from using the product. Approximately 20 to 25% of iOS users increase their text size using dynamic type. On Android, it's roughly 15 to 20% of users that increase their font scaling in their accessibility setting. On average, we're looking at about one in five people using your app.

They may be seeing a completely different layout than what you think and what you've been testing as. Let's look at this in action, and I'll show you how it breaks and then how to fix it. Here's that same to-do application. I'm going to go to my settings in my accessibility settings. I'll go to display and text size, enable my larger accessibility sizes, and then I'll just crank it all the way up. Let's go refresh our application and see how that looks now. You can see in here we've got some text coming off of the screen. Our to-do items, you can't read the full line there. Looks like our icons, they're not scaling effectively. We've got some buttons down here where we don't have enough real estate for the text anymore, so the button hasn't scaled with the text size. Let's take a look at the code and see what changes we can get started with.

On the left here, the app uses some hard-coded styles for headers and sub-headers. That's what results in those clipped or unreadable text for users who rely on the larger fonts, like we just saw. On the right, we've added some styles to scale dynamically, so let's zoom in on this. We've updated the styles to scale dynamically using that pixel ratio dot get font scale and the math dot max. This is so we can make sure that even whenever font sizes increase in size, the text still remains legible and fits within the layout that it's inside of. This is a good way to ensure that there's a better user experience for users who have that low vision, elderly users, or really anyone who customizes their font size for comfort. We've also kept in those accessibility props that we talked about, so the accessibility label, the hints, and the role. Label, text, and semantic accessibility, they go hand in hand, and both really matter. After we added just some simple changes here, let's take a look at the app now.

Now we can see that our text is scaling effectively. We can see that our text isn't going off of the screen anymore. It's staying within the view that it's in. We can see the entirety of our task items now. Our icons have gotten a little bit larger. Just a quick change that you can make to get started with scaling your text effectively there. Here's a few resources and tools that can help you get started to make your apps more accessible. Start testing for accessibility. The first one is that React Native Accessibility Engine. Here's a quick example of how it looks to work with it.

Basically, this is a tool that helps enforce good practices automatically. It integrates into your code base, and then it gives you warnings about missing accessibility props. It's basically like a linter for inclusivity.

The next one that I wanted to mention was manual testing. Automation is great, but manual testing is still king here. Use your app the way that a real user might. Enable voiceover like we had just tested. Bump up your font size like we just did, and try it with one hand while you're walking. This is a really good way to spot gaps, is to try using your application. Try breaking it with different accessibility features and try to put yourself in the shoes of somebody who might be using these accessibility assistive technologies.

Lastly, the native accessibility inspectors. Both platforms provide really powerful inspectors, both iOS and Android. They let you analyze the semantics of your app. You can audit your application. Use those during developments. That way you can spot some gaps in how the screen readers might interpret your UI or maybe color contrasts. One other one that I wanted to add in here is leveraging AI. AI is huge right now. It's very powerful. AI can be a really, really powerful partner in your accessibility testing.

Start with maybe some of your AI coding assistants like GitHub Copilot or ChachiBT Cursor, Claude. These tools can help you suggest different accessibility prompts while you code, like adding that accessibility label or maybe flagging some hard-coded styles that impact your scaling. You can also use AI to analyze your UI or your components. For example, you could prompt ChachiBT to review a snippet and recommend accessibility improvements. It can suggest those semantic tags, help names, unlabeled buttons, or maybe just refactor some poor structure. You can also use it to generate those accessibility labels.

You can also translate Figma or design files into accessible code. This really helps designers and engineers align that in that early process with getting accessibility into your current process. The key is really to use AI as a supplement, not a replacement. You still need that empathy and that testing, but AI can help speed up the path to inclusion. Here's a few things that you can get started with right away. Spend about five minutes using your app with voiceover or TalkBack. You'll be shocked by what you learn.

Pick maybe just one screen at a time, increase your phone text all the way, and see what breaks. Then fix it. Go label a few buttons. Start small, just three. It adds up very fast. Then if you can, talk to a real user who depends on accessibility features. Ask them what frustrates them. And lastly, bring this into your current process. Make accessibility part of your definition of done, your QA checklist, or even your code review flow. If everyone watching this did just one of these, we'd have a lot more inclusive apps just by the end of the week.