From Buttons to Braille How We Design Apps for Every User

Accessibility is one of those words that gets used a lot and understood rarely. In app design, it tends to mean one of two things to most people: either making sure the app works with a screen reader, or checking a compliance box before launch. Both of those things matter, but neither of them captures what accessible design actually is when you do it properly.

Accessibility done well makes things work better for everyone, not just the people it names.

The World Health Organization estimates that more than a quarter of the world's population has a diagnosed vision impairment. Add in motor difficulties, cognitive differences, age-related changes, and situational constraints like bright sunlight or a broken hand, and the number of people who benefit from thoughtful accessible design grows considerably. Accessibility, done well, makes things work better for everyone.

At WAA, we've worked on products ranging from anonymous messaging apps to film industry document portals, from logistics platforms to premium property concierge tools. Across all of them, the moment accessibility became a genuine design priority rather than an afterthought, the product got simpler, faster, and easier to use across the board. This article covers what we've learned, what we've built, and how we approach accessibility as a core part of the design process rather than a layer bolted on at the end.

What Accessibility in App Design Actually Means

Accessibility in app design covers a wide range of human needs. Visual accessibility includes things like contrast, text size, and colour. Motor accessibility is about how people interact physically with a screen, including users who cannot tap precisely or who use assistive input devices. Cognitive accessibility is about how much mental effort an interface demands. And then there is auditory accessibility, which covers captioning and audio alternatives.

These categories overlap constantly. A person with low vision may also find dense interfaces cognitively difficult to parse. A user with a motor impairment benefits from the same large touch targets that help a parent holding a baby in one arm. Designing for one type of need very often improves the experience for users you had not specifically considered.

Compliance frameworks like WCAG (Web Content Accessibility Guidelines) set a useful baseline. They define minimum standards across perceivability, operability, understandability, and robustness. In the US, the ADA requires accessible apps from companies with 15 or more employees. But compliance and good design are not the same thing, and we'll come back to that distinction later. The more useful question is not whether an app meets the minimum standard but whether it works for the full range of people who will use it.

Visual Accessibility: Contrast, Scale, and Hierarchy

Visual accessibility is the area most designers encounter first, and it covers more ground than colour alone. Contrast between text and background determines whether someone can read your interface at all. The WCAG minimum is a 4.5:1 contrast ratio for body text, and that number is not arbitrary. Colour contrast affects how readable an interface is under different lighting conditions and for users with conditions like cataracts or low contrast sensitivity, not only those with colour blindness.

Colour blindness is more common than many people assume. Around 12% of men worldwide have colour-deficient vision. If your interface relies on colour alone to communicate meaning, a red error state with no icon or text label, a green confirmation with no supporting copy, a meaningful proportion of your users will miss it entirely.

Scale matters too. Resizable text is one of the most commonly implemented accessibility features among mobile developers, and for good reason. Users with low vision or those simply in a difficult reading environment benefit enormously from interfaces that flex gracefully when system font size is increased. Designing for scale from the start is far easier than retrofitting it later, because layouts that assume a fixed text size tend to break badly when that assumption is removed.

Design your interface at two or three different system font sizes before you finalise layouts. If the design breaks, fix the layout now rather than discovering it at testing.

Hierarchy and Focus States

Visual hierarchy helps users understand what to look at first and what to do next. Clear heading structures, strong contrast between primary and secondary actions, and visible focus states for keyboard or switch navigation are all part of this. Focus states are particularly easy to forget on mobile, but any user who navigates with an external keyboard or assistive technology depends on being able to see exactly where they are on screen.

Screen Reader Compatibility and Semantic Structure

Screen readers convert visual interfaces into audio, reading out content in a sequence determined by the underlying structure of the code. For a screen reader user, a button with no label is an obstacle. An image with no alt text is invisible. A form that uses visual position to imply relationships, rather than semantic markup to state them, is genuinely unusable.

