Comment 1 by jteh on 2008-05-30 01:25
This is not particularly important, so can be done after 0.6.
Changes:
Milestone changed from 0.6 to None

Comment 2 by jteh on 2010-01-22 20:36
I'm rewriting most of this code in #490.

Comment 3 by pvagner on 2012-04-19 06:25
testing with firefox 11 I see this behaves as requested.
I can't locate a revision when we have changed that but definatelly keyboard shortcut is reported after the control name.
Closing as fixed.
If I have overlooked something please excuse me and point me to what I've forgotten please.
Changes:
State: closed

Comment 4 by pvagner on 2012-04-19 06:27
oops I was wrong.
However now this appears to be easy to fix, we only need to swap some variables inside a string...
Changes:
State: reopened

Comment 5 by pvagner on 2012-04-19 09:26
Actually we need to modify speech.speakTextInfo() function in order to adress this ticket.
Currently we are using speech.getControlFieldSpeech() for getting text of the control's attributes once. I think we'll need to add somekind of flag into speech.getControlFieldSpeech() and call it twice because I think the only bit we want at the end is keyboard shortcut.
This way we may add conditions whether a property should be report before or after the actual text.
This sounds too complicated and I am not sure I can cover all the use cases. So before I'll change something I would like to get my ideas approved. Is this a acceptable way on doing it?

cc @pvagner

This is also related to #7232

@LeonarddeR #490 is aparently closed and this was merged. I cannot test this issue since the nv access website has been updated and there are no short keys reported.

@jcsteh is this still reproducible?

Using the following:

data:text/html,<a accesskey="4" tabindex=0 href="">Messages</a><br><a accesskey="3" tabindex=0 href="">Notifications</a><br><a accesskey="6" tabindex=0 href="">Chat</a><br><a accesskey="2" tabindex=0 href="">Friends</a>

I get different results if I view the links in browse mode versus tabbing through them.

Unless #7232 being planned to be addressed soon, this issue is pretty annoying in browse mode for buttons and menu items when a web application features a lot of access keys.
Links might be found with lengthier text, and I guess announcing before or after for them is disputable.

My first approach, as proposed 7+ years ago in #49 (comment) would be to add a new fieldType value to getControlFieldSpeech, something like "afterText", and add a new run in speakTextInfos right after the actual text has been added to the speech sequence.
@michaelDCurran, what do you think? Would you be willing to accept a PR that follows this approach?

@JulienCochuyt: Could you give an example of this approach?