--- title: How Do I Make My App Accessible for Users With Disabilities? description: Learn how making an app accessible works in practice, covering visual design, assistive tech, testing, legal duties and long-term upkeep. image: https://weareaffective.com/hubfs/learning-centre-images/how-do-i-make-my-app-accessible-for-users-with-disabilities.webp --- [Skip to content](https://weareaffective.com/learning-centre/how-do-i-make-my-app-accessible-for-users-with-disabilities#main-content) [![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com) - [Home](https://weareaffective.com) - About Us - [Our Story](https://weareaffective.com/about) - [How We Work](https://weareaffective.com/how-we-work) - Our Services - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy) - [App Design](https://weareaffective.com/app-design-agency) - [App UX Design](https://weareaffective.com/app-ux-design) - [App UI Design](https://weareaffective.com/app-ui-design) - [App Technical Architecture](https://weareaffective.com/app-architecture) - [Existing App Audits](https://weareaffective.com/app-audit) - [Case Studies](https://weareaffective.com/case-studies) - [Pricing](https://weareaffective.com/pricing) - [Learning Centre](https://weareaffective.com/learning-centre) - [Get Started](https://weareaffective.com/get-started) Expert Guide Series # How Do I Make My App Accessible for Users With Disabilities? Table of Contents We worked on a document portal for the film industry, built for crew who needed files fast while a set was running around them. The people using it ranged from runners to producers, on every kind of device, in every kind of light. Making an [app accessible was an active design decision](https://weareaffective.com/app-ux-design) on that project from the very first sketch, so the design was large scale, easy to move around, and shaped around reaching information in the simplest way possible. > Accessibility is a design decision made early, long before anyone opens a compliance checklist. Nobody on that project used the word compliance. The brief was simply that a very mixed group of people, under time pressure, had to get to what they needed without a fight. That turns out to be the same brief as accessibility, just phrased in a way product teams act on. This article walks through how we think about app accessibility for disabilities across a whole project, from the first scoping conversation to the features someone adds eighteen months after launch. Some of it is visual design, some of it is code, and a surprising amount of it is decisions made in a room before any design exists. We'll use our own projects throughout, including a few where we got pushed in a better direction by what users told us. ## Who You Are Actually Designing For The [film portal taught us something we now carry](https://weareaffective.com/learning-centre/what-film-industry-document-portal-users-taught-us-about-designing-for-people-wh) into every project. A diverse user base isn't a special case you plan for separately. It's the normal condition of any product that reaches more than a hundred people. Disability covers a wide spread of needs, and a lot of them are invisible. More than a quarter of the world's population has a diagnosed vision impairment, according to the [World Health Organization](https://info.arxiv.org/about/accessibility_research_report.html). Add hearing, dexterity, cognitive and mental health differences and you're describing a very large slice of any audience. Then add the temporary and situational versions, like a broken wrist, bright sunlight, a cracked screen or holding a baby in one arm. | Who | What gets in the way | What helps | | --- | --- | --- | | Low vision | Thin type, pale greys, fixed text size | Strong contrast, text that scales | | Colour deficient vision | Status shown by colour alone | Labels, icons, shape | | Deaf or hard of hearing | Audio-only alerts, uncaptioned video | Captions, transcripts, visible alerts | | Limited dexterity | Tiny targets, drag gestures, timeouts | Large targets, tap alternatives, no clocks | | Cognitive differences | Dense copy, jargon, long forms | Plain words, one task per screen | Read that table as a description of your whole audience on a bad day, and accessible mobile design stops feeling like a separate workstream. ## The Decisions That Lock In Accessibility Before Design Starts A property developer came to us for a concierge app for high-rise buildings. They arrived with a budget and a fairly fixed idea of the product, and what they wanted from us was a sign-off rather than a scoping exercise. We talked them into a [proper discovery phase with focus groups](https://weareaffective.com/learning-centre/how-to-scope-a-pre-build-research-phase-when-the-budget-is-already-signed-off-fo) and user workshops first. What came back was that the product needed to be far simpler than they'd pictured. We dropped a lot of the planned features and focused on building a human connection with the app rather than duplicating systems already running in the building. Better product, lower cost, and far less surface area for anyone to get lost in. #### Where making an app accessible starts Scope is an accessibility decision. Every feature you add is another flow to label, test and keep working for someone using a screen reader at 200% text size. We learned a related lesson on a [sports club app, where the pressure to launch](https://weareaffective.com/learning-centre/what-scope-creep-actually-costs-a-sports-club-app-that-spent-twelve-months-growi) everything at once rather than release in stages put the whole project at risk. Working with an iterative process gives you room to fix what testing finds. Launching one enormous build gives you none. ## UX/UI design built around *real* psychology We design app interfaces around how people actually think and behave. User research, psychology-driven UX/UI design and technical specs delivered as one complete package. [See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started) No commitment ## Research and Discovery: Finding the Barriers Nobody Mentioned On a dating app project, we put serious effort into onboarding, validation and verification. Discovery didn't cover the messaging side, because that wasn't where the client wanted to spend time. So messaging got built generically, and it allowed exactly the fake, automated behaviour that all the onboarding work existed to stop. The two halves of the product contradicted each other. That's what partial discovery does, and accessibility fails the same way. A carefully labelled sign-up flow leads into a settings screen nobody checked, and the person using a screen reader hits a dead end three taps after the bit you were proud of. > Discovery that skips half the product builds a product that argues with itself. So we scope research across the whole journey, including the parts that feel boring. Account recovery, error states, payment, cancellation, notification settings. These are the screens people reach when something has already gone wrong, and they're where barriers hide. Recruiting disabled participants into that research is the part teams skip. Talk to people who use magnification, switch control, voice input and screen readers, and talk to them about their real tasks rather than a script you've written. ## Visual Design: Contrast, Type and Colour The film portal design was deliberately large scale. Big type, generous spacing, clear hierarchy, because someone reading a call sheet between takes has about four seconds of attention. That same design holds up for anyone with low vision, which is the useful thing about designing for the hardest condition first. Contrast has a floor you can measure. WCAG 2.1 asks for at least [4.5 to 1 for normal text and 3 to 1 for large text](https://www.w3.org/TR/WCAG21/), and those thresholds apply in dark themes too, which is where a lot of pale grey-on-grey creeps back in. Check your contrast on the real device outdoors, not on a calibrated monitor in a dark studio. Sunlight is the honest test. #### Colour carrying meaning on its own If red means a problem and green means it's fine, say so in words as well. Colour deficient vision is common enough that colour-only status will fail some of your users on day one. We saw a related mismatch on a health and wellness genetics app. The packaging and website were luxurious and aspirational, all about becoming a better version of yourself, and the app was [cold and clinical. People went from that promise](https://weareaffective.com/learning-centre/why-does-my-app-feel-cold-even-though-the-design-looks-good), through ordering a kit and taking a test, to a screen that felt like a lab printout. Clarity and warmth can live in the same design. ## Touch, Motion and Input Tap targets are the cheapest accessibility fix in existence and still the most commonly missed. Anything a person taps needs to be comfortably large with space around it, because precision varies with tremor, fatigue, cold hands and screen size. The film portal worked partly because everything was oversized on purpose. Gestures are the next trap. A swipe-to-delete or a long-press menu is fine as a shortcut, as long as the same action sits somewhere a person can simply tap. The same goes for shake-to-undo, pinch-to-zoom and anything that needs two fingers at once. Motion deserves a mention of its own. Parallax, bouncing transitions and animated backgrounds cause real nausea and dizziness for some people, and both iOS and Android expose a reduced motion setting that tells you who they are. Respect it, and swap the movement for a simple fade. Try your app for a day using only one thumb, with the phone in your non-dominant hand. You'll find every target that's too small and every gesture with no backup. Input matters too. Forms should use the right keyboard type, accept pasted text, allow autofill and never block password managers. Each of those is a small thing that removes a lot of typing. ## Sound, Speech and Video Sound works as an extra layer and falls apart as the only layer. An audio alert on its own reaches nobody who's deaf, nobody with the phone on silent, and nobody standing near a generator on a film set. Pair it with something visible and something you can feel through haptics, and the message gets through in all three cases. Video needs captions, and captions need to be accurate rather than whatever the automatic transcription produced. Onboarding videos, product demos, exercise clips and brand films all carry information somebody has paid for, and uncaptioned video hands that information to a smaller audience than you think. - Captions on every video that carries meaning, checked by a human - Transcripts for audio content, so people can read or search instead - Audio descriptions where action happens with no narration - No autoplay with sound, and a clear way to stop anything moving - Player controls that work with a screen reader and a keyboard Voice input runs the other way. Speech-to-text has become a primary input method for plenty of people with dexterity or vision differences, so the practical requirement is simply that your fields accept dictated text cleanly and your buttons have names a person can say. ## Language, Comprehension and Cognitive Load We worked on a genetics product where the balance was education against anxiety. People arriving at a genetics result already carry some worry with them. Pile on medical terminology and the worry grows. Strip the science out entirely and they stop trusting the result. Our plan was plain language and real-world analogies as the first layer, with the medical and scientific detail sitting underneath for anyone who wanted it. The client preferred full medical detail as the default. We ran user testing, and it backed the layered version, which produced higher comprehension and lower anxiety among the participants. > Plain language first, with depth available on request, beats everything shown at once. That structure is called progressive disclosure, and it does a lot of work for cognitive accessibility. Each screen carries one idea. Anyone who wants more taps for more. Nobody has to hold six concepts in their head to finish a task. Plain words help everyone, including the people reading on a phone in a loud room with four minutes to spare. Short sentences, familiar vocabulary, and headings that say what's underneath them. ## Designing for Stress, Distraction and Time Pressure Simon puts it as unburdening people of tasks that seem perfectly straightforward in calm conditions. Work out the absolute minimum you need to ask of someone, then work out the absolute maximum you can do to help them with it. Stress narrows attention in a way that looks a lot like a cognitive impairment, and the design response is the same. When somebody's struggling partway through a process, strip the screen back to what the current moment genuinely requires. Anything that asks for a lot of input and doesn't serve the task in front of them can wait until they're in a better state. For any form, ask what each field is for and who reads it. If the answer is "marketing, eventually", move it out of the flow and ask later. Time limits deserve particular suspicion. A session that expires mid-form, a code that dies in thirty seconds, a carousel that moves on before you've read it. Each of those assumes a reading and reacting speed that plenty of people don't have. Visual guidance helps more than extra instructions. Show the step, show the progress, show what good looks like, and let people correct a mistake without starting again. ## Privacy and Safety as Accessibility Issues We worked on a social product for [fitness that was built around a map](https://weareaffective.com/learning-centre/what-a-fitness-social-app-changed-when-it-realised-precise-location-was-the-wron). The original idea was showing your real-time location so people nearby could meet up for a shared workout. Research then told us a high proportion of users were going to be female, and security became a much bigger question than the original brief allowed for. So we rebuilt the feature with randomised location offsets. You saw the rough area a potential workout partner was in, enough to judge whether meeting up made any sense, and nothing more precise. People talked first, looked at each other's profiles, and chose to share their exact location when they were ready. That's an accessibility story as much as a safety one. A product that feels unsafe is unusable for the people it threatens, no matter how good the contrast ratios are. The same logic applies to anyone whose disability is visible in their data. Accessibility settings reveal things about a person. Somebody turning on screen reader support, reduced motion or large text is telling you something private. Keep that information out of analytics you share, out of public profiles, and out of any feature that broadcasts behaviour to other users. ## Building for Screen Readers and Assistive Technology A screen reader turns your interface into a list of spoken elements in a set order. Everything visual that carries meaning has to exist in that list with a sensible name, or it simply isn't there. On the baby monitor project, the app controlled a physical device, with settings that had to apply correctly and report back their state. A toggle like that has to announce what it controls and whether it's on, because a person using VoiceOver gets nothing from a shape that changed colour. #### What the build actually needs - Every control labelled with what it does, not what it looks like - Images described, or marked decorative so they're skipped - A reading order that follows the visual order of the screen - Focus that moves to new content when a sheet or dialog opens - State announced for toggles, tabs, errors and loading - Native components where possible, since they bring this for free Turn on VoiceOver or TalkBack, close your eyes, and complete your core flow. Whatever you can't finish is the work list. Text scaling belongs here too. Support the system text size settings properly so layouts reflow instead of clipping, and test at the largest setting rather than one notch up from default. ## Performance, Stability and Why Slow Apps Exclude People Bugs and slow loading drive more people out of an app than anything else, and poor design with no emotional connection sits not far behind it. Both of those land hardest on people who were already working harder to use your product. A screen reader user who loses focus position during a slow load has to start the screen again. Somebody with limited dexterity who taps a button twice because nothing happened triggers the action twice. A person with a cognitive difference who waits six seconds for a confirmation has lost the thread of what they were doing. > Slow and unstable software excludes people just as firmly as bad contrast does. Older and cheaper devices matter for the same reason. Assistive technology users often hold onto hardware for longer, because switching device means relearning a setup that took months to get right. An app that only runs well on this year's flagship has quietly drawn a line around its audience. Offline behaviour counts as well. Clear states, retained input, and errors that explain what happened rather than a spinner that never resolves. ## Testing With Real Users, Not Just Scanners Automated scanners find missing labels, contrast failures and touch targets below size. They don't find a flow that makes no sense when you can't see it. More than 60% of accessibility issues surface through manual testing rather than automated checks, according to [PCloudy](https://www.uxpin.com/studio/blog/checklist-for-manual-testing-of-react-components/), which matches what the scanners can structurally detect. On the baby monitor project we had no finished hardware to test against, so we built a prototype that ran a web server from the device itself. We connected to it, watched what was happening inside, confirmed the settings applied were reflected correctly, and drove the device from the app at the same time. The full loop, simulated, before anything shipped. That's the standard worth holding for accessibility testing too. Build something real enough to break. 1. Run automated checks and clear the obvious failures first 2. Complete every core flow with a screen reader, eyes closed 3. Repeat at the largest system text size and in dark mode 4. Test with keyboard, switch control and voice input 5. Run moderated sessions with disabled participants on real tasks 6. Fix, then retest the flows you changed The genetics project is the proof of why step five matters. User testing settled a disagreement that no scanner has an opinion about. ## WCAG, the Equality Act and What You Are Legally Obliged to Do In the UK, the Equality Act 2010 requires service providers to make reasonable adjustments so disabled people aren't put at a substantial disadvantage. That duty is anticipatory. You're expected to have thought about it before a disabled customer turns up, rather than fixing things once somebody complains. WCAG is the standard everyone measures against, and Level AA is the practical target for commercial apps. It's written for the web, with a mobile-specific interpretation published by the W3C, and it gives you testable criteria for contrast, labelling, text spacing, focus and input. If you sell into the United States, the ADA applies to companies with [15 or more employees](https://www.ada.gov/), and app accessibility for disabilities has been the subject of plenty of US litigation. European accessibility rules now reach consumer apps in a lot of categories too. Treating the legal position as the brief produces thin work, though. The film portal was built for a diverse group of people under time pressure, and it met the standard because it was designed properly. The teams that chase the minimum tend to spend the same money and get an app people still can't use. ## Keeping an App Accessible After Launch A client added a rating prompt that fired the moment someone opened the app. People hadn't had a chance to experience the product yet, so the ratings meant very little, and the prompt sat on top of whatever that person was trying to do. A modal that appears over a screen someone's mid-task on is a barrier for anyone using a screen reader, and an interruption for everyone else. Prompts like that belong after a genuinely positive moment, once somebody has achieved something in the app. The wider lesson is that accessibility decays through additions. New features, marketing overlays, seasonal banners and third party widgets all arrive after the audit. WebAIM's analysis of the top million home pages found detectable WCAG failures on [98.1% of them](https://webaim.org/projects/million/), and web and app teams share the same habits. Three things keep it from slipping. Put accessibility rules into the design system so labelling and contrast come as standard. Add accessibility checks to code review and release testing. Book real user testing on a schedule rather than when someone complains. ## Conclusion The pattern running through all of this is that accessible mobile design is mostly ordinary good design, done earlier and checked properly. The film portal was large scale and simple because crew needed information fast. The genetics app used plain language with depth underneath because testing said that produced better understanding and less anxiety. The fitness product hid exact locations because research showed who the users were going to be. None of those started as accessibility work. All of them ended up as accessibility work, because designing for the person having the hardest time is how you end up with something that holds for everyone else. If you're starting a new product, the cheapest moment to deal with this is now, during scoping, when you're deciding what the app does at all. If you've already launched, start with a screen reader run through your core flow and a contrast check across every theme. You'll have your list within an afternoon. We're happy to look at where your app stands and what the realistic first steps are. [Let's talk about making your app accessible](https://weareaffective.com/get-started). ## Frequently Asked Questions When should accessibility be considered in an app project? Accessibility works best as a design decision made at the very first sketch, not a compliance check bolted on near launch. The earlier it shapes scoping, structure and layout, the less expensive it is to put right later. Who am I actually designing for when I think about accessibility? You are designing for a far wider group than people with a formal diagnosis, including those with low vision, colour deficient vision, hearing loss, limited dexterity and cognitive differences. You are also designing for temporary and situational cases, such as a broken wrist, bright sunlight, a cracked screen or holding a baby in one arm. What are the most common barriers that stop people using an app? Thin type, pale greys and fixed text sizes block people with low vision, while status shown by colour alone excludes those with colour deficient vision. Tiny tap targets, drag gestures, timeouts, dense copy and long forms cause problems for people with limited dexterity or cognitive differences. What practical changes make the biggest difference? Strong contrast, text that scales, large tap targets and plain language cover a huge amount of ground. Adding labels, icons or shape alongside colour, plus captions and transcripts for audio and video, removes most of the remaining common barriers. Is accessibility mainly a visual design job or a development job? It is both, plus a surprising amount of decision making that happens in a room before any design exists. Scoping conversations about which features to build and how simple the product should be often matter more than any individual styling choice. Does designing for accessibility mean cutting features? Often it means cutting the right ones. On a concierge app for high-rise buildings, discovery work showed the product needed to be far simpler than the client had pictured, so planned features were dropped in favour of a clearer, more human experience. Is it worth running research if the budget is already signed off? Yes, because a short discovery phase with focus groups and user workshops can reshape the brief before money is spent building the wrong thing. Clients who arrive expecting a sign-off frequently leave with a smaller, stronger and more usable product. How do I keep an app accessible after launch? Treat accessibility as a standard applied to every new feature, including ones added eighteen months down the line. Without that, a product built well at launch slowly drifts as new screens, flows and content are added by people who were not in the original conversations. ## Related Articles [![What Design Principles Create the Most Intuitive Mobile App Interfaces?](https://weareaffective.com/hubfs/learning-centre-images/what-design-principles-create-the-most-intuitive-mobile-app-interfaces.webp)](https://weareaffective.com/learning-centre/what-design-principles-create-the-most-intuitive-mobile-app-interfaces) ### [What Design Principles Create the Most Intuitive Mobile App Interfaces?](https://weareaffective.com/learning-centre/what-design-principles-create-the-most-intuitive-mobile-app-interfaces) Hand someone a phone with an app they've never opened and watch their thumb. It hovers, it moves,... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![Are Your App Developers Making Your Technical Debt Better or Worse?](https://weareaffective.com/hubfs/learning-centre-images/are-your-app-developers-making-your-technical-debt-better-or-worse.webp)](https://weareaffective.com/learning-centre/are-your-app-developers-making-your-technical-debt-better-or-worse) ### [Are Your App Developers Making Your Technical Debt Better or Worse?](https://weareaffective.com/learning-centre/are-your-app-developers-making-your-technical-debt-better-or-worse) Spend enough time working on digital products and you notice a pattern. A client arrives with a... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![How do I localise my app store listing for different countries?](https://weareaffective.com/hubfs/learning-centre-images/how-do-i-localise-my-app-store-listing-for-different-countries.webp)](https://weareaffective.com/learning-centre/how-do-i-localise-my-app-store-listing-for-different-countries) ### [How do I localise my App Store listing for different countries?](https://weareaffective.com/learning-centre/how-do-i-localise-my-app-store-listing-for-different-countries) Launching an app in Germany is a different task from launching it in Japan, and not because of... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com) 20-22 Wenlock Road London, N1 7GU United Kingdom +44 20 4572 8062 [hello@weareaffective.com](mailto:hello@weareaffective.com) Services [App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit) Legal [Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70) Case studies [TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift) About us [Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work) Guides [Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth) Copyright © 2026, weareaffective.com. All rights reserved.