Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Accessibility fixes for Bundle Item Chooser #1246
Previously we used [NSCell stringValue], which is not suited for cells with custom implementation for AXValue accessibility attribute.
More specifically item's displayed keyboard shortcut or tab trigger is now announced by VoiceOver. Implementation of accessibilityAttributeValue:forParameter: returns nil for some attributes. This is a hack to avoid doing tedious adjustments of certain parameterized attributes (like AXStringForRange, AXAttributedStringForRange, AXBoundsForRange, AXRTFForRange) for string AXValue that is extended (appended) by extra information at its end in accessibilityAttributeValue:. To get an idea how tedious this is (even though our case is a bit simpler by not *prepending* anything before the AXValue, and not being an editable field), look at OakLinkedSearchFieldCell. This looses the ability for the user to interact with the text, but considering how seldom this will be used (if at all), for now this seems acceptable. This is needed because VoiceOver asks for the *StringForRange attributes and if implemented, will never query AXValue (which is where our custom behavior is). In the future when tables will be migrated from cell-based to view-based ones, the tab trigger or shortcut could be a separate NSView, which would probably allow for much more elegant solution to this problem.
I experimented a lot with different combination of attributes, this one works reasonably well compared to the others (even though it is less feature complete). I may revisit experimenting with it at some later point.
Merged as f3b6c07...ae37334, thanks!
I took the liberty to change
Bundle items can have both a key equivalent and tab trigger so I made it potentially add both to the AX value (the UI currently does not allow showing both).
Is it possible to make VO read tab triggers letter-by-letter? I think that would be more useful.
I (think I) consistently refer to key equivalents as key equivalents, but I didn’t change shortcut in your AX text as I do not know if there are guidelines about what terminology to use.
(sorry for the delay in response, I have been terribly busy :-)
great, I will use that idiom from now on :-)
great (I did not know that)
Unfortunately there is no way to specify to VoiceOver to pronounce different parts of string in a specific way on OS X. Only thing I know in this direction in general is the CSS 3 speech module, specifically its
That said, I tried to play a little bit with modifying the strings themselves, e.g. there is "inc" in C bundle for
A blind user who has a braille display (and those doing programming or in general text editing should have one) however can read the exact spelling of the string. Given this and how no satisfying workaround exists for the braille-less experience, I would leave it how it is for now (and file an enhancement request in rdar).
You are right, I intended to change it to "key equivalent", but forgot about it in the end. The idiom used by Apple for menu items is to have the shortcut directly after the menu item title, with no "shortcut" or "shortcut is" (you can try by going to the menu using VO-M, and then using arrows to navigate it). But given that in our case we have bundle items usually with much more complicated title texts than in menu items, and that we have also tab triggers that we announce as such, I felt inclined to explicitly to announce the keyboard shortcut (or key equivalent) using "keyboard shortcut is ...". I will submit the change from "keyboard shortcut" to "key equivalent" in another pull request.