A common example where you need to manually configure the button accessibility trait is for some table/collection view cells. These tend to be “buttons” that perform an action, like playing music, or bring the user to a different screen.
You may also find interesting...
Anything representing a heading in the app should have the header trait. It allows for a faster way of exploring a screen and jumping to the part of the app you are interested in. Screens should also start with a header.
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.
Hacks are accessibility’s worst enemy. An example. There is a ‘trick’ floating on the internet: if you want a button with an icon to the right of the text, set the semantic content attribute to force right to left. Great way to create focus traps.
