mirror of
https://github.com/textmate/textmate.git
synced 2026-01-14 17:28:05 -05:00
85d3af94ba
Accessibility rotors allow VoiceOver user to navigate content quickly by making possible navigation through select elements only. In this case, we enable VoiceOver users to navigate efficiently through symbols. The first way to invoke a rotor is a "global" one (does not take into account current position in text) and is invoked with VO-U. After pressing arrow left/right sufficient times to reach "Symbols", one is presented with a list analogical to the "Jump to symbols" TextMate feature invokable by Shift-Cmd-T. Arrow up and down then enable navigating through items, Return selects the result (and jumps to it), Esc cancels the interface without moving the cursor. Also filtering the list works by simply typing characters (implemented as case-insensitive substring search - consistent e.g. with Safari's "Headings" rotor). The second way to use a rotor is a "local" one (navigates w.r.t. the current position in text) and is typically done through Trackpad Commander (turned on by VO + two finger "screw" gesture to the right on the Trackpad). Then one uses two-finger "screw" gesture (like (un)screwing the bottle lid from/to the bottle with thumb and index finger) to select "Symbols". When this is finally selected (the selection is persistent), the user can then use flick with one finger up or down gestures to move to the previous/next occurrence respectively. I made a choice at one spot - I report the "symbol location - end of hardline" as the range of the symbol (that is e.g. what VoiceOver reads when navigating the elements). This seemed to work best for the user at least in the Objective-C code. The APIs are 10.13+ only, so appropriate avaiability declarations are put in place to not cause warnings from the compiler. I was not sure whether some declaration like that is needed also for the OakTextView's informal category's conformance to the `NSAccessibilityCustomRotorItemSearchDelegate` protocol - the protocol is 10.13+ only too, but the compiler does not warn about conforming to it. Perhaps the Objective-C runtime is smart enough to take into account that the `NSAccessibilityCustomRotorItemSearchDelegate` symbol is (hopefully) weakly-linked and adds conformance to it (I assume using the `class_addProtocol` function) only when it is non-nil. I have however not tested whether the compiled app actually degrades gracefully (without crashing) on macOS 10.12 and earlier, though (for starters, I seem not to have access to a macOS Sierra image to create a VM).