Semantic structure means using the right HTML or native mobile components for each element. A button should be coded as a button, not a styled div that looks like one. A heading should carry the correct heading level. Form fields should be associated with their labels. These choices do not affect how the interface looks to a sighted user, but they determine whether a screen reader can make sense of it at all.

A button with no label is an obstacle. An image with no alt text is invisible.

VoiceOver on iOS and TalkBack on Android are the two dominant screen readers on mobile. Both rely on apps providing meaningful accessibility labels for interactive elements, a logical reading order, and clear announcements when content changes on screen. The WebAIM annual study found that around 98.1% of home pages had detectable WCAG failures, which tells you how rarely this is done well, even on the web.

Turn on VoiceOver or TalkBack and navigate your app without looking at the screen. Every place where the experience becomes unclear or impossible is a place to fix.

Dynamic Content and Live Regions

When content updates on screen without a page reload, a success message, an error, a count changing, screen readers will not announce it automatically unless you tell them to. Live regions are the mechanism for this. Without them, a user who cannot see the screen completes an action and hears nothing, with no way of knowing whether it worked.

Motor Accessibility and Touch Target Design

Motor accessibility is about how people physically interact with a device. Some users have limited precision in their finger movements. Some use a stylus. Some use switch access, which cycles through on-screen elements one at a time and requires a single confirmatory action. Some use voice control, speaking commands to navigate. All of these users need interfaces that are forgiving and clearly structured.

Touch targets are the most common failure point. Apple's Human Interface Guidelines recommend a minimum touch target size of 44 by 44 points. Google's Material Design guidelines suggest 48 by 48 density-independent pixels. These are minimums, not targets to aim for and then reduce. Small, closely spaced interactive elements cause problems for users with tremors, limited grip strength, or reduced fine motor control, and they cause the same problems for anyone using a phone with one hand on a bus.

Gesture Complexity and Alternatives

Gesture-based navigation, like swipe-to-delete or pinch-to-zoom, can create real barriers for users with motor difficulties. Where gestures are used, they should always have an alternative, a button that achieves the same outcome, or a setting that replaces the gesture with a tap. This does not mean removing gestures from the interface entirely. It means not making them the only route to an action.

Spacing matters as much as size. A row of small icons placed close together creates a high-risk area for mis-taps, even when each individual icon meets the minimum size requirement. Generous padding around interactive elements reduces errors and reduces frustration for all users, regardless of motor ability.

Designing for Cognitive Load and Clarity

Cognitive accessibility is the hardest to define and the easiest to underestimate. It covers a broad range of needs: users with dyslexia, ADHD, memory difficulties, learning disabilities, or simply users who are anxious, tired, or navigating a service in their second language. What these users share is a lower tolerance for complexity, ambiguity, and information overload.

Reducing cognitive load means making decisions about what to show and when. Progressive disclosure, where detail appears only when a user needs it rather than all at once, keeps screens clear. Plain language reduces the processing required to understand instructions. Consistent navigation reduces the effort of remembering where things are. Short, single-purpose screens are easier to complete than long, multi-task ones.

Error handling is a particularly important part of this. An error message that says "Error code 403" tells a user nothing useful. One that says "You don't have permission to view this page, please log in to continue" tells them exactly what happened and what to do next. The difference in cognitive effort between those two messages is significant, especially for users already operating at their limit.

Consistency as a Cognitive Tool

Consistency lowers the cost of learning an interface. When buttons look the same throughout an app, when navigation lives in the same place on every screen, when language is used predictably, users do not have to re-learn each screen they encounter. For users with cognitive difficulties, this consistency is functional, not just aesthetic. Every surprise in the interface is an obstacle. Removing surprises is a form of accessibility.

Accessibility Under Pressure: Lessons from a Film Industry Portal

We worked on a document portal for the film industry, designed for use by many different types of people across a production. Because productions run under real time pressure and the people using the tool would be scattered across locations, under stress, and often switching between tasks, we made accessibility an active design priority from the start.

