If an object has an accelerator, Orca currently adds it in parentheses immediately after the object.  For example:

Open Terminal(Shift Control n)

For mnemonics, there are a few options, including the following:

1) Somehow find the character in the string and highlight it in braille somehow
2) Display is as a separate string as we do with accelerators

The easiest option would be #2 and we could include it with the accelerator text.  For example -- the following puts the 't' mnemonic for the menu item just prior to the accelerator:

Open Terminal(t,Shift Control n)

If the object has a mnemonic, but no accelerator, you'd see something like the following:

Open Terminal(t)

If there were no mnemonic and only an accelerator, you'd see what you currently see.

If there were neither, you wouldn't see any any additional text.

In addition, I'm curious if there would be a desire to turn the display of the mnemonic on/off and whether it would be a dynamic thing (e.g., only display it if you pressed the Alt key) or a settings thing like we do with the speech presentation of mnemonics.

> 1) Somehow find the character in the string and highlight it in braille somehow

This could be done be using dots 7/8 on the brailledisplay.
this will be nice but more complex to implement.
An advantage is it doesn't need aditional display clells on a brailledisplay.
Another question is what the verbosity option should do with the mnemonic.

The way I'd like to have this handled is to put the braille cursor/dots7 and 8 under the mnemonic.  

One way to do this would be to look at the attributes of the text and use the text attributes feature to represent the attribute in braille.  When I look at menu and menu items in gnome-terminal, for example, I see the "underline:low" attribute being used to paint the mnemonic.

Doing this for all objects *might* be as easy as moving the getAttributeMask from the Text class to the Component class in braille.py.

I personally would opt for adding dots 7 and 8. The only question raised by the use dots 7 and 8 idea I have is: are mnemonics ever capitals? If a mnemonic could be a capital and dots 7 and 8 are used then it wouldn't be possible to identify whether it is lowercase or uppercase when using the NABCC table in brltty.

