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

Accessibility fixes for Bundle Item Chooser #1246

Closed
wants to merge 3 commits into
base: master
from

Conversation

Projects
None yet
2 participants
@dusek
Contributor

dusek commented Jul 24, 2014

More detailed info in commit messages.

I release these patches into the public domain.

dusek added some commits Jul 13, 2014

Use AXValue of OakChooser's cells for accessibility announcements
Previously we used [NSCell stringValue], which is not suited for cells with
custom implementation for AXValue accessibility attribute.
Improve accessibility for OakBundleItemCell
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.
Implement basic accessibility for OakKeyEquivalentView
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.

@dusek dusek changed the title from Accessibility improvements for Bundle Item Chooser to Accessibility fixes for Bundle Item Chooser Jul 24, 2014

@sorbits

This comment has been minimized.

Member

sorbits commented Jul 28, 2014

Merged as f3b6c07...ae37334, thanks!

I took the liberty to change OakKeyEquivalentView’s accessibilityAttributeNames method so that the compiler does the initialization (somewhat consistent with what our other implementations of this method do, as I changed it in 5edd347).

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.

@sorbits sorbits closed this Jul 28, 2014

@dusek

This comment has been minimized.

Contributor

dusek commented Aug 11, 2014

(sorry for the delay in response, I have been terribly busy :-)

I took the liberty to change OakKeyEquivalentView’s accessibilityAttributeNames method so that the compiler does the initialization (somewhat consistent with what our other implementations of this method do, as I changed it in 5edd347).

great, I will use that idiom from now on :-)

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).

great (I did not know that)

Is it possible to make VO read tab triggers letter-by-letter? I think that would be more useful.

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 speak-as property. But nothing like that on OS X.

That said, I tried to play a little bit with modifying the strings themselves, e.g. there is "inc" in C bundle for #include "...", VoiceOver pronounces it as "incorporated", I tried "i n c", it worked fine (spelled out "i", "n", "c"). Then I tried "m a c", but it pronounced the "a" as the English indefinite article "a", not as "a" the letter, but changing that to "M A C" made it work. But if we also capitalize, then we loose the ability to distinguish "inc" and "Inc". It's a mess.

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).

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.

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.

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