I'm not sure it'll solve your problem, if you change automatically the focus for the StaticText controls. Because, as they won't receive the focus, the screen readers won't "see" them.
Attached a test program (see Test-FocusChange.zip) for a illustration, with 2 couples of StaticText/DBEdit controls: as soon as a StaticText control gets the focus, it sets it back to it's "associated" DBEdit control.
I don't know if and how it's possible to change the focus when entering in a StaticText control directly with the LCL. That's why I've used a Windows "hack" to do it instead.
Anyhow, NVDA (for instance) doesn't "see" the text of the StaticText controls when you are tabulating.
However, I've begun to look recently at the LCL to see how MSAA (i.e. Microsoft Active Accessibility) could be implemented in the LCL.
As a proof of concept, I've coded a "module tool" unit in order to not modify the LCL directly, just to make some tests.
As already indicated a few posts above, a first step for accessibility has already been implemented in the LCL. For instance, all TControl (and their descendants) have 3 major public accessible properties:
-AccessibleRole: to indicate push button, edit box, standard text, ...
-AccessibleValue: content for an edit text, a progress bar, ...
-AccessibleDescription: a comprehensive text for the corresponding control; like 'This button will terminate the application' for a push button that closes the program.
That's why I've tried to see how the existing "interesting" properties of the most common controls and these major public accessible properties could be mixed to give an final acceptable result. By "interesting" properties, I mean mainly:
-caption,
-hint,
-text (for edit or memo).
My main idea is:
-if Accessiblexxxx properties are filled, they are used in priority for the screen readers,
-if not, gets directly the necessary data for the screen readers from the standard control properties (i.e. those I've called above the "interesting" properties).
This way, even for applications that have not been designed specifically with accessibility on purpose, most of the data visible on the screen (included hints) could be available to the screen readers.
Unfortunately, it's still not terminated, but attached you can find a test program (see Test-WAccessibilityTmp.zip) with also a few StaticText and DBEdit controls for an illustration. DBEdit controls are not really "directly recognized" by my tool, but in fact it's absolutely not necessary to give extra informations about them to screen readers.
For instance, this sample illustrates 3 possible ways of giving extra pieces of information to the screen readers for the DBEdit controls:
-StaticText1 and DBEdit1: here, only DBEdit1 has a Hint property; this one will be read by the screen readers (so Static Text1 is not used),
-DBEdit2: similar to the DBEdit1, except that the AccessibleDescription property is used instead. DBEdit2 has both a Hint and an AccessibleDescription (see FormCreate for the AccessibleDescription value), but AccessibleDescription is used for screen readers instead of Hint,
-StaticText3 and DBEdit3: StaticText3 has an accelerator (Alt+S), and DBEdit3 is defined as its FocusControl property. So, the StaticText3 Caption and Hint are "associated" by my tool to DBEdit3; and they are automatically sent to the screen readers when you're entering DBEdit3.
I intend to write a small documentation to use my tool, but as I've written before it's not over yet, and so there is currently none.
But if you are interested at least for making some tests, I can make quickly a brief one. Anyway, using it is very simple and doesn't necessitate a lot of additional code; generally only 2 conditional instructions to add.
Even if you don't plan to use it, I'd be still very interested to get some feedbacks in the future (when it'll be finished of course). Because it's main purpose is to be a sort of a "draft" for my proposal of a future implementation of MSAA into the LCL.
Recent
