Hello all,
LCL applications can't be used by blind users. It's a bad news for blind programmers, but specially for blind users. It's a severe restriction if we regard it can occurs in the workplace.
Recently, I heard about a blind girls who couldn't access a desktop application. The developer makes an application wich returns a database query in a picture not readable for screen readers. The company doesn't have patience to search for another occupation for her. The consequence is that she will probably laid off.
I don't know if the application was writen in Lazarus. It's an example on what can happen when applications were designed without accessibilities concerns. It seems to be a little bit dramatical, but being blind, I can make sure the consequences are usually so unsuitable. And why is not LCL accessible? As I couldn't use it because the lack of accessibility, I don't know if this is the single problem. But as far as I could realize, the problem are the labels. If I have a label "name" and an editbox to fill up this information, label is not read. The labels of buttons and those used in dialog messages are not read as well. I tried to understand why the screen readers don't read it. The answer, for Windows system, was:

Two conditions need to be respected in order to provide information for screen readers. When using labels and editboxes in combination, it's necessary to set the mnemonic of label to point to the editbox. If I am right, it was done to set the property "control" of labels. Yes, it's important, but it's not sufficient. Screen readers query information by means of the windows event called wn_gettext. If LCL does not handle this event, it's not possible to provide information for screen readers.
So my ask is: does LCL handle this event?
I will do some tests in Linux to give you some feed back about accessibility.
Regards,
Luciano

Since the last time this topic came up the LCL was extended with the necessary basic (widgetset independant) code for accessibility handling. Currently only support for Mac OS X is implemented though. For further information please look here:
http://wiki.lazarus.freepascal.org/LCL_Accessibility

Regarding the two conditions you mentioned:
I don't know whether condition one is/can be satisfied, but condition two would be the platform dependant implementation of the accessibility interface that is still missing yet as mentioned above for Windows (and Linux).

Regards,
Sven

Luciano de Souza wrote

LCL applications can't be used by blind users.

That's a very generic statement and also only a half-truth. Many basic controls will work out of the box for accessibility, although many won't. I already improved a the accessibility of LCL-Carbon and am also working in the accessibility of LCL-CustomDrawn-X11 and LCL-CustomDrawn-Cocoa.

Also this discussion is high platform specific: Which operating system are you talking about?

Even if it were written in Lazarus, the problem in this specific case is not of Lazarus, but of the programer that wrote the program. It is a design flaw in the program which is unrelated to the library utilized to write it, since pictures by definition are not accessible without an alternative text.

And why is not LCL accessible?

Just the same answer as for every other questions of the kind: Why doesn't the LCL support feature Y?
Answer: Because there is no developer which contributed code to implement feature Y.

So my ask is: does LCL handle this event?

No, but patches to support it are welcome.

Am 06.08.2012 08:31 schrieb "Felipe Monteiro de Carvalho" <

: Also this discussion is high platform specific: Which operating system are you talking about?

Based on the fact that the author mentioned "handling a message" I would say that he is talking about Windows. If I'm not mistaken there isn't any Windows specific accessibility support yet, isn't it?

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120806/b644c0f7/attachment.html>

Yes, the title of my message is not correct and not fair. I have really mentioned a problem restricted to Windows system.
If I understand if the developer wants to provide accessibility to his or her application, he or she can handle special routines to do it. What is currently not possible is to have accessible native controls. Is this true?
It's a good news to know that the accessiblity in LCL is possible also to Windows. If there is no way to provide accessiblity, we would be undoubtedly worse. but in spite of the fact that accessiblity is perhaps possible in Windows, since it isn't native, only a few developers, interested in accessibility issues, will use these routines. The tru accessibility will exist when the native TLabel, TButton and the other LCL controls provide native accessibility.
So I ask: is there a schedule? Can blind Windows and Linux users have hopeness these features will be available in a short time?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120806/86a61fce/attachment.html>

Luciano de Souza wrote

If I understand if the developer wants to provide accessibility to his or her application, he or she can handle special routines to do it. What is currently not possible is to have accessible native controls. Is this true?

You could try the Qt widgetset in Windows. Maybe it will fare better for accessibility of the standard windowed controls, although it will not help anything for those controls which descend from TGraphicControl like TLabel.

You need to differentiate the kinds of controls which are available in the LCL and this wiki page is important for that:
http://wiki.lazarus.freepascal.org/Roadmap#Status_of_TCustomControl_based_controls_on_each_widgetset

Note that there are 3 kinds of controls:
*TGraphicControl descendents
*TCustomControl descendents
*native controls

Only native controls may possibly have their accessibility already implemented by the underlying toolkit (when one is utilized). For all others we need special code in the LCL to implement accessibility for them. This code is mostly just setting some properties which are then implemented in the general accessibility support for custom controls which is implemented for each widgetset separately and can handle any kind of custom control.

So I ask: is there a schedule? Can blind Windows and Linux users have hopeness these features will be available in a short time?

No, for sure it won't be working in a short time. I am working since a long time in getting accessibility working in Mac OS X and the process is very long and needs a lot of time to depurate all the small details and problems that appear.

There are multiple ways in which you can help, however.

The first step would be making a step-by-step guide of how to setup a free (as in zero cost) screen reader in Windows. Write the instructions in the wiki in this page:
http://wiki.lazarus.freepascal.org/LCL%20Accessibility#Screen_Readers

The second step would be start writing small applications which show how to use the MS accessibility APIs in Free Pascal: http://wiki.lazarus.freepascal.org/LCL%20Accessibility#Microsoft_Active_Accessibility

Hans-Peter Diettrich wrote

I don't think that X11 offers such support, because it has no such notion of "controls" - that's up to the widgetsets.

In Linux the library ATK offers support for accessibility regardless of the widgetset tecnology utilized. And it works fine with the system of 1 X11 handle per form.

The current Qt version (which AFAIK is not supported by the LCL?) uses only one Handle per form, so that the controls are not accessible (addressable) in the WinAPI.

The documentation of Qt says that it supports accessibility in Windows: http://doc.qt.nokia.com/4.7-snapshot/accessible.html

They have (or at least had till some time before Nokia sold it off) a lot of money, so I bet they could go at any lengths to implement their accessibility support, even if they had to create fake window handles only to get accessibility messages for every control.

This might be true for controls that are based on native controls like TEdit or TButton, but not for LCL-only controls like TLabel. So there special handling is needed and to make it as easy as possible for the application developer this needs to be handled by the LCL. Felipe has already implemented the base for this and a Mac OS X implementation. Implementations for GTK, Qt and Windows are still missing though.

Regards,
Sven

Windows doesn't deserve special support. Send a WM_GETTEXT message to a (windowed) control to get its text. I don't think that X11 offers such support, because it has no such notion of "controls" - that's up to the widgetsets.

DoDi

The current Qt version (which AFAIK is not supported by the LCL?) uses only one Handle per form, so that the controls are not accessible (addressable) in the WinAPI.

DoDi

On Windows all windowed controls (derived from TWinControl) are accessible through the WinAPI. IMO TLabel is the only text control without a window handle; this is by design and should not be changed. Graphic controls do not deserve a window handle, and thus are not normally accessible by the WinAPI.

DoDi