Most teams treat accessibility as a checklist. Tick some boxes, pass an audit, move on. The app technically complies, but it doesn't actually work well for the people it's supposed to help.
That approach misses the point. Accessibility isn't a compliance exercise - it's a design philosophy that, when done properly, makes your app better for every single user. This guide covers what genuine accessibility looks like, why it matters for your business, and how to build it into your product from day one.
The Business Case You're Probably Ignoring
Over one billion people worldwide live with some form of disability. In South Africa, approximately 7.5% of the population has a disability. That's not a niche audience - it's a market segment larger than most companies' entire user base.
But the numbers only tell part of the story. Accessible design benefits everyone. Captions help users in noisy environments. High contrast helps users in bright sunlight. Voice control helps users whose hands are occupied. Large touch targets help users on a bumpy taxi ride. When you design for the extremes, you improve the experience for the middle.
Companies that prioritise accessibility consistently report higher user satisfaction, longer session times, and better retention across their entire user base - not just among users with disabilities. It's also increasingly a legal consideration. South Africa's Promotion of Equality and Prevention of Unfair Discrimination Act and global standards like the European Accessibility Act mean that inaccessible digital products carry real legal and reputational risk.
Screen Reader Support That Actually Works
Screen readers translate visual interfaces into spoken descriptions. For your app to work with them, every interactive element needs a meaningful label. Images need alt text. Decorative elements should be hidden from the accessibility tree.
In Flutter, the Semantics widget is your primary tool. Label buttons with their action - "Submit order", "Add to basket", "Go back" - not their appearance. "Blue button" or "Icon" tells a screen reader user nothing useful.
Group related elements so screen readers present them as logical units. A product card with an image, title, price, and "Add to basket" button should be announced as a single coherent item, not four disconnected elements. Use MergeSemantics and ExcludeSemantics to control how Flutter's accessibility tree represents your UI.
Test the navigation order carefully. Screen readers move through elements sequentially, and if your visual layout doesn't match the logical reading order, users get lost. Flutter generally handles this well, but custom layouts and positioned widgets can break the expected flow.
Colour, Contrast, and Colour Independence
WCAG 2.1 requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text. These aren't arbitrary numbers - they're the threshold at which text becomes reliably readable for users with low vision.
But contrast is only half the equation. Approximately 8% of men and 0.5% of women have some form of colour vision deficiency. If your app uses a red/green colour scheme to indicate error and success states, roughly one in twelve male users can't distinguish between them.
The fix is straightforward: never rely on colour alone to convey information. Pair colour with icons, patterns, or text labels. A form field with an error should show a red border, an error icon, and a text message - not just a colour change. A status indicator should use shape or text alongside colour coding.
A useful exercise: view your designs in greyscale. If the interface is still usable without colour, you've built a solid foundation.
Touch Targets and Motor Accessibility
Interactive elements need sufficient size for users with motor impairments, tremors, or limited dexterity. Apple's Human Interface Guidelines recommend 44×44 points minimum. Google's Material Design specifies 48×48 dp. We follow the larger of the two.
Size isn't enough on its own. Space targets apart to prevent accidental activation. A row of tightly packed icons might look clean, but it's unusable for someone with limited fine motor control. Provide at least 8dp of non-interactive space between interactive elements.
Consider alternative interaction methods too. Swipe gestures should have button alternatives. Drag-and-drop should have a tap-based fallback. Complex gestures like pinch-to-zoom should include on-screen controls. Every gesture-based interaction in your app should be completable through simple taps.
Typography That Adapts
Support dynamic type sizes. Users who increase their system font size have done so for a reason - your app must respect that preference. In Flutter, use MediaQuery.textScaleFactor to scale text appropriately and test your layouts at 200% text size.
Fixed-height containers are the enemy of accessible typography. When text scales up, it needs room to grow. Use flexible layouts that expand to accommodate larger text rather than clipping or overflowing. A container that looks perfect at default size but truncates text at 150% scale has failed.
Choose readable fonts at reasonable base sizes. Body text below 14sp is difficult for many users. A line height of 1.5 improves readability for users with dyslexia and cognitive disabilities. Avoid fully justified text - the uneven word spacing creates visual noise that impairs reading for neurodivergent users.
Keep line lengths between 50 and 75 characters. Text that stretches across the full width of a tablet screen forces excessive eye movement that fatigues readers quickly, especially those with cognitive or visual impairments.
Motion and Animation
Animation adds delight to an interface - unless it triggers nausea, dizziness, or seizures. Vestibular disorders affect a significant number of adults, and excessive parallax scrolling, zoom transitions, and spinning animations can make your app physically uncomfortable to use.
Respect the system's "reduce motion" setting. In Flutter, check MediaQuery.of(context).disableAnimations and provide static alternatives when the user has requested reduced motion. This doesn't mean removing all animation - subtle opacity fades and gentle position changes are generally safe. It means eliminating large-scale movement, parallax effects, and auto-playing animated content.
Never use flashing content. More than three flashes per second can trigger photosensitive seizures. This isn't a guideline - it's a safety requirement.
Cognitive Accessibility
Accessibility isn't limited to sensory and motor disabilities. Cognitive accessibility - designing for users with learning disabilities, ADHD, anxiety, or autism - is equally important and often the most overlooked category.
Use clear, simple language. Break complex processes into smaller steps with visible progress indicators. Provide confirmation dialogs before destructive actions. Allow users to undo mistakes easily. Avoid time limits where possible, and when they're necessary, warn users before time expires and allow extensions.
Consistent navigation patterns reduce cognitive load dramatically. If your settings icon is in the top-right corner on one screen, it should be in the top-right corner on every screen. If "Back" is a swipe gesture on one page, it should be a swipe gesture everywhere. Predictability isn't boring - it's accessible.
Minimise distractions. Auto-playing videos, pop-ups, and persistent notification badges create sensory overload for many users. Let users control what demands their attention.
Testing With Real Users
Automated accessibility testing tools catch roughly 30% of issues. They'll flag missing alt text and insufficient contrast ratios, but they can't tell you whether your screen reader labels make sense in context or whether your navigation flow is logical.
Enable TalkBack on Android or VoiceOver on iOS and try to complete every core task in your app using only the screen reader. This exercise is humbling - it reveals problems that no automated tool will catch. Try it with your eyes closed for ten minutes. The experience will change how you think about interface design.
Most importantly, include users with disabilities in your testing process. Their lived experience catches problems that simulated testing cannot. Budget for accessibility-focused user testing the same way you budget for any other quality assurance work - it's not optional, it's essential.
Building It In, Not Bolting It On
At Masterpiece Designs, accessibility isn't a phase we add at the end of a project. It's considered from the first wireframe and validated at every milestone. We've seen it firsthand: building accessibility in from the start adds a small amount to the initial budget. Retrofitting it later costs significantly more - and the result is never as good.
The goal isn't to pass an audit. The goal is an app that works for everyone who wants to use it. When you approach accessibility as a design value rather than a compliance requirement, you build better products. Not just for the billion people with disabilities - for all your users.