Some indicator menues and menu items now not have mnemonic letters

Hammer Attila hammera at pickup.hu
Wed Mar 21 15:17:06 UTC 2012


Hy,

Now, some indicator main menues and menu items not have mnemonic 
letters, but mnemonic letters some time fasting the navigation with 
screen reader and keyboard with visual impaired users.
Some examples the future advantages:
If future have a mnemonic key for example the messages indicator main 
menu (need doing this with indicator-messages package), not need 
pressing two right arrow and one left arrow to activate the messages 
indicator and access the menu items.
An another example is the sound indicator. Now need pressing I think 
five right arrow to access this indicator. Future this is not need, if 
have mnemonic letter the sound indicator main menu (need doing this in 
indicator-sound package).

Look the actual state:
A typical example is in indicator-session package the device menu and 
user menu.
In the device menu all menu items not have mnemonic letters (system 
settings, displays, startup applications, lock screen, suspend, restart, 
shutdown, etc).
In the network indicator all menu items have mnemonic letters, except 
disconnect and edit connections menu items. Of course the awailable 
hotspots full acceptable why not have mnemonic letters.

I looked possible associate this menu items with mnemonic letters with 
translation side, usual yes. If the translated string containing _ 
simbol, after the underscore character have letter will be the mnemonic 
letter of the proper menu item.
This is a temporary workaround to non english language translators if 
want possible associate mnemonic letters with importanter menu items of 
the indicators, but future better doing this task with general in source 
level.

I have got a question:
I very would like working this task to prowide better and easyest 
keyboard access of indicators.
If I doing general patches with the required source packages, have 
chance to land this change before final release the proper packages? Or 
better scheduling this task general with next development cicle, because 
now already have UI freeze, near beta2 and final release, etc?
Have advantage to schedule this task with next development cicle, this 
change not risk already full translated indicators localized outputs 
before final release with more languages.
If need changing more strings in indicator source packages, translators 
possible not have enough time to verify the changed strings, doing the 
translation corrections before final release.
I doed a fast calculation. Need changing first impression with 30 
strings, but this is an estimated value, because I only possible lookup 
my system the awailable indicators.

Attila



More information about the Ubuntu-accessibility mailing list