303408 - Text size menu in View not completely spoken by Window Eyes

Status: RESOLVED INVALID

(Core :: Disability Access APIs, defect, P2)

Description

[Dan Kinnunen]

Text Size menu in View, the shortcut for increase/decrease text size not
completely spoken by Window Eyes. Window Eyes speaks only 'Ctrl' and not "Ctrl++'

  Steps to recreate the reported problem.

1.  Alt+V for view menu.
2.  Press z for text size.
3.  Use up/down arrows for increase/decrease options.

Comment 1

[Mark Pilgrim (inactive)]

This is almost certainly a bug/feature in WindowEyes.  It displays the same behavior in other applications, such as Opera.  WindowEyes never reads punctuation marks in menu items or accelerators, including "%", "+", "-", and so forth.  I have an extension that adds a menu item to the Firefox menu with the accelerator Ctrl+].  WindowEyes reads that as "Ctrl" as well.

Tempted to mark this one invalid and file a bug on WindowEyes to add a verbosity setting that reads punctuation in menu items and accelerator.

Comment 2

[Aaron Leventhal]

It's a verbosity setting that all screen readers have -- different modes for reading punctuation. I'd argue it's actually a bug in Window-Eyes that they don't automatically speak punctuation for the accelerator though. Bill, want to file a bug in betacentral?

Comment 3

[William Smith]

Window-Eyes can't do anything on this one because the "ctrl++" is in the MSAA name instead of the keyboard shortcut.   Window-Eyes believes that that is just part of the menu item text so it's not Window-Eyes' problem.

I think this bug should be reopened.

Comment 4

[Aaron Leventhal]

Bill, I disagree. Window-Eyes already does special parsing of the accessible name for ROLE_MENUITEM. That's why it says "Reload R Ctrl+R" instead of "Reload Ctrl+R R". It can do this because the accelerator is seprated from the label with the tab character in the accName. So Window-Eyes knows when it's reading a menu accelerator and can do the right thing.

Otherwise, if we reeopened this bug, exactly how would you have us expose accelerator text differently?

Comment 5

[William Smith]

I should have looked at our code more closely.    Window-Eyes uses the keyboard shortcut property to get the "R" in your example.   Then we will put it either before or after Reload based on a menu verbosity setting.

We designed it to behave the way it does accelerators.   The text "ctrl" gets turned into "control" by an exception dictionary entry.   If the user wants to hear the shortcut in this Increase/Decrease size case, the math punctuation set file entry can enable the "+".   We don't have that punctuation on by default so that we don't say an extra "plus" for every accelerator, which is best for most applications.  

Comment 6

[Aaron Leventhal]

So it sounds like you can fix this in Window-Eyes?

Comment 7

[Mark Pilgrim (inactive)]

If there's something we can do to make your life easier in this regard, please let us know.  But it really sounds to me like WindowEyes has all the information it needs to speak this intelligently, and just needs a few tweaks to an exceptions list to make this work.  As I said before, this is not a Firefox-specific issue; WindowEyes behaves the same way in other applications that use Ctrl++ or Ctrl+-, or applications that use "%" as part of the menu item name.

Comment 8

[William Smith]

I entered it as our BC 3212 but it isn't easy to solve in the general case because in some applications an accelerator can have multiple pluses and/or multiple-keystrokes after the modifier.