Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2014-06

Accessibility of Lazarus

9 messages · 4 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Grzegorz Zlotowicz

Hi all.
I'm Greg from Poland, a blind computer user and programmer. Looking for an advanced multi-platform framework to work with FPC, the Lazarus seems obvious choice, but unfortunately it has some accessibility problems. After reading the
http://wiki.freepascal.org/LCL_Accessibility
I decided to write here about it, because maybe it'll be possible to fix the issues.
I'm using the NVDA screen-reader (www.nvda-project.org), and working under Windows (currently win7, but in xp the problems were the same, as I tested it some time ago).
Starting from simplest thing:
I compiled the bitbutton program in the examples directory. The radio buttons, and their group names ("kind" and "layout") are read perfectly well.
But the problem is the button itself.
In the source, it has a "close" caption, but it is not announced by screenreader, although its' role as button is correctly recognized. After setting the properties Accessiblevalue and accessibledescription to 'close', nothing changes.
The same problem has all buttons in Lazarus IDE, and also programs build using Lazarus.
Is there some possibility of solving the problem (I mean somebody knowleable and willing to do it)? Knowing Pascal, I don't know where to start debugging this thing.
I hope, that these problems can be rather easy to fix, and if it'd happen, it would make world easier for many people (not only programmers, but also all blind users of programs written using LCL).

The treeviews aren't accessible nearly at all (all items are read by the screenreader at the same time without identication which one is selected, or which collapsed); listboxes seems to work well. But returning to the simplest button.
the fragment of the NVDA's log says about this control:

name: u''
role: ROLE_BUTTON
states: STATE_FOCUSABLE, STATE_FOCUSED
isFocusable: True
hasFocus: True
description: None
value: None
windowHandle: 32703706
windowClassName: u'Button'
windowText: u''
displayText: u''
IAccessible event parameters: windowHandle=32703706, objectID=-4, childID=0 IAccessible accName: None
IAccessible accRole: ROLE_SYSTEM_PUSHBUTTON
IAccessible accState: STATE_SYSTEM_DEFAULT, STATE_SYSTEM_FOCUSED, STATE_SYSTEM_FOCUSABLE, STATE_SYSTEM_VALID (1048836) IAccessible accDescription: None
IAccessible accValue: None

Greetings, Greg.

Hans-Peter Diettrich
to Grzegorz Zlotowicz
Show quoted text 20 lines
the fragment of the NVDA's log says about this control: name: u'' role: ROLE_BUTTON states: STATE_FOCUSABLE, STATE_FOCUSED isFocusable: True hasFocus: True description: None value: None windowHandle: 32703706 windowClassName: u'Button' windowText: u'' displayText: u'' IAccessible event parameters: windowHandle=32703706, objectID=-4, childID=0 IAccessible accName: None IAccessible accRole: ROLE_SYSTEM_PUSHBUTTON IAccessible accState: STATE_SYSTEM_DEFAULT, STATE_SYSTEM_FOCUSED, STATE_SYSTEM_FOCUSABLE, STATE_SYSTEM_VALID (1048836) IAccessible accDescription: None IAccessible accValue: None

It looks to me like the WNDCLASS and/or WNDPROC of the control lacks support for the Name, WindowText and DisplayText fields or methods. E.g. for the WindowText the WNDPROC should react on WM_GETTEXT messages. The NVDA developers should know more about how they try to obtain above properties from a window handle.

The fix depends on the handling of the WNDCLASS.WNDPROC in the Lazarus widgetsets, at both designtime and runtime. In either case this WNDPROC should react properly on WM_GETTEXT, i.e. return the Text or Caption string (PCHAR) associated with the control. The LCL gurus should be able to find out why this doesn't work as expected.

A test program can enumerate the window handles, associated with a running Lazarus IDE or some Lazarus application, and output the result of WM_GETTEXT for each handle. More tests can be added for the other properties retrieved by NVDA (selected state...).

It would be helpful if you supply the Lazarus version and widgetset which you are using, and whether you use a 32 or 64 bit Lazarus and Windows. A screen reader finally should be able to retrieve all required values in all these combinations.

Did you also try other than the Win32 widgetset in building the IDE or applications, with possibly different results in your screen reader?

DoDi

Grzegorz Zlotowicz
to Hans-Peter Diettrich: It looks to me like the WNDCLASS and/or WNDPROC of the control lacks support for the…

Hi.
Unfortunately, I can't switch widgetset for bitbutton project. After spending about an hour or more in the project options dialog, I can achieve nearly everything (using keyboard or build-in in the screen-reader virtual mouse emulation), but with no success about widgetset, and in general any macro definitions.
According to:
http://wiki.lazarus.freepascal.org/IDE_Window:_Compiler_Options I hope that this macros grid should exist somewhere in the compiler options, or on the build modes dialog.
Unfortunately although I managed to add the debug and release modes, I can not in any way access the macros grid.
I'm using:
lazarus-1.2.4-fpc-2.6.4-win32

