I am blind and use the NVDA screen reader with Libreoffice using the Java Access Bridge 2.0.2 to ensure accessibility. This setup has worked well in past versions of Libreoffice but seems to have broken with 3.5. The program acts as though JAB is not installed even though I have enabled assistive technology support in the Options dialog under Accessibility. without this working I am unable to navigate through menus and dialog boxes using NVDA.
Thanks for bugreport
Tested in 3.5.3 on Windows 7 32 bit, NVDA 2012.1
When I place mouse cursor on menu, it reads all items from File to Help. When I move mouse cursor on menu, click some item, nothing happens.
When I clicked some menu and appears submenu, then NVDA reads item only if cursor appears on item text, but not reads when cursor on icon that is to left from text in menu item.
NVDA nothing reads when cursor placed on tool in toolbar.
@ David Goldfield
Problem still persist?
Can confirm also affection x86-64 (AMD64) platforms.
While the NVDA screen reader (v 2012.1) is fully functional, LibreOffice v3.5.4rc2, appears to have Java Access Bridge dependencies preventing correct function of accessibility tools. The external NVDA screen reader will only read single lines from LO documents response to mouse actions, but NVDA "cursor selection" does not follow LO active text selection--believe accessibility support must be enabled to function correctly. Setting LO Tools -> Options --> Accessibility "Support assistive technology tools (program restart required) check box responds with message "LibreOffice 3.5 requires Java Access Bridge 1.0.3 or later version to support accessibility".
Install Oracle Java Access Bridge (v 2.0.2 - 2012/04/18)--Windows 7 sp1 64bit-- following manual setup instructions: http://docs.oracle.com/javase/accessbridge/2.0.2/setup.htm
Then setting LO Tools -> Options -> Accessibility "Support assistive technology tools.." check box causes LO to close with this Event log:
Faulting application name: soffice.bin, version: 184.108.40.206, time stamp: 0x4fbc7fd1
Faulting module name: MSVCR90.dll, version: 9.0.30729.6161, time stamp: 0x4dace5b9
Exception code: 0xc0000417
Fault offset: 0x0002e9f4
Faulting process id: 0x11e4
Faulting application start time: 0x01cd3cf3499d3855
Faulting application path: C:\Program Files (x86)\LibreOffice 3.5\program\soffice.bin
Faulting module path: C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_50934f2ebcb7eb57\MSVCR90.dll
With no Java Access Bridge -- accessibility plug-ins and external tools are not functional for a broad class of previously supported users.
Thats bad; make it a most-annoying bug.
[Libreoffice-accessibility] list thread from OP asking about usability of JAB 2.0.2 with LO 3.5.4 indicating he has been using JAB 2.0.2 with LO 3.5.3 and that original issues was resolved for him at 3.5.1--so that would have been the 45530 bug ( https://bugs.freedesktop.org/show_bug.cgi?id=45530 )
Asked on list that he provide configuration steps used to make JAB 2.0.2 function with LO 3.5.3 (and presumabbly 3.5.2, and 3.5.1) since following the Oracle installation and configuration is not functional at 3.5.4, regression of fix from 45530?
Currently setting up two Accessiblity enabled test systems (32bit and 64bit) to capture stack trace--but if there is a known work around, sure would like to heare it and modify this bug.
So if somone knows what the Accessibility community has been doing with the JAB under Windows--please pipe in.
I am not concerned about betas. But I think broken accessibility should normally prevent a final release from taking place. The only exceptions I can think of are that a patch or new release that breaks accessibility might be (barely) tolerable if it fixes a security or document corruption problem.
> I am not concerned about betas. But I think broken accessibility
> should normally prevent a final release from taking place.
We rely very substantially on user testing. If the brokenness is not detected until after the release, it is hard to retrospectively un-release it. People test what they care about - if no-one is testing a11y support on Windows before releases and you care about this - then it'd be great to have you step in to volunteer to do that.
The closer the breakage is detected to the point where it broke, the quicker and easier it is for us to fix. As of now - it's not easy to isolate where the problem is, and we have no stack trace - as/when we have that it shouldn't be too hard to fix. It is also now marked a 'Most Annoying' bug (one of ~70 or so) so has the highest visibility possible.
NVDA works as expected, and others have reported that JAWS and DOLPHIN are working correctly with JAB 2.0.2 on LO 3.5.4
I have marked as NOTABUG, and it should be removed from most annoying bugs [https://bugs.freedesktop.org/show_bug.cgi?id=37361]
The cause of my original LO 3.4.4rc2 crash remains unknown, but I suspect it was related to incomplete Java Access Bridge configuration. I have now installed JAB 2.0.2 on multiple 32-bit and 64-bit instances Windows 7 with LO 3.5.4
Side notes to the issue of working with JAB and the Accessibility tools in Windows:
(1) The manual JAB install instructions provided by Oracle are tedious--and error prone. Yes they got me twice!
The Accessibility user community on MS Windows OS has embraced a FOSS (GNU LGPL) contribution by Jamal Mazrui, JWin-- http://empowermentzone.com/JWin.htm -- JWin is built on the Inno installer (by Jordan Russle) and performs a Java JRE validation and installation if needed along with an installation of Java Access Bridge 2.02, the JWin installation script follows Oracles steps and the scripted results are functional.
(2) In reviewing OpenGrok for this issue--noted a number of inconsistencies with current Windows installation from the legacy OpenOffice Java Framework configurations.
Libre Office Windows installer no longer lays down user Windows Registry values. Configurations per user are controlled from the "registrymodifications.xcu" file placed in the %APPDATA%\LibreOffice\3\User folder. That is functional, but a number of the Windows registry hooks remain including this note from the /core/jvmfwk/source/framework.cxx
287 #ifdef WNT
288 //Because on Windows there is no system setting that we can use to determine
289 //if Assistive Technology Tool support is needed, we ship a .reg file that the
290 //user can use to create a registry setting. When the user forgets to set
291 //the key before he starts the office then a JRE may be selected without access bridge.
292 //When he later sets the key then we select a JRE with accessibility support but
293 //only if the user has not manually changed the selected JRE in the options dialog.
294 if (jfw::isAccessibilitySupportDesired())
So with no Registry value, it looks like the isAccessibilitySupportDesired(), and its related routines from
--isAccessibilitySupportDeisred(), GetEnableATToolSupport() and SetEnableATToolSupport()--are all orphaned. The ".reg" file method that OpenOffice deployed for users needing to toggle on AT support is not functional.
What that means now for users is an edit of the user's "registrymodification.xcu", or use of the GUI Tools --> Options --> Accessibility --> Support Assistive Technology Tools (program restart required) can a user toggle on support for Assistive Technologies.
Unfortunately either task is exceedingly difficult for the sight impaired--the practice being dependence on keyboard shortcuts of: <alt>t, o, a, a, <tab>, <space>(to toggle). It seems like there should be a better way to enable Assistive Technologies, e.g. https://bugs.freedesktop.org/show_bug.cgi?id=39803 or some other mechanism.
Windows exception code c0000417 and offset 0002e9f4 in msvcr90.dll indicate this is a duplicate of Bug 38913.
*** This bug has been marked as a duplicate of bug 38913 ***