The design was large-scale, with high contrast and generous spacing. Navigation was built to be as direct as possible, with information reachable in as few steps as we could manage. Everything about the design was oriented around getting to the right document quickly, in the simplest way, under conditions that were rarely ideal. The people using this portal were not necessarily sitting quietly at a desk. They were on set, potentially in poor light, possibly handing a phone to a colleague while managing something else.

This project made something clear to us that we have carried into every project since. Accessibility in a professional context is partly about serving users with particular needs and partly about serving every user under the conditions they are actually in, not the conditions you imagine them in when you design. A person with perfect vision, in a rush, in poor light, is functionally in a similar position to someone who always needs high contrast and large text. Design for the harder context and you serve both.

The film industry portal also had to work across a wide range of roles and experience levels with technology. A production designer and a runner might both use the same tool. Designing to the lowest assumed level of technical confidence, without stripping utility from experienced users, was a constant balance to manage.

Safety and Reporting as Accessibility Features

Safety features are not typically framed as accessibility, but they belong in the same conversation. An interface that fails to give users a clear route to report harm, escalate a concern, or protect their own safety is inaccessible to any user in a vulnerable situation.

On an anonymous messaging app, we added in-product reporting features that allowed users to escalate concerns about inappropriate or bullying messages to the client's admin team. As we got deeper into the project and worked through the security and safety implications of anonymous communication, these reporting structures became one of the central design challenges. Making them visible enough to be found when needed, without making them so prominent that they created anxiety, required careful thinking.

The same project raised a tension between GDPR, which gives users the right to have their data removed, and the legal requirement to retain data in case of criminal investigation. We resolved this by implementing a data retention policy of around six months, so that even if a user deleted their account after sending harmful messages, the data would not be immediately wiped. That window meant that if police needed to open an investigation, the data would still be there, without ignoring GDPR obligations entirely.

Think about safety and reporting as part of your information architecture from the beginning. A reporting mechanism buried three levels deep is barely functional for a user in a calm moment and effectively inaccessible for a user in distress.

Embedding Accessibility from the Start, Not Retrofitting It

One of the clearest lessons from our work on the wellness genetics product is how expensive it is to add things late. We were brought in to improve the emotional layer of a product that had been built in a functional way that did not match its premium, wellness-focused brand. The product worked. It did not feel right. When we handed our designs to the development team, a third-party designer sat in between, and what was produced looked luxurious on screen but was very difficult for the developers to implement on top of their existing codebase. There was considerable back and forth before it landed correctly.

Applying a new interaction or emotional design layer on top of existing code is possible, but it requires careful management at every stage. The gap between what a design promises visually and what the underlying code can support is where rework accumulates. Accessibility works the same way. Building semantic structure, focus management, and contrast into a design from the first wireframe is straightforward. Retrofitting them into a finished product is slow, expensive, and prone to gaps.

Accessibility in the Design Brief

The most effective way to embed accessibility is to name it explicitly in the design brief. Not as a final checklist but as a constraint that shapes decisions from day one. What are the target WCAG conformance levels? Which assistive technologies should the product support? What user groups, beyond the primary target audience, need to be considered? Answering those questions at the brief stage means they inform everything that follows, rather than arriving as a surprise at the testing stage.

Testing with Real Users Across Abilities and Contexts

One of the clearest lessons from our work on the concierge app for a premium property development was about who you recruit for research. The target audience was high-net-worth individuals. We also brought in people from social housing, who would never be customers of the product. We brought them in because they had what we were trying to build into the product: a genuine sense of community, neighbourliness, and openness. High-net-worth residents in high-rise developments rarely know their neighbours. Social housing residents often do.

Recruiting outside your target audience surfaces qualities and behaviours that target users cannot articulate, because those qualities are not part of their experience. The social housing group gave us insight into community and communication that shaped the entire product direction. That same principle applies to accessibility testing. Users who navigate with assistive technology will find things that sighted, dexterous testers simply will not notice, because those things are invisible to someone who does not need to look for them.

