Low-Vision Mobile App Design Considerations

That "clean, minimal" form design you're proud of? Some of your users can't see it at all. Light gray borders on white backgrounds. Subtle focus indicators. Ghost buttons with barely-there outlines. These design choices look sleek to you, but they're completely invisible to people with low vision, color blindness, or anyone squinting at their phone in bright sunlight. WCAG 1.4.11 (Non-text Contrast) exists because if someone can't see where to click, focus, or type, your design isn't minimal - it's missing. This carousel breaks down what non-text contrast actually means, who it helps, and how to fix it without abandoning your aesthetic. #Accessibility #WCAG #WebDesign #UXDesign If you prefer your content as text, read on: Is your 'minimal design' actually invisible? What is WCAG 1.4.11? User interface components and graphical objects need enough contrast against their background. This includes: form inputs, buttons, focus indicators, icons, and charts and graphs. All should have at least a 3:1 contrast ratio. Why it matters This guideline helps people with low vision and color blindness who need stronger visual cues to identify what's interactive. Anyone using a screen in bright sunlight, working on a budget laptop with a dim display, or dealing with aging eyes benefits from better contrast. Common Mistakes • Barely-there borders on form fields (the #1 offender) • Subtle focus indicators that blend in • Ghost buttons with low contrast borders • Icons that almost match the background These patterns might look 'clean' to you, but they're invisible to some users. If people can't find where to click, focus, or type, your design isn't minimal - it's missing. What doesn't need 3:1 contrast? • Inactive or disabled components don't need 3:1 contrast • Decorative graphics and text get a pass, too. • Logos are exempt (but it's still preferable to ensure your logo can be seen by as many people as possible) Make your UI visible • Darken borders, outlines, and icon colors to at least 3:1 against the background • Ensure visual focus indicators have contrast against both the background and the element they're highlighting • Test in grayscale to catch issues your eyes might miss in color Testing • Use browser dev tools to check colors • Search the web for an accessible contrast checker • Test with real users, automated tools can miss issues • Remember to check different states: default, hover, focus, active The bottom line If sighted people can't see your UI, they can't use it. Non-text contrast is about making sure everyone can interact with what you build. Start with your most-used components. Fix forms, buttons, and focus states first. Learn more Want more clear and actionable WCAG breakdowns? Check out wcagInPlainEnglish.com

10 practical ways to improve content for blind & visually impaired users (and eventually everybody else) Tomorrow is World Braille Day, so I prepared this short list as a reminder of the small, practical things that can make digital content truly usable for blind and visually impaired people (and not only) and why they matter. 1️⃣ Use real text, not text in images Screen readers can’t read text baked into images. Real text allows people to navigate, search, resize, and read with Braille displays. WCAG 1.4.5 Images of Text: https://lnkd.in/eBjAVF24 W3C explanation: https://lnkd.in/eEktjnDP 2️⃣ Write meaningful alternative text Alt text explains why an image matters. Decorative images should be skipped, while informative ones should describe intent, not appearance. WCAG 1.1.1 Non-text Content: https://lnkd.in/eZjVn7Bk Alt text decision tree: https://lnkd.in/esHNeM5n 3️⃣ Use proper heading structure Headings are navigation landmarks for screen reader and Braille users. Skipping levels or styling text as headings breaks orientation. WCAG 1.3.1 Info and Relationships: https://lnkd.in/eBA6uevr W3C tutorial on headings: https://lnkd.in/eVStaN9b 4️⃣ Make links descriptive “Click here” gives no context when read aloud. Descriptive links help users understand destination instantly. WCAG 2.4.4 Link Purpose: https://lnkd.in/e5XYX37z Good vs bad link text: https://lnkd.in/e7SVpSJZ 5️⃣ Ensure sufficient color contrast Low contrast makes text unreadable for many users, especially with low vision or glare sensitivity. WCAG 1.4.3 Contrast (Minimum): https://lnkd.in/epFpS-BY Contrast checker explanation: https://lnkd.in/eKem_t9s 6️⃣ Never rely on color alone Instructions like “fields in red are required” exclude blind users. Always add text or icons. WCAG 1.4.1 Use of Color: https://lnkd.in/e79G-KEF How to make figures and presentations that are friendly to Colorblind people: https://lnkd.in/e4MhKpH4 7️⃣ Write clear, simple language Short sentences and plain words reduce cognitive load and improve comprehension with screen readers and Braille. WCAG 3.1.5 Reading Level: https://lnkd.in/ee9qSrup 8️⃣ Label form fields clearly Every input must have a programmatic label so users know what information is required. WCAG 3.3.2 Labels or Instructions: https://lnkd.in/eK-vCcdJ W3C example of accessible form errors: https://lnkd.in/eQkhadkM 9️⃣ Ensure full keyboard access Blind users often navigate via keyboard or Braille devices. If something can’t be reached or activated, it’s inaccessible. WCAG 2.1.1 Keyboard: https://lnkd.in/eS_AfM5K Keyboard accessibility tutorial: https://lnkd.in/em-G7K2Y 🔟 Test with screen readers You don’t need to be an expert. Just listening once reveals missing labels, broken structure, and confusing flows. WCAG: 4.1.2 Name, Role, Value: https://lnkd.in/emraZMZz #WorldBrailleDay #Accessibility #WebAccessibility #InclusiveDesign #A11y #DigitalInclusion #DisabilityInclusion #UXDesign #ContentDesign #EqualAccess

