I recommend running your app with Double-length Pseudolanguage. It is a great way to stress-testing your app and see how adaptive it is and if your UI will hold to other languages that might be a bit more verbose or even with larger text sizes.

Sometimes it won't be enough to make colors darker or lighter for Increase Contrast. As always, it is important to do some testing. The same colors might be used with different backgrounds or text colors and the contrast could actually get worse.

You can enable the possibility of providing assets for different appearances including light/dark modes and high contrast. As we've seen, that's valid for colors, but you can do the same for images too! https://x.com/dadederk/status/1594724075590619138?s=20&t=XJrlJiGSCTR9sJC7XPZPjA

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.

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 An app to help anyone learn VoiceOver's gestures in a very creative and playful way.

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.