-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve accessibility of Find dialog (+small stuff) #1221
Conversation
This function makes it easy to set accessibility "labels" for UI elements. It is flexible - takes care of NSView vs. NSControl case, labels can be specified directly as a string or as a user interface element.
Accessibility labels now can be specified conveniently as a parameter of a UI construction function.
The button for showing results count in find dialog is meant to quickly provide the user just with the information about number of search results. Unlike with full search, where the resulting information is very large and has to be presented in a table, this information the user is requesting is very short ("%d occurences of \"%s\"") so can be, for better VoiceOver user experience, presented directly to the user without requiring them to leave the Show Results Count button. Without this addition, in order to learn this short information, VoiceOver user would have to move to the status string below the results table after pressing the button to learn this short information. Due to technical reasons, the implementation is not strict: - it requires the user to stay on the Show Results Count button until the results count gets displayed (issue for searches longer than 1-2 seconds where user might move away from the button), otherwise the user is not notified of the result and has to move to the status string to learn it - any changes to the status string not related to results count (e.g. if the user has launched a full-fledged search reporting each directory searched) are being reported while the user is on the Show Results Count button (which should happen really seldom in such a case - Voiceover user would probably not "park" their VoiceOver cursor on this button when doing a full fledged search)
Thanks as always! Merged as 9f177d3...25b3a5f. I did not merge 86603ef but instead added the feature via 25b3a5f — if you have any suggestion for how to better associate the notification with the find panel or make it global, please let me know. There are also command results which may show (custom) tool tips which should also be announced, although here I could associate them with the text view (as I did for 5f94f46), though in practice the user can invoke commands without a text view. Something else related to announcements: TextMate uses a few menu delegates where it implements It looks to me that the API does not actually allow Apple to announce the selected menu item, since the delegate method return target and action, not any actual menu item found. Do you know anything about this? Something else, is ec491a4 the best way to get an As for As for the history pop-ups, I would like to retire these custom (modal) windows. I think the main problem with using an |
Unfortunately I don't have a better suggestion as I think there is no API to announce something globally. I tried specifying
I tried it (⌘G) and this is great! Also I will look into how to make document statistics (⌃⇧N) accessible via an announcement.
I noticed that issue.
Unfortunately no. But it seems the menu item (or its deepest visible ancestor - "Go" top-level item) gets highlighted when pressing ⌘1-⌘3 in file chooser and that should IMHO be enough for VO to announce it. Probably again a good topic for Apple's accessibility mailing list, I will ask that question there after making a minimal repro.
I noticed this commit, thanks for this work to clean the status bar. I submitted 4ec184a in #1224 with something I consider "better". I bet there could be discussions and fights which approach is better, just like the legendary which one of Emacs vs. vim is better (it's TextMate 2 :-P). But in general,
Yeah, when I saw the interface, I was thinking that it is, by the real meaning of the UI, a combo box (editable text field with value changeable either by editing the text or by choosing a value from menu). Making it into |
These commits improve accessibility of Find dialog by setting accessibility
labels for various UI elements and announcing result directly in one case.
While I was at it, I improved a little bit in the same spirit old code for
accessibility in status bar, and added one of my email address hashes.
I am not sure with
NSObject*
vs.id
in my commits - I usedNSObject*
asit is more type strict, but if the TextMate's convention is to use
id
in suchcases, please feel free to change it that way (or tell me to change it).
Also there is one issue - the Find/Replace history menu is in a new window
to which VoiceOver does not switch automatically (only announces a "new window"
and provides no feedback when navigating just with arrows up/down (as opposed
to VO-up/down), but fixing that is beyond the scope of work I want to do right
now (and maybe beyond what I am capable of right now :-).
I release these patches into public domain.