LibreOffice uses an internal API for accessibility. On Windows, this API is mapped to the Java Accessibility API through a kind of bridge. Unfortunately, the Java Accessibility API is badly supported by screen readers on Windows (JAWS, Window-Eyes, the open source NVDA, etcetera). Implementing IAccessible2 (developed by IBM and donated to the Linux Foundation, <http://www.linuxfoundation.org/collaborate/workgroups/accessibility/iaccessible2>), would improve access for screen readers. Note: IBM donated code that implemented IAccessible2 in OpenOffice.org to Oracle. Integration and testing were still in progress when Oracle decided to give OpenOffice.org to the community, so the IAccessible2 code is not available yet. Since IBM's decision to donate a large part of their Lotus Symphony code, it is uncertain that this IAccessible2 code will become available: if OpenOffice.org moves to the Lotus Symphony user interface, this piece of bridge code will become irrelevant.
Update on IAccessible2 code for/from OpenOffice.org: The child workspaces at http://hg.services.openoffice.org/ contain the code. Malte Timmermann, who worked on this for Oracle, sent a message about this to the LibreOffice Accessibility list: <http://listarchives.libreoffice.org/global/accessibility/msg00163.html> Summary: * accfixes2: ready for QA; was meant to be integrated *after* OOo 3.4, to make sure the new accessibility code doesn't break Accessibility on some other platform. * accia2bridge: not critical to integrate: it is Windows-only - UAA IA2 bridge - and can't break anything on other platforms; removes the Java Accessibility stuff on Windows, so better do this as the last step. * accfixes3 was intended to be the last CWS with IA2 stuff. * accstuff contains other changes, which would be either deleted or migrated to accfixes3 (accstuff was not meant to be integrated as such). * Integration into LibreOffice could cause many conflicts.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Dear bug submitter! Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs. To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem. Yours! Florian
Implementing IAccessible2 as viable alternative to continued dependence on Oracle Java Access Bridge remains a valid requirement to end Java JRE/URE dependenc in LO. Reinstate.
Okay, valid NEW enhacement...
(In reply to comment #0) > Unfortunately, the Java Accessibility API is badly supported by screen > readers on Windows (... the open source NVDA It's worth noting that we've done our best to support the Java Access Bridge (JAB) in NVDA. However, JAB is difficult for users to set up, enforces dependency on Java and has severe limitations and bugs as an API. To give one example, it's not possible to communicate a great deal of formatting information with JAB. Supporting IAccessible2 would definitely be a huge leap forward for LibreOffice accessibility and allows for future improvements not possible with JAB.
Yes moving to IAccessible2 should help in eliminating the JAB mappings of UNO Accessibility API. The IBM Symphony \winaccessibility contribution to Apache Open Office is tantalizingly close as a framework for achieving the IAccessible2 implementation--seems like we are just waiting for a IBM/Appache signoff on stamping the code contribution with the ALv2 license. I think though, that even if the licensing were released today, until work starts on LibreOffice 4.0 and Apache OpenOffice 4.0, the Windows OSs and NVDA will remain dependent on the Java Accessibility with Java Access Bridge mappings. So, I am curious if the JAB provided support is really that incomplete? Or is it just that it has lacked needed attention in both OpenOffice and LibreOffice implementations? The Java AWT/Swing components of Java Accessibility API seem pretty comprehensive, as do the UNO Accessibility a11y roles and trees. What I don't have a feel for is the fidelity of role mappings achieved by the JAB, and issues of exposing a documents accessibility tree to AT. Can emerging a11y ATK 3.0 efforts like the ATK::collection interface be implemented in UNO Accessibility and mapped across the JAB to the Java Accessibility API? As I reported in NVDA#2753 - ( http://www.nvda-project.org/ticket/2753 ) the JAB based implementations are loosing AT focus within an NVDA session. Several other structural issues with AT document trees and inadequacies of UNO Accessibility roles suggest there is considerable room to improve how UNO Accessibility in general annotates elements with accessibility details. And while the scrub in preparation for LOdev 4.0 and AOoDev 4.0 begins, it would make sense to put some work into improving UNO Accessibility mappings into Java Accessibility API across the JAB. https://bugs.freedesktop.org/show_bug.cgi?id=35652 https://bugzilla.gnome.org/show_bug.cgi?id=345750 https://bugzilla.gnome.org/show_bug.cgi?id=652548 https://bugs.freedesktop.org/show_bug.cgi?id=36549
Work to implement IAccessible2 in Apache OpenOffice is under way. Part of it was done before the release of OpenOffice 4.0 (a snapshot from February 2013 is still available at https://people.apache.org/~steve_y/ia2snapshots/), but it is now part of the OpenOffice 4.1 release plans; see https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1+Release+Planning.
The corresponding Apache bug is https://issues.apache.org/ooo/show_bug.cgi?id=107914. (With a bug about a Feb 2013 QA build at https://issues.apache.org/ooo/show_bug.cgi?id=121833.)
The last elements of the AOO \winaccessibility IAccessible2 implementation have received ALv2 licensing annotation with rev 1536599 ( http://svn.apache.org/viewvc?view=revision&sortby=date&revision=1536599 ) as the ia2 branch is being prepared to merge with AOO trunk for a 4.1 release. This should allow LibreOffice review and possible adoption of the IBM contributed implementation of the IAccessibile2 IDL for use as a native bridge between the UNO Accessibility API and AT on Windows clients. This is good news as we've been waiting for this for a while. Just hope someone has the energy to migrate the svn branch to git and start the process.
So David O. has taken the plunge and spun off an ia2 feature--KUDOS! http://cgit.freedesktop.org/libreoffice/core/log/?h=feature/ia2 Looking at the commits noticed that a few of the source files retained IBM copyright and LGPLv3 markings all from /offapi/com/sun/star/accessibility : MSAAService.idl XAccessibleExtendedAttributes.idl XAccessibleGroupPosition.idl XAccessibleTableSelection.idl XAccessibleTextSelection.idl XMSAAService.idl Is that a problem for anyone until the tags get cleaned up over on the AOO side? @David - I'd be happy to help you test the feature(s) prior to its adoption and move into master, but I would need a link to your build when you get to that point.
It's worth noting that there are still quite a few bugs in the AOO IA2 implementation, some of them rather severe. The AOO IA2 work will need to be watched closely for fixes over the coming months and those fixes merged into the LO work.
(In reply to comment #15) >... The AOO IA2 work will need to be > watched closely for fixes over the coming months and those fixes merged into > the LO work. Even sooner, as the AOO folks yesterday brought in the current Linux Foundation A11y IAccessible2 IDL v1.3 ( URL http://accessibility.linuxfoundation.org/a11yspecs/ia2/ia2_api_all.idl ) and have refactored the ia2 branch to use it.
UAA to IAccessible2 native bridge, not there yet... On Windows 7 sp1 64-bit en-US Version: 4.2.0.0.alpha1+ Build ID: 73342dbb82ba074d01962359dac50fb2aa36cbeb TinderBox: Win-x86@39, Branch:master, Time: 2013-11-22_07:08:35 Working with the TB-39 build that had "--enable-ia2" configuration, I could not activate the UAA to IAccessible2 bridge from Tools --> Options --> Advanced "enable experimental features" with or without an environment variable of SAL_FORCE_IACCESSIBLE2 = 1. Also, without the "enable experimental features" set, I could not enable the Java Accessibility Bridge based support for assistive technology tools. Tested with both msiexec.exe /a administrative, and full msiexec.exe /i command line with a WRITE_REGISTRY=1 install. Neither could be made to function correctly with ia2 or JRE w/JAB based AT. Even made manual stanza entry into the of the LibreOffice registry registrymodifications.xcu -- <item oor:path="/org.openoffice.VCL/Settings/org.openoffice.VCL:ConfigurableSettings['Accessibility']"> <prop oor:name="EnableATToolSupport" oor:op="fuse" oor:type="xs:string"><value>[true]</value></prop></item> Setting SAL_ACCESSIBILITY_ENABLED environment variable had no affect, and manual entry of EnableATToolSupport was cleared from registry with each launch of LibreOffice.
IN the context of implementing this final native UAA bridge for Windows, eliminating? the JAB kludge, could we revisit enabling support for AT Tools by default (gone the performance impact of the UAA <-> JAB <-> JRE JAA performance hit)--and allow the individual ATs to manipulate NS Accessibility, ATK AT-SPI, and MSAA/IAccessible2 as needed? FDO# Bug 39803 and bug 39833 are germane.
> IN the context of implementing this final native UAA bridge for Windows, > eliminating? the JAB kludge, could we revisit enabling support for AT Tools > by default (gone the performance impact of the UAA <-> JAB <-> JRE JAA > performance hit)--and allow the individual ATs to manipulate NS > Accessibility, ATK AT-SPI, and MSAA/IAccessible2 as needed? Sure - so, ATK integration is already on by default if a11y is on by default [IIRC] - although that has some -hideous- performance impacts too IIRC, so maybe we vacillated on that; I'm not eager to see a 5+ second slower start for everyone to avoid a single a11y key ;-) [ and IIRC the GNOME guys decided to turn on a11y everywhere too and the decided against it ]. So my take is that - as long as it's not turned on on the desktop by default, it makes sense for us to enable by default as/when it's turned on globally. Either way - the state (as of when I last touched it) was that if Experimental mode is on, and IAcc2 is working - then we auto-enable it - and clobber the UI setting. Of course we should prolly yank out the UI setting in this case as well - but I was curious about the Mac situation. If (as I recall) Mac a11y is a bridge built-into the core/vcl then as/when we have IAcc2 working properly we should prolly just drop the JAva bridge, and the setting, and default it to on as/when anyone wants it ;-) Does that help ? =)
(In reply to comment #19) > > ... could we revisit enabling support for AT Tools > > ... --and allow the individual ATs to manipulate NS > > Accessibility, ATK AT-SPI, and MSAA/IAccessible2 as needed? > > Sure - so, ATK integration is already on by default if a11y is on by default > [IIRC] - although that has some -hideous- performance impacts too IIRC, so > maybe we vacillated on that; I'm not eager to see a 5+ second slower start > for everyone to avoid a single a11y key ;-) [ and IIRC the GNOME guys > decided to turn on a11y everywhere too and the decided against it ]. > > So my take is that - as long as it's not turned on on the desktop by > default, it makes sense for us to enable by default as/when it's turned on > globally...- but I was curious about the Mac situation. > > If (as I recall) Mac a11y is a bridge built-into the core/vcl then as/when > we have IAcc2 working properly we should prolly just drop the JAva bridge, > and the setting, and default it to on as/when anyone wants it ;-) @Joanmarie, @Boris -- any thoughts as now would be a good time to review the status quo?
On Windows 7 sp1 64-bit NVDA 2013.2 Accprobe 1.2.1.1 Version: 4.3.0.0.alpha0+ Build ID: e3b7e62b0dc34787f66c504230252b2c5edd18c3 TinderBox: Win-x86@39, Branch:master, Time: 2013-11-23_14:43:54 Success, we have a working IAccessible2 based bridge to UAA! So while the 2013-11-21 04:17 GMT pull for 4.2.0.0 beta1 build has issues -- see bug 71946 --today's TB-39 build of master provides good UAA to IAccessible2 bridge support when launched with the experimental features enabled. --Windows environment variables-- SAL_ACCESSIBILITY_ENABLED=1 SAL_FORCE_IACCESSIBLE2=1 --LibreOffice registry-- set from Tools --> Options --> Advanced "enable experimental features" <item oor:path="/org.openoffice.Office.Common/Misc"><prop oor:name="ExperimentalMode" oor:op="fuse"><value>true</value></prop></item> Unfortunately, I could no longer get the Java Access Bridge based AT tool support to enable.
(In reply to comment #21) > Version: 4.3.0.0.alpha0+ > Build ID: e3b7e62b0dc34787f66c504230252b2c5edd18c3 > TinderBox: Win-x86@39, Branch:master, Time: 2013-11-23_14:43:54 > > Success, we have a working IAccessible2 based bridge to UAA! it is odd that this build works for you - it shouldn't, because it fails to instantiate the COM components. unless you somehow managed to register the UAccCOM.dll in the registry with regsvr32.exe. you can search with regedit.exe for UAccCOM.dll to verify. perhaps you have some AOO installed on the same system that did register its dll? loading that from LO could actually work :) anyway the problem should be fixed in current builds with commit 732ec36edfd09d2091d70c4d71b5f182fe279c45
(In reply to comment #22) > it is odd that this build works for you - it shouldn't, because it > fails to instantiate the COM components. > > unless you somehow managed to register the UAccCOM.dll in the registry > with regsvr32.exe. you can search with regedit.exe for UAccCOM.dll > to verify. Yes, in working with it I'd run a regsvr32 against the UAccCOM.dll per Michale M's note in http://opengrok.libreoffice.org/xref/core/winaccessibility/README#42 guess those notes might need to be adjusted. And when I unregister UAccCOM.dll -- Build ID: e3b7e62b0dc34787f66c504230252b2c5edd18c3 TinderBox: Win-x86@39, Branch:master, Time: 2013-11-23_14:43:54 stops exposing IAccessible2 events--showing MSAA only. > > anyway the problem should be fixed in current builds with commit > 732ec36edfd09d2091d70c4d71b5f182fe279c45 Yes, it appears to be. Thanks! Reliable exposure of ia2 events in accprobe with /a admin install of the 2013-11-24 build containing the last of your winaccessibility commits, and no other registry or user profile actions other than enabling "experimental features", on Windows 7 sp1, 64-bit with: Version: 4.3.0.0.alpha0+ Build ID: 732ec36edfd09d2091d70c4d71b5f182fe279c45 TinderBox: Win-x86@39, Branch:master, Time: 2013-11-24_00:16:51 Will of course see how it goes tomorrow when we can get hold of the refactored COM CoCreateInstance https://gerrit.libreoffice.org/#/c/6792/ as 3b86569fcba210eb6570fabef7ff8abf6aff91f0 on TB-39. Notice that Thorsten B. has a TB-42 instance for 4.2.0.0beta1+ up, but that it is being built without "--enable-ia2" configs--will poke him about adding that to the TB.
On Windows 7 sp1, 64-bit Version: 4.3.0.0.alpha0+ Build ID: b32651febdaad5939250fb04f721d88952f54732 TinderBox: Win-x86@39, Branch:master, Time: 2013-11-26_00:09:34 Still could not enable JRE w/JAB AT tool support Enabling "experimental features" activates IAccessible2 AT support. Should there be an effort to reestablish JRE w/JAB AT support? Or, should it be cut in favor of the native ia2 bridge and focus on UI refinements there?
> Still could not enable JRE w/JAB AT tool support And it worked before I assume ? :-) if so, that's a bug. Is the accessbridge jar file present ? if you export SAL_DISABLE_IACCESSIBLE2=1 - does that make it work for you ? If you read: http://cgit.freedesktop.org/libreoffice/core/tree/vcl/source/app/svdata.cxx#n301 it's hard to see how it won't fall back to where it was before =) I assume you've turned on a11y in the options page for the Java mode ? > Enabling "experimental features" activates IAccessible2 AT support. Great.
(In reply to comment #24) > On Windows 7 sp1, 64-bit > > Version: 4.3.0.0.alpha0+ > Build ID: b32651febdaad5939250fb04f721d88952f54732 > TinderBox: Win-x86@39, Branch:master, Time: 2013-11-26_00:09:34 > > Still could not enable JRE w/JAB AT tool support > > Enabling "experimental features" activates IAccessible2 AT support. > > Should there be an effort to reestablish JRE w/JAB AT support? Or, should it > be cut in favor of the native ia2 bridge and focus on UI refinements there? JAB AT support is going to be discontinued in one of the next LO releases. How is the fidelity of the native ia2 bridge events in current master? What is still missing before we can kill JAB?
(In reply to comment #25) > > Still could not enable JRE w/JAB AT tool support > > And it worked before I assume ? :-) if so, that's a bug. Is the accessbridge > jar file present ? if you export SAL_DISABLE_IACCESSIBLE2=1 - does that make > it work for you ? If you read: > http://cgit.freedesktop.org/libreoffice/core/tree/vcl/source/app/svdata. > cxx#n301 it's hard to see how it won't fall back to where it was before =) I > assume you've turned on a11y in the options page for the Java mode ? > I was never able to bring up the JAB based a11y once the ia2 was merged, we had a brief lapse in the TB's when your VCL work on David O's start was not available. Then Michale S.'s and Stephan B.'s refactoring were pushed. That's when I finally got a got at it on a TB-39 build--and JAB is kaput. Same once the ia2 bridge build was activated on the TB-42 build of LODev 4.2.0.0beta1+, JAB goes away. (In reply to comment #26) > > Should there be an effort to reestablish JRE w/JAB AT support? Or, should it > > be cut in favor of the native ia2 bridge and focus on UI refinements there? > > JAB AT support is going to be discontinued in one of the next LO releases. > How is the fidelity of the native ia2 bridge events in current master? What > is still missing before we can kill JAB? The ia2 bridge is already miles beyond fidelity of the JAB. There are some nuisance issues like bracketing keyboard F6 key "sub-menues", and <TAB> vs. Cursor (U,D,L,R) movement blocks for the newer UI widget based GUI. But we are already doing much better than JAB was ever able to accomplish. Following the refactoring, Caolán has continued to work through some residuals of the AOO trunk source. So it looks like we've got the bridge in pretty good shape. I'd encourage anyone to download a seat of NVDA 2013.2 and see just where we are at. I've had solid useable IAccessible2 based AT on Windows 7 sp1 64-bit, and Windows 8 64-bit with today's build. But I did have to install MSVC++2012 32-bit runtimes. I got useable AT on Windows XP, but with NVDA AT running was getting "Fatal error: Caught unknown exceptiong: Aborting" will poke at that tomorrow to see if I can get more details on the crash. msiexec.exe /a admin installs of: Version: 4.3.0.0.alpha0+ Build ID: b32651febdaad5939250fb04f721d88952f54732 TinderBox: Win-x86@39, Branch:master, Time: 2013-11-26_00:09:34 At this point, I'd have no concern about dumping the JAB based AT, and putting any additional effort into refining the XAccessible roles and keyboard interface with the native bridge.
(In reply to comment #27) > > At this point, I'd have no concern about dumping the JAB based AT, and > putting any additional effort into refining the XAccessible roles and > keyboard interface with the native bridge. I have working IA2 based AT verified with latest NVDA and "Delete JAB" patch applied [1]. Tested on Win7 64 bit, MSVC 2010, debug build. Can we have a go for merging that patch to master? [1] https://gerrit.libreoffice.org/6819
David Ostrovsky committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=130833f80e89774269108cf30b2d1155a00354ce fdo#39956 Delete JAB The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Updated the wiki page [1] with JAB discontinuation details. No experimental mode any more. @Stuart: have you tried recent master build after JAB deletion? Does it make sense to close this issue? [1] https://wiki.documentfoundation.org/Development/ia2
@David, (In reply to comment #30) > @Stuart: have you tried recent master build after JAB deletion? Does it make > sense to close this issue? > > [1] https://wiki.documentfoundation.org/Development/ia2 Not yet, the 2013-12-05 TB39 build was at commit dfd1a47a38dac743f9ed0f1e9507714bac027d35, the builds with JAB removed should start tomorrow. Will install those and see how we do. Also, we'll need to get the whole slate of IAccessible2 commits pushed down to the 4.2.0 branch as well--not sure that they all have been cherry picked. Stuart
judging from the log Michael S merged it to libreoffice-4-2 already =)
The IAccessible2 interface has been implemented as an experimental feature for LibreOffice 4.2.0 release, and will enable when an AT is set active. Existing Java Access Bridge (JAB) based AT remains in place as default. The two can be toggled by use of the Enable experimental features check box. For builds of master 4.3.0alpha0, the Java Access Bridge based AT for Windows has been removed in favor of IAccessible2. Setting Resolved Fixed.
Andras Timar committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/help/commit/?id=400d3515694ff3857f253c8da9ea44b962161ee0 fdo#39956 delete Java Access Bridge from help The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.