Returning to the accessibility:
the wm_gettext message result is defined in the windowText field of quoted log, but instead relying only on winapi, NVDA tries to use MSAA or IAccessible interfaces, which give much more (for example possibility of reacting to events of control changing state, without querying it continously and comparing with previous state).

Greetings, Greg.

W dniu 2014-06-28 08:46, Hans-Peter Diettrich napisa?/a:

Show quoted text 60 lines
Grzegorz Zlotowicz schrieb: > the fragment of the NVDA's log says about this control: > > name: u'' > role: ROLE_BUTTON > states: STATE_FOCUSABLE, STATE_FOCUSED > isFocusable: True > hasFocus: True > description: None > value: None > windowHandle: 32703706 > windowClassName: u'Button' > windowText: u'' > displayText: u'' > IAccessible event parameters: windowHandle=32703706, objectID=-4, > childID=0 > IAccessible accName: None > IAccessible accRole: ROLE_SYSTEM_PUSHBUTTON > IAccessible accState: STATE_SYSTEM_DEFAULT, STATE_SYSTEM_FOCUSED, > STATE_SYSTEM_FOCUSABLE, STATE_SYSTEM_VALID (1048836) > IAccessible accDescription: None > IAccessible accValue: None It looks to me like the WNDCLASS and/or WNDPROC of the control lacks support for the Name, WindowText and DisplayText fields or methods. E.g. for the WindowText the WNDPROC should react on WM_GETTEXT messages. The NVDA developers should know more about how they try to obtain above properties from a window handle. The fix depends on the handling of the WNDCLASS.WNDPROC in the Lazarus widgetsets, at both designtime and runtime. In either case this WNDPROC should react properly on WM_GETTEXT, i.e. return the Text or Caption string (PCHAR) associated with the control. The LCL gurus should be able to find out why this doesn't work as expected. A test program can enumerate the window handles, associated with a running Lazarus IDE or some Lazarus application, and output the result of WM_GETTEXT for each handle. More tests can be added for the other properties retrieved by NVDA (selected state...). It would be helpful if you supply the Lazarus version and widgetset which you are using, and whether you use a 32 or 64 bit Lazarus and Windows. A screen reader finally should be able to retrieve all required values in all these combinations. Did you also try other than the Win32 widgetset in building the IDE or applications, with possibly different results in your screen reader? DoDi -- _______________________________________________ Lazarus mailing list http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Grzegorz Zlotowicz
to Bart: AFAIK for TBitBtn an attempt was made to make it work, but this lead to visual anomalies…

Hi.
As I wrote a moment ago in previous message, the problem is not the wm_getwindowtext itself, but the underlying accessibility object. http://wiki.freepascal.org/LCL_Accessibility
states, that:
LCL developers need to provide accessibility for all TCustomControl descendents in the LCL and also for all non-windowed controls in the LCL (such as TLabel).

So the right thing seems to be setting up the accessible object for this non-standard control, and everything should work.
But, as I mentioned - after trying to set AccessibleDescription for the bitbutton didn't work, so I suppose that the implementation of accessible object may be somehow incomplete for bitbutton.

By the way - the mentioned wiki page says about testing the accessibility using screen-reader, but it lists only Voice Over for Macos x, and Orca for Linux, but says nothing about NVDA for Windows, which is advanced, free and open-source screen reader, and possibly most important - it can be placed on the computer as a portable version, not changing anything in the system settings. So for testing suggested by the Wiki page, it can be activated for a moment, and turned off when not needed anymore.

Greetings, Greg.
W dniu 2014-06-28 14:48, Bart napisa?/a:

Show quoted text 12 lines
AFAIK for TBitBtn an attempt was made to make it work, but this lead to visual anomalies (double captions on the button) and was reverted. Bart -- _______________________________________________ Lazarus mailing list http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Hans-Peter Diettrich
to Grzegorz Zlotowicz: Hi. Unfortunately, I can't switch widgetset for bitbutton project. After spending about…
Show quoted text 6 lines
Returning to the accessibility: the wm_gettext message result is defined in the windowText field of quoted log, but instead relying only on winapi, NVDA tries to use MSAA or IAccessible interfaces, which give much more (for example possibility of reacting to events of control changing state, without querying it continously and comparing with previous state).

I didn't know of existing accessibility support yet, very interesting :-)

DoDi

Lubos Pintes
to Grzegorz Zlotowicz: Hi all. I'm Greg from Poland, a blind computer user and programmer. Looking for an…