Testing accessibility means testing with real assistive technology, with real users, under realistic conditions. Automated tools like axe or Lighthouse catch a portion of issues, perhaps 30 to 40 percent, but the rest only surface when a person with a screen reader or a motor difficulty actually tries to use the product. Both types of testing matter.

Platform Constraints and What They Mean for Accessible Design

Platform choice affects what accessible design is possible. iOS and Android both provide accessibility APIs, but they differ in how they work, what they expose, and how assistive technologies interact with them. A design decision that works well on one platform may need a different implementation on the other.

We experienced the real cost of platform constraints on the bootstrapped social football platform, where scope grew steadily and budget became critically strained. Midway through the project, we made the decision to pause Android development entirely and put all remaining budget into the iOS product. The client launched iOS-only, which addressed roughly half the potential market. The target audience skewed younger, and younger audiences disproportionately use Android, so the day-one adoption rate was significantly lower than it would have been with both platforms.

Post-launch, the client had to introduce advertising and abandon their subscription model because the user base was too small to make subscriptions viable. Platform decisions made mid-project, under budget pressure, had consequences that ran well beyond the launch date. From an accessibility perspective, launching on one platform means that any users whose assistive technology or platform preferences align with the other platform simply cannot use the product at all.

Native Components vs Custom Ones

Native platform components, the ones provided by iOS and Android directly, come with accessibility built in. Custom-built components do not. Every time a team builds a custom slider, a custom date picker, or a custom dropdown, they are taking on the responsibility of implementing all the accessibility behaviour that the native component would have provided automatically. This is not an argument against custom components, but it is an argument for understanding the cost and doing the work properly when you choose them.

Compliance as a Floor, Not a Ceiling

WCAG 2.1 AA is a useful standard. Meeting it means a product is broadly accessible to a meaningful range of users and provides a defensible baseline against legal challenge. In the US, the ADA applies to businesses with 15 or more employees, and accessibility failures have led to litigation across retail, travel, and hospitality sectors. Compliance matters.

A survey of 75 mobile developers found that 60% considered accessibility very important for mobile app development, while 39% cited personal ethics as a primary reason for implementing accessibility guidelines. That is the right instinct. The best accessible design comes from genuinely caring whether all your users can complete their goals, not from trying to stay out of legal trouble.

Compliance tells you the minimum. It does not tell you whether the experience is good. A product can meet every WCAG criterion and still be frustrating, confusing, or exhausting to use for someone with a cognitive difficulty or low technical confidence. The criterion checklist cannot capture that. Only real testing with real users can.

Compliance tells you the minimum standard. It does not tell you whether the experience is good.

The goal is a product that works well for the full range of people who will use it, across the full range of conditions in which they will use it. Compliance is the floor you build on, not the ceiling you reach for.

Conclusion

Accessible design is not a specialist sub-discipline you bring in at the end of a project. It is a way of thinking about who uses your product and what they actually need. The constraints it introduces, from generous touch targets to clear semantic structure to plain language, tend to make products better for everyone, not just the users who need them most.

Across the projects we have worked on, from the film industry document portal built for speed and clarity under pressure, to the anonymous messaging app where safety and reporting were as important as the core experience, accessibility has never been in tension with good design. The two pull in the same direction. Clarity helps everyone. Structure helps everyone. Predictability and generous spacing and visible focus states help everyone.

The work starts early, in the brief and the research phase, and it continues through testing with real users on real devices with real assistive technology. It does not end at launch. Platforms change, users change, and a product that was accessible at launch needs to be maintained that way.

• Name accessibility requirements in the brief, before design begins
• Test with automated tools and with real users who use assistive technology
• Use native platform components where possible and build accessible behaviour into custom ones
• Treat compliance as the starting point, not the finish line

If you are building a product and want to think through how accessibility fits into your design process from day one, let's talk about your app.

Frequently Asked Questions