Tips and tricks to build accessible iOS apps

#365DaysIOSAccessibility

RSS Feed

#365DaysIOSAccessibility

RSS Feed

A year-long journey exploring iOS accessibility, one day at a time. Each post shares practical insights, tips, and techniques to make your iOS apps more accessible.

If you use Color Sets in the Assets Catalog to define your color palette, make sure you enable variants for the Any, Light and Dark appearances and also High Contrast. You'll be able to define variations of the color that have better contrast.

I used to think of Zoom as an accessibility feature that didn't need support from developers. But actually, testing with Zoom might unveil some issues and bad practices. Watch out for buttons that change something far away on the screen. Using a snackbar is usually not a good idea. Especially if it lets you do/undo something. Because they're ephemeral, they're difficult to spot and/or reach with Zoom, VoiceOver, Switch, Keyboard... Confirming a destructive action with a dialog might be better.

Zoom lets the user magnify the screen if the user needs to zoom in a region to be able to see any details a bit closer. It is useful to know the gestures that let you zoom in, back out, move around the screen, adjust zoom level or show its menu.

While you are at @shelly's "36 Seconds That Changed Everything", I would definitely also check out the Bonus Content. Including the full interview with @marcoarment. "Awareness is the biggest problem here." https://www.36seconds.org/behind-the-scenes/ "Cause iOS 7 was so inaccessible in so many ways (...) it started getting under developers’ radars this section of settings, called accessibility, that changes the way my app looks or works and I need to make sure that it doesn’t break under those settings.” "There’s so much variation out there. We no longer have just one size phone, we no longer have just one font size. It is easier for us as developers not to fall into bad assumptions of how I see it is how everyone is going to see it.” "The good thing about VoiceOver is that the accessibility framework is pretty well built-in the standard controls. For a given app you can fix any VoiceOver problems it has in one day or less. Even if it is a complex app. Even if it has a lot of custom controls." "What developers now do, if they care, is they treat that (accessibility issues) as if it was any other design flaw. If any other screen in your app broke visually or functionally you’d consider that a bug and you would try to fix it in the next update.” "I think the more that we can do as a developer community to talk about these features even existing, and these problems existing, and to tell people how easy it is to fix. That is the best any of us can do to help. Awareness is the biggest problem here."

WWDC 2009's keynote, Phil Schiller spoke for 36 seconds, about how the iPhone was, two years later, finally accessible. @shelly tells this amazing story in her audio-documentary "36 Seconds That Changed Everything" https://www.36seconds.org/2019/06/19/36-seconds-transcript/ "Apple didn’t develop VoiceOver for Mac out of the goodness of their hearts. They developed VoiceOver for Mac because if they didn’t they were going to be in serious trouble with their key market, which was education," @JonathanMosen says. "They did that thinking a third party would write the screen reader for Mac OS 10, and then when really nobody picked up that mantle to write the screen reader as a third party, Apple stepped in and developed VoiceOver," @jamesdempsey says. "I borrowed a friend’s phone. It was confirmed. The screen was too small, the background too bright, the text too tiny. For the first time in 20 years, Apple had built a product I couldn’t use. I’m fairly sure I cried about that." @shelly Four minutes before the two-hour mark, in the midst of a long list of new apps to be included on the iPhone 3GS, @pschiller switched slides, revealing the iPhone Accessibility settings screen. “VoiceOver is on the iPhone. They did it.” "I bought myself an iPhone at the same time as other people. I didn’t have to wait for a new version of the software, an update to be made, or someone sighted to help me. I could start up VoiceOver and it just worked great." @SteveOfMaine

@JanJaapdeGroot presented the ScreenReader app for #GAAD2022. An app to help anyone learn VoiceOver's gestures in a very creative and playful way.

There are a ton of things to love about SwiftUI. But one of my favorites it's got to be the possibility of previewing Variants: the possibility of seeing your UI in dark/light modes, all dynamic type sizes, and orientations, side-by-side.

If you are using SwiftUI to build your apps, there is a fairly basic but very useful Accessibility Inspector built right there in the Inspectors Panel, on the right side of Xcode.

The Accessibility Inspector has a Notifications log that you can find in Window, in its top menu, and then Show Notifications. It shows accessibility-related notifications like layout changed, screen changed, or announcements... I learned about this feature from the Accessibility Inspector in this article by @basthomas. A very recommended read to learn all about the Verifying VoiceOver with the Accessibility Inspector. https://www.basbroek.nl/verifying-voiceover

The Accessibility Inspector can be used with your device. It is actually quite interesting to check what other apps (or iOS) configure, for some of the basic accessibility attributes (label, value, traits, hint...), in their UI components.

In addition to being able to test some accessibility options in the simulator using Environment Overrides. You can even preview some of these options before even running the app in the simulator with this Accessibility panel in Interface Builder.

If you use Interface Builder to build your app’s layout, there are some basic accessibility attributes that can be configured from there. They can be found in the Identity Inspector in the right-side panel in Xcode.

Accessibility Labels are not just for VoiceOver, and Accessibility User Input Labels are not just for Voice Control. The latter will also help Full Keyboard Access users to find elements on the screen by different names. Good API design!

Meet @jordibruin developer of Navi (and other great apps) and organizer of @swiftuiseries (with an accessibility category). Navi is sadly not available anymore but it was worth an Apple Design Awards nomination. It added subtitles to FaceTime!

@azzoor is the developer of the Braille Scanner It uses computer vision to locate the page and Machine Learning to match Braille to letters. You can see English letters above the braille, convert them to speech, copy and paste it... so cool!

Showing 46-60 of 230 posts

Special thanks to

Quintin Balsdon

for helping extract the content from the original Twitter posts.

Created in Swift with Ignite.

Supporting Swift for Swifts