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

Closed
wants to merge 6 commits into
base: master
from

Conversation

Projects
None yet
2 participants
@dusek
Contributor

dusek commented Mar 31, 2014

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 used NSObject* as
it is more type strict, but if the TextMate's convention is to use id in such
cases, 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.

dusek added some commits Mar 31, 2014

Add OakSetAccessibilityLabel function
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.
Add ability to specify AX labels in UI functions
Accessibility labels now can be specified conveniently as a parameter
of a UI construction function.
Notify VoiceOver user of results count directly
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)
@sorbits

This comment has been minimized.

Member

sorbits commented Apr 1, 2014

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 menuHasKeyEquivalent:forEvent:target:action:. When an action is invoked via this method, it does not get announced. An example of this is using ⌘T and then ⌘1-⌘3 to switch source.

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 NSImageView ignored by VO?

As for NSObject* vs id then I prefer the latter but I have no strict rules about it, so I left your NSObject*’s.

As for the history pop-ups, I would like to retire these custom (modal) windows. I think the main problem with using an NSComboBox is that I have custom code to resize the NSTextField based on content, and previously Apple would warn if NSComboBox was used in a non-standard size, but it seems they have come around on this.

@sorbits sorbits closed this Apr 1, 2014

@dusek

This comment has been minimized.

Contributor

dusek commented Apr 4, 2014

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.

Unfortunately I don't have a better suggestion as I think there is no API to announce something globally. I tried specifying NSApp as the element of the notification, but that yielded nothing. I might ask the Apple's accessibility mailing list about this.

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.

I tried it (⌘G) and this is great! Also I will look into how to make document statistics (⌃⇧N) accessible via an announcement.

Something else related to announcements: TextMate uses a few menu delegates where it implements menuHasKeyEquivalent:forEvent:target:action:. When an action is invoked via this method, it does not get announced. An example of this is using ⌘T and then ⌘1-⌘3 to switch source.

I noticed that issue.

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?

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.

Something else, is ec491a4 the best way to get an NSImageView ignored by VO?

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, NSControl delegates its accessibility to its cell. So in my opinion the cell should decide (and therefore specify) how accessible it is (including not being accessible at all).

As for the history pop-ups, I would like to retire these custom (modal) windows. I think the main problem with using an NSComboBox is that I have custom code to resize the NSTextField based on content, and previously Apple would warn if NSComboBox was used in a non-standard size, but it seems they have come around on this.

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 NSComboBox would fix the accessibility right away.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment