Support text attributes with VoiceOver

[dusek]

VoiceOver can announce text formatting, such as bold font, italics,
underline, font, etc., as well as whether text is misspelled. For this, it
needs the AXAttributedStringForRange attribute supported. This commit does
exactly that.

Testing can be done in this way (VO stands for Ctrl-Option):

• first interact with the text (VO-Shift-down arrow when standing
  on the text element)
• to announce text attributes for character after cursor, press VO-T
• to seek for next:
  • misspelled text: VO-Cmd-E
  • color change: VO-Cmd-K
  • underlined text: VO-Cmd-U
  • many more (see VO-H-H, "Find", close help with Esc)
• to seek for previous *: just add Shift to the shortcut

Some attributes remain to be supported (full list of attributes is
available at:
https://developer.apple.com/library/mac/documentation/cocoa/reference/applicationkit/Protocols/NSAccessibility_Protocol/Reference/Reference.html#//apple_ref/doc/uid/20000945-SW53).

The misspelled text VoiceOver support can be used nicely with TextMate's
spelling support:

1. the user finds next mistake with VO-Cmd-E, hears the misspelled word,
   perhaps reads it on a braille display
2. the user then presses Cmd-; to show the spelling menu for that word
   and chooses the desired resolution (apply suggested correction etc.)
3. go back to step 1. :-)

Also the user can turn on announcements of attribute changes:

• press VO-V
• choose "Text Attributes" setting with arrow left/right
• choose "Play Tone" or "Speak" with arrow up/down and confirm with Return

Then when moving in the text with arrows (e.g. arrow down), VoiceOver beeps
(or speaks text attributes) whenever text attributes change.

[dusek]

Forgot to add: I release both patches into the public domain.

[dusek]

Also I would appreciate tips for situations (perhaps grammar bundles and the specific language construct that triggers the situation in that grammar) where following things happen in text (if they can happen in TextMate at all) - I have not found (met) any:

• links (things that can be clicked to open a URL etc.)
• underlined text
• underlined text with non-single underline (e.g. double underline) or non-contiguous underline (e.g. dotted underline)
• text with bold or italics
• text with strikethrough
• text with superscript/subscript

This would help me to add missing attributes / test existing attributes better.

[sorbits]

Thanks, I merged the 3 commits into 2108810 with just some minor code style changes (about when/where to use spaces).

As for your questions: There is only one underline style in addition to the squiggly underline used for misspelled words. There is no use of strikethrough, superscript, or subscript.

Links, which can be opened with enter (⌅) or fn-return should (in the normal case) have a scope prefix of markup.underline.link, so these can be identified while iterating over the scopes (which is presently done to obtain styles) like this:

scope::selector_t linkSelector = "markup.underline.link";
for(auto pair = scopes.begin(); pair != scopes.end(); )
{
    bool isLink = linkSelector.does_match(pair->second);
    ⋮
}

Though getting the destination of the link is not possible. That is, there is a command in the Hyperlink Helper bundle that simply use the document content and sends that to the open shell command. But there are also a few specialized link scopes where the command has been overloaded, here are two examples (both of which you can open via fn-return), paste into a C source:

/* Workaround for <rdar://6940427> */
/* Filter RFC822 email headers */

I assume for the attribute, the URL destination is needed.

As for bold, italic, and underline: These are both styles that the theme can apply, but there are also markup.* scopes for these, for elements that represent markup with the given style, for example in a markdown document you can use:

**bold** and _italic_

These styles can be toggled with ⌘B and ⌘I. In practice it might be better to only use the bold and italic accessibility attributes for these scopes, since a theme making e.g. keywords bold, I would assume, is unnecessary information for a blind person.

This can be tested similarly to the markup.underline.link scopes. For testing that something is underlined, but not a link, you would use a scope selector of markup.underline - markup.underline.link.

I hope that answered your questions, otherwise let me know.

[dusek]

Thanks for your explanation (and sorry for my delayed answer):

• I tested underlined text (after installing the Hyperlink Helper bundle) and it works fine
• I tested bold and italics in MarkDown, it works fine. As for your suggestion to make these reported as such to VoiceOver only when they represent a markup, my opinion is that is not the right thing to do:
  • The same argument could be made that sighted people don't need italics unless the text is marked up as italics.
  • If some bundle e.g. defined comments to be in italics and the VoiceOver user wanted to find some comment, then they would want to be able to search for italics. So finding the "right" cases when to report italics (or bold etc.) attributes seems unreliable.
  • Accessibility APIs can be used also for automated testing or information extraction (not only in VoiceOver), so we want to not "lie" to them :-)

So I would stay (at least for now) on the "conservative" path when reporting these text attributes - report them as they are displayed.

• I think current support for links is not that bad. Users can search for underlined text (which can however return more than just links, but still a good tool to have) and then launch them using Enter (⌅) (which is btw. more reliable than the VoiceOver way with VO-space, based on my testing with links in TextEdit). So given that URL would currently also be unavailable (it is not required for accessibility links, but would be good to have - e.g. VO-Shift-U reads the link target), it seems that implementing links as links is currently more work than the benefits it would yield over the current way (the only real benefit for the VO user would be ability to explicitly search for links as opposed to just underlined text).

Thanks again for having answered my questions.

[dusek]

Still I got links working (with the expected limitations) and will be submitting them in the next couple of days :-)