When I asked a visually impaired developer to review the accessibility of four popular iOS apps, he made a surprising discovery. All four were making the same big accessibility mistake… They built interactive elements without telling blind users what they are - or even that they exist at all. This was the finding of Diogo Melo, a mobile app developer who is himself blind, who I engaged at Welldone Consulting to undertake a research project to analyse the accessibility of four popular UK not-for-profit apps. For each of the four, he found that custom-built buttons and interactive components were never assigned the correct accessibility trait (iOS accessibility specialist Rob W. has also previously written about how critical these are!). Why is this a problem? To a sighted user, a button can be made to look like a button with the help of graphic design. That type of visual motif doesn’t benefit a visually impaired user. It’s vital that instead, accessibility software like Apple’s VoiceOver is given the necessary context to indicate an interactive element accurately. Without it, visually impaired users don’t know a button is there, and aren’t able to interact with it. In my last post on this research I mentioned a terms and conditions tickbox at the outset of using an app, which Diogo was unable to interact with. This was an example of a missing accessibility trait. But the problems stretch deeper across all four apps - with accessibility traits missing from… - Donation method options - Text fields (meaning they can’t be completed) - Buy buttons - Back buttons (a significant barrier to basic navigation) - Event listings …and many more. What’s intriguing is that in principle, the fix here is simple - assign the correct trait. Yet all four apps are missing these. It’s a must that they’re implemented. Without it, the work done throughout the rest of the app to optimise for accessibility is wasted. For me, it points to a systemic gap in how accessibility is considered during development. So often that gap presents as a lack of consistency. For accessibility optimisation to be effective, consistency is key. When the consistency isn’t there, any good work that might have been performed to make an app accessible is so quickly undone. But when it is, a rising tide raises all ships - a clearer, more flexible design that improves the experience for everyone. . . . Image alt text: Two smartphone screens are shown side by side. On the left hand side smartphone screen, large text reads ‘What sighted users see’. Underneath this text is: 1) A turqoise-coloured button with text reading ‘Donate now’ 2) A white text entry field with light grey text reading ‘Enter email address’ 3) A smaller dark blue coloured button with text reading ‘Sign up’ On the right hand side smartphone screen, large text reads ‘What a blind user’s screen reader hears’. Underneath this text are four small grey buttons, each with a question mark overlaid. 

1 in 12 people live with low vision Most products ignore them Designing for low vision users is not optional anymore… That’s lost users Lost trust Lost revenue What to DO: • Use high color contrast + readable font sizes → Make content easy to read instantly • Keep all information on the page → Reduce friction, improve access • Use color + text + shapes together → Don’t rely on one signal • Follow a clear, linear layout → Works better for zoom and navigation • Keep actions in context → Make interactions obvious What to AVOID: • Low contrast and small text → Hard to read = drop-off • Hiding information in downloads → Adds unnecessary effort • Using only color to communicate → Not accessible for all users • Scattered layouts → Breaks flow and focus • Separating actions from content → Creates confusion Accessible design = better UX = better conversion You’re not designing for some users You’re designing for everyone