VoiceOver does not announce tab name after switching to it

[dusek]

When a VoiceOver user switches between tabs using Cmd-{ and Cmd-}, VoiceOver no longer announces the name of the tab switched to. This happens with recent TextMate 2 on Yosemite. This used to work with older TextMate 2 on Mavericks and relied on a notification being sent that the new implementation of tab bar seems to send as well based on looking at the code (but needs to be verified in reality). Could be either Yosemite issue or new tab bar implementation issue.

[sorbits]

Announcing the newly selected tab still work most of the time on
Mavericks (10.9).

I say most of the time because occasionally VO will instead announce the
text view’s changed value (speaking the current line from the text
view).

So I am thinking that perhaps the issue is that there are too many
notifications sent (menu item, tab bar changed value, and text view
changed value), so Yosemite (10.10) only acts on the last one.

On 14 Oct 2014, at 0:36, Boris Dušek wrote:

When a VoiceOver user switches between tabs using Cmd-{ and Cmd-},
VoiceOver no longer announces the name of the tab switched to. This
happens with recent TextMate 2 on Yosemite. This used to work with
older TextMate 2 on Mavericks and relied on a notification being sent
that the new implementation of tab bar seems to send as well based on
looking at the code (but needs to be verified in reality). Could be
either Yosemite issue or new tab bar implementation issue.

---

Reply to this email directly or view it on GitHub:
#7

[dusek]

Thanks for information on Mavericks as I am already upgraded to Yosemite and have not yet installed a Mavericks virtual machine.

I guess I will end up having to ask on the Apple accessibility mailing list about this.

[sorbits]

Something else I have been wondering about with respect to the tabs is
the overflow button.

This is currently eclipsed by the tab bar view because that view has
NSAccessibilityTabGroupRole, so VO never descend to its chilren (the
overflow button is a descendent of this view, added to the last tab). In
practice the same goes for the close buttons, but I consider these
buttons less essential.

I tested Safari and Finder, and their tab implementation show the same
flaw (overflow button eclipsed by the parent accessibility tab group). I
think this is either an oversight on Apple’s part, or it’s because
it’s too cumbersome to fix.

On 14 Oct 2014, at 8:48, Boris Dušek wrote:

Thanks for information on Mavericks as I am already upgraded to
Yosemite and have not yet installed a Mavericks virtual machine.

I guess I will end up having to ask on the Apple accessibility mailing
list about this.

---

Reply to this email directly or view it on GitHub:
#7 (comment)