Hi Greg and all,
A long time ago, (more than one year I think), I researched about accessibility in Lazarus.
Unfortunately I just noticed that I lost, or totally forgot almost everything about this subject :).
But I remembered the following.
- There is very basic TLazAccessible object implementing properties like Accessible{Name,Value,Role,Description}, but the object is abstract in the sense that a concrete implementation must be created for concrete widget set.

- The above-mentioned properties are just very basic thing even if fully implemented, perhaps enough for things like Button, but absolutely insufficient for more complex things like tree views.

- The accessibility framework could be designed first, at least on Windows we need the concept of accessible children, structural navigation like next/previous child, and event notification like something was changed/selected/created etc. This is completely missing in the mentioned abstract implementation.

- The framework could perhaps be based on IAccessible2. It has good support on Windows and perhaps also on Linux:
http://en.wikipedia.org/wiki/IAccessible2
http://www.linuxfoundation.org/collaborate/workgroups/accessibility/iaccessible2

- This would allow us to implement the good support even for code editor (IAccessibleText etc.).

- There is only something implemented for MacOS X. So setting accessible properties on Windows just does nothing.

D?a 27. 6. 2014 20:50 Grzegorz Zlotowicz wrote / nap?sal(a):

Show quoted text 62 lines
Hi all. I'm Greg from Poland, a blind computer user and programmer. Looking for an advanced multi-platform framework to work with FPC, the Lazarus seems obvious choice, but unfortunately it has some accessibility problems. After reading the http://wiki.freepascal.org/LCL_Accessibility I decided to write here about it, because maybe it'll be possible to fix the issues. I'm using the NVDA screen-reader (www.nvda-project.org), and working under Windows (currently win7, but in xp the problems were the same, as I tested it some time ago). Starting from simplest thing: I compiled the bitbutton program in the examples directory. The radio buttons, and their group names ("kind" and "layout") are read perfectly well. But the problem is the button itself. In the source, it has a "close" caption, but it is not announced by screenreader, although its' role as button is correctly recognized. After setting the properties Accessiblevalue and accessibledescription to 'close', nothing changes. The same problem has all buttons in Lazarus IDE, and also programs build using Lazarus. Is there some possibility of solving the problem (I mean somebody knowleable and willing to do it)? Knowing Pascal, I don't know where to start debugging this thing. I hope, that these problems can be rather easy to fix, and if it'd happen, it would make world easier for many people (not only programmers, but also all blind users of programs written using LCL). The treeviews aren't accessible nearly at all (all items are read by the screenreader at the same time without identication which one is selected, or which collapsed); listboxes seems to work well. But returning to the simplest button. the fragment of the NVDA's log says about this control: name: u'' role: ROLE_BUTTON states: STATE_FOCUSABLE, STATE_FOCUSED isFocusable: True hasFocus: True description: None value: None windowHandle: 32703706 windowClassName: u'Button' windowText: u'' displayText: u'' IAccessible event parameters: windowHandle=32703706, objectID=-4, childID=0 IAccessible accName: None IAccessible accRole: ROLE_SYSTEM_PUSHBUTTON IAccessible accState: STATE_SYSTEM_DEFAULT, STATE_SYSTEM_FOCUSED, STATE_SYSTEM_FOCUSABLE, STATE_SYSTEM_VALID (1048836) IAccessible accDescription: None IAccessible accValue: None Greetings, Greg. -- _______________________________________________ Lazarus mailing list http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Grzegorz Zlotowicz
to Bart

Returning to the subject...
The advantage of making accessibility of Lazarus working, would solve such problems as described below unsuccessfull attempt to make BitBtn accessible by setting its' Windowtext...
The Accessibility layer is independent from visual layer, so the window can be drawn in anyway you like, and if the Iaccessible object would return proper values to the screen-reader, everything would look as it should, and be accessible too...
I found following interesting example how to implement MSAA/IAccessible(IAccessible2 is an extended and multi-platform version of MSAA) in Delphi, didn't tested yet under Freepascal, also have no idea at the moment, how to incorporate it into Lazarus, even in the most simplest form letting the BitBtn name be read correctly... http://stackoverflow.com/questions/16320914/creating-accessible-ui-components-in-delphi

Greetings, Greg.
W dniu 2014-06-30 15:04, Bart napisa?/a:

Show quoted text 15 lines
On 6/28/14, Bart wrote: > AFAIK for TBitBtn an attempt was made to make it work, but this lead > to visual anomalies (double captions on the button) and was reverted. See: http://bugs.freepascal.org/view.php?id=24135 Bart -- _______________________________________________ Lazarus mailing list http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus