Have you ever seen VoiceOver randomly focusing on elements of the previous view when presenting a custom modal view? That can be fixed by letting the system know that the presented view is modal in terms of accessibility.

If you have interactions that are hidden or require complex gestures to be performed or that may conflict with VoiceOver, you need to provide alternative ways of executing these actions. Custom actions can help a lot of times, but not always.

If a view has isAccessibilityElement to true, assistive tech won't look for any of its subviews. That means that if there are any buttons inside, they won't be accessible. You can add custom actions to that element though.

Grouping elements when it makes sense can make a huge impact on easing navigation with some assistive technologies like VoiceOver, Switch Control, or Full Keyboard Access. It also helps on reducing redundancy.

Images should either be decorative or have a proper accessibility label or alt text that describes them. If they're decorative you can make it so they get skipped by assistive tech so it doesn't get in the way of the experience.

Some recommendations for improving your accessibility labels: don't add the element type, avoid redundancy and verbosity, localize... @MobileA11y has an excellent blog post on it: https://mobilea11y.com/blog/writing-great-labels/ @jordyn2493 has a great video too: https://developer.apple.com/videos/play/wwdc2019/254/

One of the accessibility issues I see more often in iOS apps, believe it or not, is unlabelled elements. This happens especially for buttons with an icon but no title. In those cases, you need to configure an accessibility label manually.

Once you learn some basic gestures with VoiceOver, it is very important to master he Rotor. It is very useful to also know some more power user gestures like the Magic Tap or the Escape gesture.

When using VoiceOver on a device without a home button it can first be confusing how you can do a few things, including going to Home from an app, or opening the App Switcher, Control Center, or Notifications. Here's a quick guide for you.

Let's quickly remember a few of VoiceOver's most important gestures that will let you do some of the most basic actions including selection, interacting, navigating, and scrolling. And Apple has a great video: https://m.youtube.com/watch?v=qDm7GiKra28&feature=youtu.be

The most straightforward way for making sure your colors work well in all appearances (dark, light, increase contrast, and all the combinations) is to use the provided system colors. Check the background and label semantic colors too. All the info in the Color section of Apple’s Human Interface Guidelines: https://developer.apple.com/design/human-interface-guidelines/color

If you don't use Color Sets in your Asset Catalog, and you define your color palette in code, you can still check if the user has Increase Contrast enabled to offer a slightly different color that improves the contrast ratio even more. Day 192 (2/2). You can check if the darker system colors is enabled: https://developer.apple.com/documentation/uikit/uiaccessibility/isdarkersystemcolorsenabled Listen to a notification in case this setting changes: https://developer.apple.com/documentation/uikit/uiaccessibility/darkersystemcolorsstatusdidchangenotification And also check if the accessibility contrast is high in your trait collection: https://developer.apple.com/documentation/uikit/uitraitcollection/accessibilitycontrast