TMainMenu accessibiity lazarus / 31-LCL ---------------------------------------------------------------------- Walmir · 2014-08-14 16:18 Hi, The Lazarus  TMainMenu is not following the standards when used with a screen reader. For example, to activate the menu bar, a blind person will use ALT+F to activate the "File" menu. Then, to hear all the menu bar menus, she will hit ESC and hear "File submenu ALT F". Navigating with the left and right arrows, she will hear similar descriptions for the other menus of the menu bar. With Lazarus applications, the description is "Fime submenu". The indication of the accelerator key is missing. Other "problem" is in the menu items. The standard is, for example "Save, control s, s", indicating that she is in the "Save" menu item, the shortcut is CTRL+S and the accelerator key is "S". But applications build with Lazarus will show only "Save, s". The shortcut is omitted. People with vision difficulties, myself included, make heavy use of shortcuts and accelerator keys and most of them depend of them being red by the screen readers. So, appplications built with Lazarus are less accessible to them. So, my question is: how can I make Lazarus follow the standards? Lazarus 1.2.4 Windows 7 Screen reader: NVDA 2014.1.1 ---------------------------------------------------------------------- Never · 2014-08-14 17:06 hello you have to set these properties your self througth the property editor of any control or menu item of your interest. Example : for a button with name :Button1 and caption :Button1 if you want to enable short cut ctrl+B you have to add char [ &  ] before letter [ B ] so your caption in property editor will look like this Caption:&Button For menu items there are also saperate properties in property editor named as ShortCut and ShortCutkey2 Also there is an older thread with the same subject http://forum.lazarus.freepascal.org/index.php?topic=12709.0 hope was helpfull nice coding ---------------------------------------------------------------------- ChrisF · 2014-08-14 17:50 It's quite possible I've not correctly understood what you mean when describing your troubles. Please, correct me or make additional comments if appropriated. Microsoft has defined 2 kinds of keyboard shortcuts for Windows application: accelerators and mnemonics. Though people (including me) are generally and improperly using the same term (i.e. accelerator) for both of them. The way to use them in a program is a bit different. Basically, "real" accelerators are a combination of keystrokes that are defined inside the concerned program for activating a given command. For instance, in your own sample: 'CTRL+S' for saving a file. Please note that this combination (i.e. 'CTRL+S') is a "standard" for such a command, though it's quite possible in your program to define another combination for it. I mean, you still could have 'Save' as a menu caption, and 'CTRL+X' - for instance- as the associated accelerator: accelerator are not necessarily related to their menu caption. Finally, accelerators are not neither necessarily relative to a menu: you can define accelerators inside your application which don't correspond directly to any menu entry. Menu accelerators are defined into the concerned menuitem data when you are designing your application. Still with your former sample, define 'CTRL+S' for the 'Save' menu entry into the 'ShortCut' property of this menuitem. In this case, both the caption for this accelerator will be added automatically to the menu caption (i.e. 'CTRL+S' added just after 'Save'), and this keystroke combination will also call directly your menuitem code, as if the user has used the mouse and click on this menu entry. As already said before, it's also possible to define accelerators without any corresponding menu: see the TActionList component in this case ("Standard" palette in the Lazarus IDE); On the other side, mnemonics are directly relative to a menu/control caption. You can define a 'ALT+Char' combination associated to a letter in your caption, using a preceding ampersand character (i.e. character '&') for that. It can be the first letter of the caption, as '&File' (i.e. 'ALT+F') for instance, but it can also be any another letter of the caption, as 'Fi&le' (i.e. 'ALT+L'). But it's necessarily one existing letter into the caption. In certain case, you can even entry only the concerned character on the keyboard (not having to press both 'ALT+Char'). They are 2 sub kinds of mnemonics: -mnemonics for main menu entry, as 'ALT+F' for '&File' if this is one of you main menu entry with a 'File' submenu (which is often the case in numerous applications), -mnemonics for control, as 'ALT+Q' for '&Quit' if you have a valid pushbutton with caption '&Quit' on your form. Mnemonics (for both cases) are defined in the caption of your main menu entry or of your control: '&File' in your first menu entry will define 'ALT+F' as a keyboard shortcut to display the submenu of this main 'File' menu; '&Quit' in a caption of a pushbutton will define 'ALT+Q' as a keyboard shortcut to call the code associated to it (as if the user has left clicked on the button). So, you have 2 ways to define keyboard shortcuts for your application: accelerators and mnemonics. Each of them is defined differently into your program: but you'll still have to define and enter them yourself. Choose carefully yours when designing your application. It's generally not recommended to use the same combination for both mnemonics and accelerators. Finally, AFAIK using these 2 ways to define keyboard shortcuts allow to have them recognized automatically by any 'Screen reader' program. Just avoid controls that are not standard Windows controls, and that are displayed/painted directly by code: don't use 'TLabel' component for instance, but prefer 'TStaticText' instead. ---------------------------------------------------------------------- taazz · 2014-08-14 18:24 As accessibility is described the ability that an operating system has to allow impaired people (eg blind) to use a computer, it includes short cuts, accelerators, Text to speech, speech to text, themes with high contract for color blind, etc. The current question asks about text to speech for menu and their short cuts accelerators and mnemonics as well as mouse position key presses etc. I'm sorry but I have no experience with accessibility features and how to enable them support them so other than guiding the answers in the correct direction I can't offer any help. ---------------------------------------------------------------------- engkin · 2014-08-14 19:43 Short Answer to get the missing key: Precede the menu caption or sub-menu caption with an ampersand. On my keyboard the ampersand is located above the number 7 key. I press and hold shift key then I press 7 to get this character. Examples: For file use: &File For save, use: &Save ---------------------------------------------------------------------- rvk · 2014-08-14 20:18 Quote from: engkin on August 14, 2014, 09:43:03 pmShort Answer to get the missing key: Precede the menu caption or sub-menu caption with an ampersand. That only speaks the Alt letter after the menuitem (almost inaudible and without the text shortcut). Either way... this wouldn't be a solution for Save (Ctrl+S) or Open (Ctrl+O). Sometimes the &Letter isn't practical and an alternative shortcut needs to be defined (using Ctrl instead of Alt). On screen it looks like "Open    Ctrl + O" and normally the narrator would speak the menu and at the end it would speak "Shortcut Command control plus O". It doesn't do that in a Lazarus app (neither in the Lazarus IDE). If you try it in notepad it does this correctly. So yeah... The TMainmenu does not conform to the Microsoft Active Accessibility on this point. My guess there is some heavy custom drawing going on and the narrator doesn't see the shortcut. ---------------------------------------------------------------------- engkin · 2014-08-15 00:21 @rvk, the original poster wants both, the Alt and the shortcut. My answer was for the Alt. The screen reader the OP is using is able to handle applications that do not provide IAccessible interface. NonVisual Desktop Access Executable: sourceforge.net/projects/nvda/ Source Code: community.nvda-project.org/browser/ ---------------------------------------------------------------------- Walmir · 2014-08-15 15:32 Quote from: Never on August 14, 2014, 07:06:59 pmyou have to set these properties your self througth the property editor of any control or menu item of your interest. ...for a button with name :Button1 and caption :Button1 if you want to enable short cut ctrl+B you have to add char [ &  ] before letter [ B ] [/quote] Excuse me, but I know perfectly well how to set these properties. Al of them  ARE set, so the problem is not this. And in my message i refered only to TMainMenu... ---------------------------------------------------------------------- Walmir · 2014-08-15 15:48 ChrisF, Thank you. I am aware of all you sad. I have an ActionList component where the actions shortcuts are set, via the property of the same name. These actions are then linked to the menu items. Also, the menu items captions are all set with the "&" character to ativate what we informally call accelerator key. So, the question here is that the cited screen reader is not reading what it should in applications built with Lazarus -- while it works perfectly well with applications written with Delphi (note that I am referring only to TMainMenu). ---------------------------------------------------------------------- Walmir · 2014-08-15 16:07 Quote from: engkin on August 14, 2014, 09:43:03 pmPrecede the menu caption or sub-menu caption with an ampersand. On my keyboard the ampersand is located above the number 7 key. I press and hold shift key then I press 7 to get this character. Are you kidding? Only because I can't see the "&" key, it doesn't mena I don't know where it is... I hit it without seeing it and I know very well how to use it in the caption property... The question here is that I descovered TMainMenu is not conforming with the accessibility standards and I would like to know why and how to solve this problem. ---------------------------------------------------------------------- Walmir · 2014-08-15 16:12 Quote from: rvk on August 14, 2014, 10:18:02 pmOn screen it looks like "Open    Ctrl + O" and normally the narrator would speak the menu and at the end it would speak "Shortcut Command control plus O". It doesn't do that in a Lazarus app (neither in the Lazarus IDE). If you try it in notepad it does this correctly. Is exactly of this I am talking about... For some reason the screen reader can't see the text referrng to the shortcut. ---------------------------------------------------------------------- Walmir · 2014-08-15 16:33 Given some replies i've got, I feel I must clarify the following: 1 - Sure I know where the "&" key is on my keyboard. 2 - I'm not a begginer: I know how to use the "&" character in the caption property. 3 - My question relates only to TMainMenu and the NVDA screen reader 4 - I don't know if the problem is similar in Linux with ORCAA. Follow the steps I showed in my first post with, say, Notepad, and afterward whith a Lazarus applications (or even theIDE) to see the behavior I described. ---------------------------------------------------------------------- ChrisF · 2014-08-15 18:24 Sorry if I didnt' understand what you really meant, neither what is your knowledge into programming. For telling the truth, my own tests in the past were based upon Delphi, and not Lazarus/FPC. I just notice something into one of your last posts, concerning "real" accelerators: Quote from: Walmir on August 15, 2014, 05:48:22 pm... I have an ActionList component where the actions shortcuts are set, via the property of the same name. These actions are then linked to the menu items. ... Have you tried instead to use directly the ShortCut property of the concerned menuitems, and not using an "intermediate" TActionList component (at least for a test purpose) ? As in this case, the shortcut string (like 'Ctrl+E', for instance) is really added automatically at the end of the menu caption string displayed on the screen, it should theoretically help the screen reader program. Mnemonic shortcuts (i.e. with the '&' character) seems to be another problem... **Edit** I've just made a test using the ShortCut property of the menuitems, and it's not working neither. There is definitively something wrong with Lazarus, indeed. . ---------------------------------------------------------------------- ChrisF · 2014-08-15 22:09 After a few investigation into the LCL code (Windows version, file win32wsmenus.pp), all that is visual concerning the menus is in fact "painted". Even for menus with text only, the menu text is displayed through DrawText and DrawThemeText API calls. Everything which is concerning directly the windows menu API seems to be "deprecated" for the visual part; I think there is even a bug inside it. Plus, there are no Unicode/Ansi conversions at all for them. I think it should be possible to "reactivate" a few of them, at least in order to improve accessibility for the menus. 1/ Accelerators (ShortCut and ShortCutKey2 properties for TMenuItem): There is a TWin32WSMenuItem.SetShortCut method, it's even called correctly, but it just does nothing (nothing concerning the accelerators, I mean): Code: [Select]class procedure TWin32WSMenuItem.SetShortCut(const AMenuItem: TMenuItem; const ShortCutK1, ShortCutK2: TShortCut); begin   UpdateCaption(AMenuItem, aMenuItem.Caption); end; A simple way to "reactivate" it (but without any string conversions, for my test purpose) as a possible workaround - tested and working -: Code: [Select]class procedure TWin32WSMenuItem.SetShortCut(const AMenuItem: TMenuItem; const ShortCutK1, ShortCutK2: TShortCut); begin   if AMenuItem.ShortCut <> scNone then     UpdateCaption(AMenuItem, aMenuItem.Caption+#9+MenuItemShortCut(aMenuItem))   else     UpdateCaption(AMenuItem, aMenuItem.Caption); end; It needs to be improved, of course. 2/ Mnemonics ('&' for ALT+Char): It seems to be more complicated for them. When the menu is created, menu captions are passed to Windows API (with various other data) through a InsertMenuItem API call. But, as far as I can see, there is a bug inside the TWin32WSMenuItem.AttachMenu method: Code: [Select]    dwTypeData := PChar(AMenuItem); should be in fact:     dwTypeData := PChar(AMenuItem.Caption); Anyway, fixing it doesn't make the trick and it still doesn't work properly. Probably, because of some another API calls done later (inside the SetMenuFlag method may be ?). But anyway, I think this is the correct way to process. For instance, when changing the menu caption later in the user program like this: Code: [Select]menuitem1.Caption:=''; menuitem1.Caption:='&File'; This provokes 2 correct calls to the TWin32WSMenuItem.SetCaption method. This one updates the menu caption through the UpdateCaption method. And then, mnemonics are working (i.e. the screen reader indicates them). I guess a bug should be opened concerning these 2 troubles. Comments welcomed... ---------------------------------------------------------------------- engkin · 2014-08-16 13:38 Quote from: Walmir on August 15, 2014, 06:07:19 pmAre you kidding? Walmir, no I was not kidding. Most of the problems are related to users, including myself, not knowing basic stuff. I had to learn about ampersand character at some point. So please don't get me wrong, it has nothing to do with your sight! @ChrisF, well done. ---------------------------------------------------------------------- ChrisF · 2014-08-16 14:56 (@engkin: Thanks) Final part of the menu troubles: mnemonics Additionally to the bug concerning the dwTypedata field in TWin32WSMenuItem.AttachMenu, there is also a problem with the fMask field. MIIM_TYPE is used currently in the code (to retrieve or set the fType and dwTypeData fields). Unfortunately this option value is only valid for the versions of Windows anterior to Windows 98. For Windows 98 and later, MIIM_BITMAP, MIIM_FTYPE, and MIIM_STRING must be used instead (see http://msdn.microsoft.com/en- us/library/windows/desktop/ms647578%28v=vs.85%29.aspx ). Consequently, setting the caption of the menuitem is not working for Windows 98 and later (i.e. MIIM_TYPE is REALLY not supported in these cases). It's probably related to the size of the MENUITEMINFO structure: when the Windows 95 size is used (44 bytes) MIIM_TYPE is accepted, but when Windows 98+ size is used (48 bytes, hbmpItem added), MIIM_BITMAP, MIIM_FTYPE, and MIIM_STRING must be used instead. After a few tests, replacing MIIM_TYPE by MIIM_FTYPE or by (MIIM_FTYPE or MIIM_STRING), depending of the type of the call is working properly (i.e. the screen reader indicates the mmemonics). Using different parameters for Windows95 or Windows98+ versions is not really a problem, as there is already one variable (i.e. menuiteminfosize) which is set depending of the Windows version in the current code. As a conclusion, troubles and fixes: 1/ Accelerators: -UpdateCaption method must be modified to add the accelerator(s) if present into the menu caption (using the existing MenuItemShortCut function), -plus (unless I'm wrong), the "whole" caption (i.e. caption + eventual accelerator text) must be converted (UTF8ToUTF16 and Utf8ToAnsi), and conditional code must be used (using as usual WindowsUnicodeSupport, UnicodeEnabledOS for GetMenuItemInfoA / GetMenuItemInfoW and SetMenuItemInfoA / SetMenuItemInfoW). 2/ Mnemonics: -bug fix for the caption into the AttachMenu method (i.e. wrong instruction dwTypeData := PChar(AMenuItem)), -using MIIM_FTYPE or (MIIM_FTYPE or MIIM_STRING), instead of MIIM_TYPE for Windows98+, -plus (unless I'm wrong), utf8 to ansi/widechar conversions and usual conditional code (InsertMenuItemA, InsertMenuItemW). ---------------------------------------------------------------------- Walmir · 2014-08-18 16:25 ChrisF, Your descoveries are very interesting. I think all you exposed is in fact bugs. Ironnically, they are better "seen" by people who don't see well... Maybe the fact that textual objects are beeing painted seem the root to all other "misbehavior" of Lazarus applications, wich don't have Hints, captions of TSpeedButtons, ToolbarButtons and BitButton read. For BitButtons, all is heard is "button", not the captions. ---------------------------------------------------------------------- ChrisF · 2014-08-18 17:57 Quote from: Walmir on August 18, 2014, 06:25:49 pmI think all you exposed is in fact bugs. IMHO, yes there are certainly bugs. I intend to introduce a bug report with patches for them after the summer holidays, though I don't know if and when they'll be accepted. Quote from: Walmir on August 18, 2014, 06:25:49 pmIronnically, they are better "seen" by people who don't see well... Well, in this particular case I should even say they are "seeing" the "invisible things". Quote from: Walmir on August 18, 2014, 06:25:49 pmMaybe the fact that textual objects are beeing painted seem the root to all other "misbehavior" of Lazarus applications, wich don't have Hints, captions of TSpeedButtons, ToolbarButtons and BitButton read. For BitButtons, all is heard is "button", not the captions. Yes, I think that all kinds of text which are "painted" using the graphical APIs of Windows are potentially (probably ?) a problem, considering the screen reader issues. BTW, there has been a discussion recently concerning BitButtons and accessibility (I just discovered it a couple of days ago): - http://lists.lazarus.freepascal.org/pipermail/lazarus/2014- June/087766.html - or http://free-pascal-lazarus.989080.n3.nabble.com/Lazarus- Accessibility-of-Lazarus-td4037734.html  This discussion is also related to 2 bug reports concerning this subject: - http://bugs.freepascal.org/view.php?id=24135 - http://bugs.freepascal.org/view.php?id=24583 Apparently, the problem is currently not solved (and seems not easy to be solved simply). ---------------------------------------------------------------------- ChrisF · 2014-10-04 10:59 Patch accepted (though I don't know for which release version it will be included). See bug report: http://bugs.freepascal.org/view.php?id=26718 ---------------------------------------------------------------------- JuhaManninen · 2014-10-04 12:18 It will be in the next major 1.4 release. Please test with trunk as much as possible. I am not an expert in WinAPI nor in accessibility. I applied it to ensure it will not be ignored like some patches have been for too long unfortunately. BTW, I can recommend Lazarus trunk. It is stable and offers many goodies compared to 1.2.x. ---------------------------------------------------------------------- ChrisF · 2014-10-04 13:01 Quote from: JuhaManninen on October 04, 2014, 02:18:10 pm...I am not an expert in WinAPI nor in accessibility... I'm certainly not an expert neither in accessibility. But my feeling is that if we wait for a "real" one, we may have to wait for a very long time (I guess there are only few of them). Anyway, thanks for including it in the next major release. ---------------------------------------------------------------------- JuhaManninen · 2014-10-04 17:16 Quote from: ChrisF on October 04, 2014, 03:01:50 pmI'm certainly not an expert neither in accessibility. But my feeling is that if we wait for a "real" one, we may have to wait for a very long time (I guess there are only few of them). True. I will look at and commit any functional patch for the related TBitBtn accessibility issue, if somebody finds out how to implement it. ---------------------------------------------------------------------- valdir.marcos · 2014-10-04 19:04 Quote from: JuhaManninen on October 04, 2014, 02:18:10 pmBTW, I can recommend Lazarus trunk. It is stable and offers many goodies compared to 1.2.x. Is it time for releasing a beta? ---------------------------------------------------------------------- JuhaManninen · 2014-10-04 21:31 Quote from: valdir.marcos on October 04, 2014, 09:04:31 pmIs it time for releasing a beta? No. The 1.4 is not even branched yet. But as I said trunk is very good. Use it to get the latest features. I use it every day without problems.