Although scaling dynamic type is preferred whenever possible, there are cases as the navigation bars, the tab bars, the toolbars and the status bar where views have fixed height. The reason for assigning fixed height to these views is because otherwise they will take significant size of the screen and users will not be able to focus on the main content. In these cases we can use the Large Content Viewer to provide an accessible interface.
The Large Content Viewer works only when the text is assigned to one of large Accessibility text sizes.
Let’s try to create a tab view with two items, as follows
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
struct ContentView: View { var body: some View { TabView { Text("With System Image") .tabItem { Image(systemName: "figure.walk") Text("Walk") } Text("Without preserving vector data") .tabItem { Image("walk") Text("Walk") } //Photo by <a href="https://unsplash.com/@bernardhermant?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Bernard Hermant</a> on <a href="https://unsplash.com/s/photos/icon-black-and-white?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a> } } } |
That results to the below screen.
By using one of the larger Accessibility texts, by long tapping on top of the tab bar items we see the Large Content Viewer.
In the above example we notice that the first tab produces a great experience on the Large Content Viewer, but the second is not.
The reason why the second is bar item produces a bad experience is because the image asset is not a system image but a custom jpg image. In order to fix it we should provide a pdf asset and select to preserve the vector data. Alternatively if we are using UIKit or create a custom bar we can provide an alternative image and/or text for the Large Content Viewer. More details can be found on this WWDC video: https://developer.apple.com/videos/play/wwdc2019/261/
