--- title: What happens when accessibility conflicts with my app design description: Accessibility conflicts in app design often stem from leaving it too late. Discover how to resolve the tension and build accessibility in from the start. image: https://weareaffective.com/hubfs/learning-centre-images/what-happens-when-accessibility-conflicts-with-my-app-design.webp --- [Skip to content](https://weareaffective.com/learning-centre/what-happens-when-accessibility-conflicts-with-my-app-design#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 # What happens when accessibility conflicts with my app design Table of Contents Designers who care about their work feel the tension the moment someone raises accessibility. The brand palette is specific, the typography is deliberate, and the layout does something particular. Then a requirement arrives, increase the contrast ratio, make the touch targets larger, support dynamic text sizes, and the first instinct is to worry about what gets lost. That instinct is understandable. It is also usually wrong, or at least misdirected. > Accessibility treated as a late-stage constraint creates the very tension that early integration avoids. The conflict between accessibility and design is real in some situations and imagined in many others. The imagined version tends to arrive when accessibility is treated as an external constraint imposed on a finished design, rather than as a set of conditions the design should have been built around from the start. We have seen both versions, and the distinction matters because the solutions are different. On a document portal we [built for the film industry](https://weareaffective.com/learning-centre/what-film-industry-document-portal-users-taught-us-about-designing-for-people-wh), the brief required that the product serve many different types of users, all working under time pressure on set. Accessibility was not a compliance note tacked onto the end of the project. It shaped the entire design approach from day one: large-scale layouts, clear navigation, and an architecture built entirely around getting to information as fast as possible. The result was a better product for every user, not a compromised one. ## What the conflict actually looks like in practice When designers describe an accessibility conflict, they are usually describing one of three specific situations. The brand colour palette does not meet the WCAG 2.1 minimum contrast ratio of 4.5:1 for body text. The touch targets are smaller than the recommended minimum. Or the layout breaks when a user increases their text size, because the design was built on fixed rather than relative units. Each of these is a genuine constraint. None of them is unsolvable, and none of them necessarily requires abandoning the design intent. A contrast ratio can fail on one combination of colours and pass on another within the same palette. Touch targets can be enlarged without changing the visual weight of an element. Text that reflows cleanly requires relative units, which is a structural decision rather than an aesthetic one. #### Where the real friction sits The actual difficulty is usually that the design was completed before accessibility was tested. A palette is signed off, a visual language is established, a prototype is built. At that point, any change feels like a disruption to something settled, because it is. The conflict people describe as aesthetic is frequently just the discomfort of rework, and rework that could have been avoided if the accessibility conditions had been part of the design brief from the start. ## Why accessibility gets treated as a visual constraint Accessibility arrives late in most projects because it is framed as a technical requirement rather than a design condition. The reasoning runs something like this: get the design right first, then check it passes the technical tests. The problem is that by the time checking happens, the decisions that would have been easy to make differently at the start are now expensive to change. This pattern mirrors something we notice across many types of design work. [Emotional considerations, user psychology, behavioural design](https://weareaffective.com/learning-centre/what-a-development-team-actually-needs-to-know-about-the-user-before-sprint-one), these also tend to arrive late, added onto a product that was built around function first. When they arrive late, they look like embellishments rather than structure. Accessibility has the same problem. It gets treated as a layer applied on top, rather than as one of the conditions the design was built to satisfy. There is also a cultural dimension. Design teams value craft and intentionality, and a requirement that feels like it overrides those values reads as a threat. Contrast requirements can feel like a restriction on colour freedom. Touch target sizes can feel like they undermine visual precision. These feelings are real, even when the underlying assumption, that accessibility and good design pull in opposite directions, does not hold. According to a survey reported by [Springer's Empirical Software Engineering journal](https://link.springer.com/article/10.1007/s10664-022-10182-x), 39% of developers cited personal ethics as their primary reason for implementing accessibility guidelines, more than any other factor, and 60% rated it as very important. The intention is there. The process often is not. ## 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 ## The real cost of introducing accessibility late On a dating app project focused on verified profiles and preventing bots, the client chose to skip discovery for the messaging component and concentrate resources on onboarding. The onboarding was rigorous and well-considered. The messaging feature was built generically, and that generic build allowed the automated and fake messages that the onboarding process had been designed to stop. The mismatch between two parts of the same product meant the messaging section had to be rewritten entirely, at a cost of approximately £15,000 in additional budget and two months of extra work. That was not an accessibility story, but the structural failure is identical. [A decision made early in one part](https://weareaffective.com/learning-centre/how-to-write-a-product-hypothesis-a-development-team-can-actually-test-against) of a product, to skip a thorough review, created expensive consequences downstream. Accessibility works the same way. A contrast decision made at brand level, a layout decision made without considering dynamic text, a touch target decision made on desktop, all of them become harder and more expensive to fix the later they are caught. > A decision made early in one part of a product creates expensive consequences when it reaches the parts it was never tested against. According to [PCloudy via UXPin](https://www.uxpin.com/studio/blog/checklist-for-manual-testing-of-react-components/), over 60% of accessibility issues are caught through manual testing rather than automated tools. That means automated checks alone, the kind that are quick to run at the end of a project, miss the majority of real problems. The issues that automated tools catch are the easy ones. The rest require deliberate, human review, which takes longer and finds problems that are far more costly to fix at that stage. Run an accessibility audit before a design is signed off, not after. Catching a contrast failure at brief stage takes minutes. Catching it after visual design is complete costs hours. Catching it after development is complete can cost weeks. ## When accessibility improves the design rather than fighting it The film industry document portal is the clearest example we can point to of accessibility improving a product rather than constraining it. The decision to make the design large-scale, easy to navigate, and focused entirely on speed of access was driven by the need to serve a diverse user base under pressure. The result was also, straightforwardly, a better-designed product. Clear hierarchy, generous spacing, and fast navigation are good design principles regardless of whether accessibility is the reason they are applied. This is not an unusual outcome. Many of the conditions that accessibility standards push for, sufficient contrast, adequate text size, clear focus states, logical reading order, are the same conditions that make a design easier to use for everyone. A contrast ratio that passes at 4.5:1 is also a contrast ratio that works in sunlight, on older screens, and for users who are tired. A touch target that is large enough for a user with limited motor control is also a touch target that is easier to hit when someone is using their phone on a moving train. #### Accessibility as structural thinking The deeper benefit is that [app UX design](https://weareaffective.com/app-ux-design) for accessibility requires you to think structurally about your product rather than only visually. Ensuring content reflows cleanly when text size increases means understanding how your layout actually works, not just how it looks at one size on one device. That structural clarity tends to produce more robust designs, ones that hold up under conditions the designer did not originally anticipate. Test your design at 200% text size early in the process. If the layout breaks or content disappears, the structure needs attention before the aesthetics do. ## Where the tension is genuine and how to resolve it There are situations where the tension is real and the resolution requires an actual trade-off. Brand palettes built around soft, low-contrast tones, common in [wellness, beauty, and premium lifestyle products](https://weareaffective.com/learning-centre/why-a-charity-reorder-flow-should-feel-different-from-a-beauty-reorder-flow), can genuinely conflict with contrast requirements for body text. A design language built around very small, refined typography can conflict with legibility requirements. These are not imaginary problems. The most useful approach is to separate the brand expression from the functional text. A brand can use its full palette, including low-contrast combinations, in decorative contexts, logotypes, and large-scale visual elements, all of which are exempt from the 4.5:1 requirement under WCAG 2.1. The constraint applies to text that users need to read and act on. Keeping the brand expressive at a visual level while ensuring functional text meets contrast requirements resolves most of the genuine tension without requiring a palette overhaul. About 12% of men worldwide have colour-deficient vision, according to [Colour Blind Awareness](https://www.colourblindawareness.org/colour-blindness/). A product that relies on colour alone to communicate state, error states, selection states, progress, excludes a significant portion of its audience. Adding shape, label, or position as a secondary signal alongside colour resolves this without changing the colour at all. #### Making trade-offs visible Where a genuine trade-off exists, [the decision should be made explicitly](https://weareaffective.com/learning-centre/how-to-tell-whether-your-digital-problem-is-a-format-problem-or-a-brief-problem), with the implications understood on both sides. A table helps here. | Situation | Accessible option | Brand impact | User impact | | --- | --- | --- | --- | | Low-contrast body text | Darken text or lighten background | Minimal if colour stays in palette | Legible for all users | | Colour-only error states | Add icon or label | None | Clear for colour-blind users | | Small touch targets | Increase hit area (not visual size) | None | Easier for all users | | Fixed-unit text layouts | Switch to relative units | None | Supports user text preferences | ## How to build accessibility in from the start The film industry portal worked because accessibility was a design condition from the start, not a test run at the end. That is the structural shift that resolves most of the tension people experience: treating accessibility as part of the brief rather than a review criterion applied to a finished design. In practice, this means a few specific things. Contrast ratios get checked as the colour palette is being built, not after it is signed off. Touch target sizes are defined in the design system alongside other component standards. [Text scaling is tested during prototyping](https://weareaffective.com/learning-centre/what-should-your-app-prototype-test-before-full-build), not after development. Focus states are designed as part of the interaction language, not added later as an afterthought. Define your accessible colour combinations during brand and palette work, before any screens are designed. This makes contrast a design decision rather than a compliance fix. 1. Check contrast ratios as the palette is developed, using the 4.5:1 threshold for body text and 3:1 for large text as design targets rather than pass/fail tests. 2. Include touch target minimums in your component specification alongside visual dimensions. 3. Test at varied text sizes during prototyping, not just at your default, to catch layout failures before development. 4. Design focus states as part of your interaction language, giving them the same visual care as hover and active states. 5. Use labels and shapes alongside colour to communicate state, so no information is carried by colour alone. This approach also changes how teams talk about accessibility. When it is part of the brief, it is part of the design conversation. When it arrives late as a compliance check, it is experienced as external pressure on something already complete, which is where the tension and the resentment come from. ## Conclusion The conflict between accessibility and design is largely a process problem dressed up as an aesthetic one. When accessibility arrives late, after a palette is settled and a layout is built, it creates real disruption, and that disruption feels like the two things are inherently at odds. The film industry portal showed the other version: accessibility as a design condition from the start, producing a product that was clearer, faster, and more usable for everyone who touched it. The genuine tensions, soft brand palettes, refined typography, colour-only states, have workable resolutions that do not require abandoning the design intent. They require understanding where the WCAG requirements apply (functional text, interactive elements) and where they do not (decorative elements, logotypes), and making deliberate decisions about each. What the dating app messaging rewrite made plain is that skipping a thorough process in one part of a product creates costs that land later and harder. Accessibility works the same way. The £15,000 and two months lost on that project came from a decision that felt like it was saving time. Accessibility caught at brief stage costs a conversation. Caught after development, it can cost a rebuild. If your product is carrying accessibility as a review item rather than a design condition, the time to change that is before the next brief is signed off. [Let's talk about your design process](https://weareaffective.com/get-started). ## Frequently Asked Questions Why do designers often see accessibility as a threat to their work? Accessibility tends to arrive late in the design process, framed as a technical requirement rather than a core design condition. By that point, any change feels disruptive because decisions have already been settled, so the friction people describe as aesthetic is often just the discomfort of rework. Is the conflict between accessibility and good design always real? In many cases the conflict is imagined rather than genuine, arising when accessibility is treated as an external constraint imposed on a finished design. When accessibility conditions are built into the brief from the start, the tension largely disappears. What are the most common accessibility problems designers encounter? The three most frequent issues are brand colour palettes that fail the WCAG 2.1 minimum contrast ratio of 4.5:1 for body text, touch targets that are too small, and layouts that break when a user increases their text size. Each of these is a genuine constraint, but none of them requires abandoning the original design intent. Can I keep my brand colours and still meet contrast requirements? Yes, in most cases. A contrast ratio can fail on one combination of colours within a palette and pass on another, so the solution is often about which colours are paired together rather than replacing the palette entirely. Testing colour combinations early gives you far more room to manoeuvre. How do I make touch targets larger without changing how my design looks? Touch targets can be enlarged without altering the visual weight or appearance of an element, because the interactive area and the visible element do not have to be identical in size. This is a structural decision that can be made during build without touching the visual design. What does it mean to build a layout that supports dynamic text sizes? It means using relative units rather than fixed ones, so that text and surrounding elements scale proportionally when a user adjusts their preferred text size. This is a foundational structural decision that is straightforward to make early but costly to retrofit once a design is built. When should accessibility be introduced into a project? Accessibility should be part of the design brief from day one, not a compliance check at the end. Introducing it early means the conditions that shape accessible design, contrast, scale, layout flexibility, inform decisions while they are still easy and inexpensive to make. Can designing for accessibility actually improve a product for all users? Yes, and the film industry document portal described in the article is a clear example. Designing around accessibility from the start produced large-scale layouts, clear navigation, and fast access to information, all of which made the product better for every user, not just those with specific access needs. ## Related Articles [![What Design Patterns Should You Avoid in Wearable Applications?](https://weareaffective.com/hubfs/learning-centre-images/what-design-patterns-should-you-avoid-in-wearable-applications-featured.webp)](https://weareaffective.com/learning-centre/what-design-patterns-should-you-avoid-in-wearable-applications) ### [What Design Patterns Should You Avoid in Wearable Applications?](https://weareaffective.com/learning-centre/what-design-patterns-should-you-avoid-in-wearable-applications) Wearable apps are failing left and right, and it's not because the technology isn't ready—it's... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![What Are the Core Principles of User-Centred Design?](https://weareaffective.com/hubfs/learning-centre-images/what-are-the-core-principles-of-user-centred-design-featured.webp)](https://weareaffective.com/learning-centre/what-are-the-core-principles-of-user-centred-design) ### [What Are the Core Principles of User-Centred Design?](https://weareaffective.com/learning-centre/what-are-the-core-principles-of-user-centred-design) A mental wellness app launches with beautiful visuals and advanced tracking features. Users... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![What Accessibility Features Do Gaming Apps Need Most?](https://weareaffective.com/hubfs/learning-centre-images/what-accessibility-features-do-gaming-apps-need-most.webp)](https://weareaffective.com/learning-centre/what-accessibility-features-do-gaming-apps-need-most) ### [What Accessibility Features Do Gaming Apps Need Most?](https://weareaffective.com/learning-centre/what-accessibility-features-do-gaming-apps-need-most) About 15% of the world's population lives with some form of disability, which means roughly 430... 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.