One of my favourite Dynamic Type tricks is to use Stack Views and flip the axis from horizontal to vertical given a certain content-size-category threshold. So effortless and it works so well in so many scenarios.

Sometimes, with large font sizes, there's no other way around it but to offer an alternative layout. Small tweaks are often enough. Otherwise, the text will be barely readable. Larger text shouldn't mean less content or a worse experience. One thing you can do is to check if the preferred content size category of a view is an accessibility category. And, in that case, move things around to make room for the text, offer more lines of text, etc. https://developer.apple.com/documentation/uikit/uicontentsizecategory/isaccessibilitycategory

It is possible to use custom fonts and for them to still work great with Dynamic Type. You need to define the default size and use UIFontMetrics to get the scaled font for each one of the styles you'd like to use. https://developer.apple.com/documentation/uikit/uifontmetrics/scaledfont(for:)

I wish the adjustsFontForContentSizeCategory was true by default. Instead, you need to configure it that way so elements adjust their font size as the content size category (dynamic type) changes when a preferred font is used for a given style.

When working with Dynamic Type, I find it useful to remember that sizes for the different text styles won't scale linearly, nor will they do proportionally between them. For larger dynamic type sizes, styles will come closer together in size.

Dynamic Type is a feature that lets a user change the font size (smaller or larger) of the whole system or a particular app. To support it, choose a preferred font based on one of the 11 supported text styles: Large title, heading, body...

Grouping elements with .accessibility(children: .combine) doesn't always generate the best accessibility label. Comma-separating labels might sometimes not be ideal. But you can improve it by tweaking the labels/grouping of its children first.

Apple asks us to consider the combine behavior, before using ignore, for .accessibilityElement(children: ). And for good reason, if combine works, and later on you decide to change the UI, the accessibility attributes will be updated for you.

If you want to know everything about how to "Tailor the VoiceOver experience in your data-rich apps" with the Accessibility Custom Content API, there is a WWDC21 session. https://developer.apple.com/videos/play/wwdc2021/10121/ When implementing accessibilityCustomContent, for any supplementary information, it returns an array that VoiceOver will announce in that given order. The value of the AXCustomContent first, then the label. Users can configure in VoiceOver's verbosity settings if it should say that there's more content available, or play a sound hinting that there is, or simply do nothing. So it should really be optional content as users might miss it.

When creating AXCustomContent objects for accessibilityCustomContent, you can specify the importance of the data. If it is high, it will always be presented by VoiceOver. You could potentially ask the user if that data is of importance to them.

When making charts accessible, sometimes you may have just too many data points for the user to have to go one by one through all of them. In those cases, you can create accessibility elements that represent meaningful chunks of the graph.

Some good practices when it comes to charts and data visualizations: use high contrast colors, avoid problematic pairings (red-green, blue-yellow), use symbols as well as colors...