What am I missing here?
I have made many tests to try and understand this behaviour that drove me crazy.
My conclusion is that if you send a notification while VoiceOver is speaking a {label / hint / value}, your notification won't be taken into account : there may be a kind of preemption when the system needs to vocalize an attribute of a focused element.
That's only at the end of the vocalization that you can post as many notifications as you want to be well analyzed and interpreted as you wish.
The UIAccessibilitySpeechAttributeQueueAnnouncement
key is only useful with your own notifications when the system doesn't need to take over.
If you send many notifications and that the user flicks to focus a new element for instance, the notifications that weren't vocalized will be removed as soon as the system vocalizes the element's attributes.
In that case, if you catch the UIAccessibilityAnnouncementDidFinish
event, you will have a false value with the UIAccessibilityAnnouncementKeyWasSuccessful
key for the last vocalized notification (UIAccessibilityAnnouncementKeyStringValue
)... all the following ones will be ignored with no info given by the observer.
Conclusion : no personal notification is taken into account by VoiceOver when a new focused element or screen/layout changed notification occurs.
How can I queue multiple accessibility notifications for VoiceOver?
According to what's exposed above, I suggest to set up a kind of retry mechanism that would still send your notifications (x times) while they're not perfectly received after y seconds for instance.
That could be a tricky way to be more certain that the notifications are flawlessly received.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…