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...
Sometimes we may fail to convey to the user of things changing on the screen in a perceivable way. Toasts and similar should be announced. We may want to make clear that some content on the screen changed. Or we might want to update on progress.
Support both orientations, if possible. I know not even iOS itself does it, but it hasn't always been like that. You'll create a more robust UI that will be easier to port to iPadOS. And especially, don't force your users to rotate their devices.
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.
Content © Daniel Devesa Derksen-Staats on Accessibility up to 11! is licensed under CC BY 4.0. License details
