A difference in accessibility snapshots was noticed when one of two side by side items changed from providing an outdented acessibilityPath to just using the default accessibilityFrame.
Further investigation found that the AccessibilityHierarchyParser has two potential issues with how elements are ordered in comparison with how VoiceOver works.
The ordering of elements is based on either the accessibilityPath (if not nil) or the accessibilityFrame. VoiceOver seems to always use the accessibilityFrame.
The vertical y comparison of elements uses a strict != comparison, whereas VoiceOver has about a ± 7 pt "roughly equal to" comparison.
This view controller shows some UILabels where one provides a custom accessibilityFrame, and another an accessibilityPath - each insets the view's frame by a different amount. Below is the VoiceOver focus order as seen by the Accessibility Inspector.
Header
"Lorem ipsum" label
"frame" label
"path" label
In the snapshot image, however the order is: Header, "path" label, "frame" label, then "Lorem ipsum" label.
A difference in accessibility snapshots was noticed when one of two side by side items changed from providing an outdented
acessibilityPathto just using the defaultaccessibilityFrame.Further investigation found that the
AccessibilityHierarchyParserhas two potential issues with how elements are ordered in comparison with how VoiceOver works.accessibilityPath(if notnil) or theaccessibilityFrame. VoiceOver seems to always use theaccessibilityFrame.accessibilityFrame, and another anaccessibilityPath- each insets the view's frame by a different amount. Below is the VoiceOver focus order as seen by the Accessibility Inspector.In the snapshot image, however the order is: Header, "path" label, "frame" label, then "Lorem ipsum" label.
Sample project: AccessibilityElementOrder.zip