You don't have to offer an alternative layout just for the accessibility category. You can actually compare content size categories. So you could tweak the UI already for anything equal to or larger than .extraExtraLarge, for example.

Apple Music app example. It shows how for the extra extra extra large size, it still shows the default layout but text is starting to wrap up way too early. It also shows the AX1 size, and how from there, the rows for the tracks allow more than one line of text for the labels. And it also shows it for the AX3 size, where the layout changes a bit more, moving the cover art so it comes before the text and not next to it, allowing more space for the text. The code compares the preferred content size category and if it is equal or more than accessibility medium, it allows for more lines of text, if it is more or equal than accessibility extra large, it changes the layout, else, it uses the default layout.

You may also find interesting...

When implementing a UISlider, it is a good idea to consider how much the slider value should change when swiping up/down to adjust it. It might not always make sense to do it in 10% increments, which is the default behaviour. Could be because the value at those intervals doesn't make sense, or feel random, or because it wouldn't provide the user with a fine enough control being able to go through the whole slider in just 10 swipes. It user will still be able to adjust the slider to any value by double tapping and holding and then moving the finger left or right, bypassing VoiceOver gestures. VoiceOver announces the new value as it changes.

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

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.

Created in Swift with Ignite.

Supporting Swift for Swifts