On Feb 28, 2014, at 7:02 AM, Josh Scotland <
email@hidden> wrote:
Hey Boris,
2. observation “1.” does not hold if the view is a NSTextField, no matter if editable, or as a static label, or an NSButton. (I verified “1.” holds when the view is a custom NSView subclass, or when the view is a NSProgressIndicator. Besides these 4 NSView subclasses, I did not try any others)
Have you tried posting the AX notification from the control’s cell? For elements which subclass NSControl (e.g. NSTextField and NSButton), the accessibility is handled on the cell.
thanks, that did it and now announcements are spoken! But it’s not there quite yet for this use case:
when there is text in the text field and the cursor is at the end of it, when the arrow down is pressed, first some “end of text reached” sound is played and the whole text in the text field is read, and only after then is the announcement spoken.
This does not happen for arrow up - only the announcement is spoken then.
The same happens when cursor is at the beginning of text and the user presses arrow up (sound, whole text read, then announcement spoken). In this case, it does not happen for arrow down - only the announcement is spoken then.
It does not happen when the text is neither at the beginning nor at the end of the text field (i.e. some text is in the text field and the cursor is in the middle of it) - only the announcement is spoken for arrow up/down.
I would like to get rid of the “sound, whole text read” thing when it happens.
Note that I am using the "-control:textView:doCommandBySelector:” delegate method of the NSTextField to “capture” the arrow up/down presses in the text field (more specifically the “moveUp:” and “moveDown:” selectors) to override it to move the selection in the table and send the announcement requested accessibility notification that speaks the currently selected table row (search result). I am returning YES from the delegate method to indicate that the method fully handled the key binding and the text field should not do so.
It seems to me that VoiceOver notices that focus is on an editable AXTextField and that the user is trying to move to the next line when there is none, so issues the sound. As I think of it, VoiceOver has no other way to provide this functionality as the NSTextField has no accessibility notification (e.g. NSAccessibilityBoundsReachedNotification) to send that would suggest to VO that the user attempted to move beyond the “borders” of the text (beyond the end, before the beginning). Selection does not change in such case (which is what drives reading the characters in the text field normally - the associated NSAccessibilitySelectedTextChangedNotification), I verified with UI Browser that NSAccessibilitySelectedTextChangedNotification is not sent in such case. So VO has to guess that arrow down (which it noticed directly on the system level, e.g. possibly by some event tap) means movement to the next line, arrow right to the right and inspects the AXTextField attributes to find whether the cursor is at the end of the text, and if so, issues the “end of text” sound and reads the field’s text. But this VO’s guess is of course wrong if the user overrides arrow up/down (or right/left) in the NSTextField’s delegate to do other things than moving up/down. So it seems for VO to *know* (instead of guess) that it should indicate "the end of text reached" etc., it should get the information about such situation as a (new) notification from the only one who really knows, which is the NSTextField/AXTextField.
Am I right and if so, should I file a bug? Again, is there some way to overcome this right now? I tried posting with NSAccessibilityPriorityHigh hoping it would “trump” the information VO wants to speak, but that did not change the described behavior.
I just want the selected table row to be spoken while the user is in the text field navigating the table view results with arrow up/down.
Have you tried comparing your suggestions menu to those found in Finder and Mail search? I notice that those search fields have a child with a role of SGTMenu, which has a single child of AXMenu. Matching the role and hierarchy might get things working.
No, I haven’t. Actually the suggestions in my case are in a table that is present in the window permanently (even with empty or non-focused search field) and it’s a sibling of the search field (if you open a file in TextMate 2 and press Cmd-T, that’s the situation I am working with). I will see how workable it is to turn the NSTextField and NSTableView siblings into the hierarchy and roles you are suggesting but thinking about it is certainly raising the hair on my neck right now :-)
Thanks, we will :-)