(In reply to comment #5)
> I personally would opt for adding dots 7 and 8. The only question raised by the
> use dots 7 and 8 idea I have is: are mnemonics ever capitals? If a mnemonic
> could be a capital and dots 7 and 8 are used then it wouldn't be possible to
> identify whether it is lowercase or uppercase when using the NABCC table in
> brltty.

If we go down the text attributes route, the text attributes page allows you to choose any combination of dot 7 and 8 (i.e., none, dot 7, dot 8, or dots 7 and 8).

Created attachment 139952 [details] [review]
Patch that uses text attributes

This patch goes down the text attributes route.  Seems to work OK, with the following exceptions:

1) It doesn't seem to get contracted braille quite right all the time.
2) OpenOffice and Firefox do not give us the text attribute information we need for buttons, menu items, and such, so this patch is no good for them. :-(

Created attachment 139953 [details] [review]
More restrcited patch

Whoops.  The previous patch contained work on another bug I've been trying to get to all week but other things keep pushing it aside.  This patch contains just the stuff needed for bug #588875 and contains the same limitations as described previously.

(In reply to comment #7)
> Created an attachment (id=139952) [edit]
> Patch that uses text attributes
> 
> This patch goes down the text attributes route.  Seems to work OK, with the
> following exceptions:
> 
> 1) It doesn't seem to get contracted braille quite right all the time.
From my experience of liblouis this doesn't surprise me and I am unsure whether it would be possible to get it to work properly with contracted Braille. Therefore would it be best to also provide the other option.
> 2) OpenOffice and Firefox do not give us the text attribute information we need
> for buttons, menu items, and such, so this patch is no good for them. :-(
Yes that's a shame. Is it a matter for openoffice and mozilla or orca?
> 

(In reply to comment #9)
> > 1) It doesn't seem to get contracted braille quite right all the time.
> From my experience of liblouis this doesn't surprise me and I am unsure whether
> it would be possible to get it to work properly with contracted Braille.

I'm not sure where the problem lies, so I can't point fingers yet. :-(

> Therefore would it be best to also provide the other option.

Which option are you referring to?  Do you mean attempting to detect the mnemonic character via the other stuff available to us in the API (e.g., the key bindings associated with the accessible action), or something else?

> > 2) OpenOffice and Firefox do not give us the text attribute information we need
> > for buttons, menu items, and such, so this patch is no good for them. :-(
> Yes that's a shame. Is it a matter for openoffice and mozilla or orca?

From what I can tell, the AT-SPI implementations of OpenOffice and Firefox do not give us the text attribute information we need for buttons, menu items, and such.  As a result, Orca does not get the 'underline' text attribute.  Without this, going down the text attributes route for this bug ends up yielding the current results.

(In reply to comment #10)
> (In reply to comment #9)
> > > 1) It doesn't seem to get contracted braille quite right all the time.
> > From my experience of liblouis this doesn't surprise me and I am unsure whether
> > it would be possible to get it to work properly with contracted Braille.
> 
> I'm not sure where the problem lies, so I can't point fingers yet. :-(
I was just meaning that if Braille is contracted then liblouis points all characters represented by the contraction to the first cell of the contraction (eg. the contraction for tion is ;n (when viewed with the NABCC table of brltty) and so liblouis gives position information for all of tion to be translated to the position of the ; ), therefore how does the user know which character it is which is the underlined one? May be you were also getting other problems with contracted Braille.
> 
> > Therefore would it be best to also provide the other option.
> 
> Which option are you referring to?  Do you mean attempting to detect the
> mnemonic character via the other stuff available to us in the API (e.g., the
> key bindings associated with the accessible action), or something else?
I was meaning the option of putting the mnemonic in brackets along with the keyboard shortcut, eg.
Open terminal (t,shift control n)
[...]
> 

Planning spam. Sorry!

As I commented in bug 654724: "... it occurs to me that access keys *might* have an implication for bug 588875. In particular, there's nothing that states that the access key needs to be a letter in the label for a widget. So we cannot just underline some letter. Do we want to handle access keys differently? Or do we want to have a consistent presentation in braille regardless of the source of the shortcut?"

Feedback/suggestions encouraged. Thanks!

In my opinion it makes no sense to underline the accesskey letter because of two reasons:
1. If the link is fokused and underlined with linkindicator dots 7 and 8 you can't read the highleted letter.
2. If a webdesigner chooses a letter as accesskey which doesn't occour in the link-name you can't underline it as well.

My Suggestions:
Add a new checkbox to firefox specific settings in orca for enabling/disabling the output of the accesskeys
If that setting is enabled orca should present the accesskeys.
The link could be displayed like this:
"foolink_f"

*** Bug 651839 has been marked as a duplicate of this bug. ***

Created attachment 203770 [details] [review]
A second way implementation, please test

Prewious I reported same issue with bug 651839, and begin working an implementation way parallel. :-):-)
I sending braille display equals output with already hearest with speech sinth.
Yesterday I maked an actual version with compatible for latest orca-xdesktop version. If have possibility, please test my patch and say me my direction is good or not, or what need to change my way implementation.
I tested my implementation with various applications (Firefox, Openoffice/Libreoffice.org, Gedit, Terminal), shortcut informations always presenting if awailable this informations.
If you would like seeing braille display the mnemonics information, after you applied this patch with orca-xdesktop branch and do general recompile and reinstall of Orca, after Orca restart you need simple checking in braille page the present object mnemonics check box.
If you click Ok button, the feature toggled on.
Unfortunately I think dot7 and dot8 implementation not a good choose, unfortunately I not possible to try other implementations, because full blocking the last patch with general role name presenting in braille display. For example, Orca Screen Reader window only the main frame presenting, but not seeing the buttons. I don't no for example how can possible marking if a mnemonics letter is a t letter, t letter braille dot number is 2345.
I don't no for example need presenting or not the ALT prefix with dialogue widgets, speech output this prefix is used with dialobs before the mnemonics informations. Some time not possible activating a dialogue widget only with single letter, need using the ALT modifier. If purpose we not reserve more cells the mnemonics informations because possible not fit the output for example a 20 or 40 cell braille display, we need a markup character before mnemonics letter this situation, for example the _ character. This situation the mnemonics letter only reserwing two cell.
Look an example output:
Now used way:
Quit orca without confirmation check box alt w
Perhaps modified output:
Quit Orca without confirmation check box _w
This perhaps modification is not need for example with menu items, because this situation only presenting normal letters with braille display if this feature implementation is active and not have accelerator key.

Webpage accesskey informations is not supporting my implementation yet, this is true for speech support too awailable speak object mnemonics feature. If anybody give me a short code example and tells what role types need listening this attribute, I welcome future try extending my implementation to support this information sending, because this extending is a very good purpose.
Halim, if you have a little time and have access an orca-xdesktop branch Orca version, please test the patch.
If this is impossible because you fulltime using GNOME3 environment, next week I try making a master branch compatible patch.

Attila

Created attachment 203839 [details] [review]
A master branch compatible revision

This patch is compatible with GNOME3 version of Orca.
I tested with my Ubuntu Precise system with Orca latest master version.
Please test the patch if anybody have a little time and using master Orca version.

Attila