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."

@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!

It is not just about applying accessibility APIs, but about caring, and thinking of features that can make your app more accessible and inclusive to everyone. Twitter's alt-text feature is a great example. Thanks, @TwitterA11y! You'll be missed.

You can add your Accessibility Shortcuts to Control Centre too. One more quick access point and one more reminder to get you testing often and quickly. How to enable Accessibility shortcuts: https://x.com/dadederk/status/1583519154165800960?s=61&t=_fK9Muzu2MyFEeJLVQZcJg

Manual testing is crucial. And therefore, reducing friction to let you start your testing process can be a huge help. Selecting some accessibility shortcuts will do that, putting most of iOS' accessibility features at a triple-click of a button.

UINotificationFeedbackGenerator has a “success” feedback type. Consider using it when a task was performed successfully together with any other visuals or sound. The use of multiple modes just makes it easier for everyone to understand your app.

Today I have a question for you: which books have helped you level up your accessibility game? I'll start: *Developing Inclusive Mobile Apps* by Rob Whitaker (@RobW). It is not just iOS—you also learn about Android, inclusive design, and WCAG.

Check isReduceTransparencyEnabled to lower transparency. A great example is Spotlight. Not only transparency is removed but it keeps the main color of the background, it feels personalized and contextual but reduces noise and improves contrast.

Today I want to share something I use a lot. You can convert any article into a “podcast” by enabling Speak Screen in Accessibility Settings, switching to Safari’s Reader Mode and swiping down with two fingers from the top of the screen. I think it is a good example of how if we all knew more about how to use the assistive tech available in iOS, we would find ourselves using more of them, more often, exemplifying quite well that accessibility benefits everyone.

You should convey important information in multiple modes, not just color. If you are still required to do so, at the very least you should complement that info with other modes, like symbols, if the user requested differentiation without color.

All the accessibility capabilities you can check for, have counterpart notification names you can observe in case the user changes its preferences while using your app. https://x.com/dadederk/status/1577435144129892352

You can add an observer to listen for changes in the content size category, in case it is more convenient than overriding traitCollectionDidChange(_:).