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...
Too much data can overwhelm users. Very little is an incomplete experience. It is hard to find a balance on verbosity and the users may have different preferences. To help with this issue, the AXCustomContent APIs let you mark data as optional.
You can add an observer to listen for changes in the content size category, in case it is more convenient than overriding traitCollectionDidChange(_:).
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.
