Screen reader users (and users of other assistive technologies) can enable support for assistive technologies by checking the option "Support assisitve technology tools" under Tools > Options > Accessibility. However, this option is unchecked by default and therefore almost impossible to find for blind users. (This default value may have to do with performance, but I could not find a source for this statement.) Procedure to reproduce the issue on Windows XP: * Install the open-source screen reader NVDA (www.nvda-project.org). * Install the Java Access Bridge (required for Java applications, and for applications that use the Java Accessibility API, like OOo and LibO on Windows) * Start NVDA * Using only the keyboard (TAB and arrows), go to Tools > Options > Accessibility in LibreOffice; notice that NVDA speaks some of the items but not all, so blind users need to guess or need to be told where the checkbox is. Please add the option "Support assisitve technology tools" to one of the steps of the installer. The installer seems to be more accessible than the other UI on Windows.
[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
Version info was previously unspecified. I confirm that this functionality is not present in the Windows installer for LibreOffice 3.5.0 RC1. Changing the status from NEEDINFO to NEW.
I wrote a patch. It sets SAL_ACCESSIBILITY_ENABLED=1 environment variable from the installer. But when I tested it, I was a bit confused. NVDA reads LibreOffice screens with and without this environment variable. In Options - LibreOffice - Accessibility panel, the Support assistive technology tools (program restart required) checkbox remains unchecked whatever I do. I mean I check it, and after program restart it is unchecked. I use jre-6u30, Java Access Bridge 2.0.2, NVDA 2012.1., and LibreOffice 3.6 (master) release configuration under Windows XP. However, when I tried to set SAL_ACCESSIBILITY_ENABLED=1 with LibreOffice 3.5.3, then the checkbox worked as expected. So it seems that my idea was good, but master has other problems, too. Please suggest a test case, that works when we have AT tools enabled, and does not work when AT tools are not enabled.
Andras Timar committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=98fd8f345504e98e9ed16f4845d55f5b88b77a5e fdo#39833 add "Support assistive technology tools" option to Windows installer
So, the "Support assistive technology tools" checkbox will be in LibreOffice 3.6 installer, unchecked by default. I think this bug is fixed. Please re-open, if you find problems related to the fix.
(In reply to comment #5) > So, the "Support assistive technology tools" checkbox will be in LibreOffice > 3.6 installer, unchecked by default. I think this bug is fixed. Please re-open, > if you find problems related to the fix. Good job ! Don't you think it must be added to the release notes ? Most people using the setup dialog will ask what it is ... Regards Pierre-Yves
Hello (In reply to comment #6) > Don't you think it must be added to the release notes ? Most people using the > setup dialog will ask what it is ... 1. I added to release notes : http://wiki.documentfoundation.org/ReleaseNotes/3.6#Core 2. After install the feature is not enabled: Tools> Options> Accessibility> Support assistive technology... is still not checked Platform : windows 7 64bits & Version 3.6.0beta1 (Build ID: 1f1cdd8) Regards Pierre-Yves
Let's wait for 3.6 beta2, I also had issues with earlier 3.6 builds, while in my local, unpublished 3.5 build the feature worked. So I think that my part is OK, the bug must be elsewhere.
(In reply to comment #8) > Let's wait for 3.6 beta2, I also had issues with earlier 3.6 builds, while in > my local, unpublished 3.5 build the feature worked. So I think that my part is > OK, the bug must be elsewhere. After install of Version 3.6.0.0.beta3 (Build ID: 3e2b862) the feature is still not enabled: Tools> Options> Accessibility> Support assistive technology... is still not checked (windows 7 64bits)
*** Bug 51836 has been marked as a duplicate of this bug. ***
Well, I realized that it will not work in betas (LOdev), because LOdev installer does not write the registry. Could you please test with WRITE_REGISTRY=1 property? Open a command prompt and enter: msiexec /i LibO-Dev_3.6.0beta3_Win_x86_install_multi.msi WRITE_REGISTRY=1
Does the write registry flag result in actual writes into the registry or simply into the registrymodifications.xcu of each users profile?
(In reply to comment #12) It actually writes to Windows registry. By the way the "Support assistive technology tools" checkbox in installer sets a global environment variable (via the registry), SAL_ACCESSIBILITY_ENABLED. You can manually set this environment variable, reboot, and see, if Tools> Options> Accessibility> Support assistive technology is checked.
(In reply to comment #13) > (In reply to comment #12) > It actually writes to Windows registry. By the way the "Support assistive > technology tools" checkbox in installer sets a global environment variable (via > the registry), SAL_ACCESSIBILITY_ENABLED. You can manually set this environment > variable, reboot, and see, if Tools> Options> Accessibility> Support assistive > technology is checked. OK, I'm in the process of uninstalling LODev and will try using the WRITE_REGISTRY flag as suggested. What HIVE_KEY should I be looking in--CURRENT_USER or SOFTWARE, one of the problems I've noted on recent installs has been that nothing goes into the Windows registry. Everything shows up in the registrymodifications.xcu
(In reply to comment #14) HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
(In reply to comment #15) > (In reply to comment #14) > HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment I ran the installation with the WRITE_REGISTRY=1 flag. As you said, the SAL_ACCESSIBILITY_ENABLED environment variable then gets written into the Registry as a value in the HKLM Session Manager\Environment keys. The LOdev -- CA9D68FF11ED2AF41A4363C276690FFB, and the component for Accessibility feature -- 450153C43E53DA0BF2FA214884B72B88, are being added to the registry. Found that since I ran the install from a command windows "Run as Administrator", I had to logoff and log back on with the user account. But then the "Use a Java Runtime Environment" and "Support assistive technology tools" are both coming up selected for all users. So I think you've got that flag configured correctly to set JRE and Accessibility for ALL system users. One potential problem--how handle multiple JRE's on system where users do not have a preferred JRE selected through a JAVA_HOME\bin entry in a path statement. Or when they have yet to configure a Java Access Bridge installation. On a sidebar--absent HKEY_CURRENT_USER\Software\LibreOffice registry values, how do we handle just one user on a multiuser system? Should we have folks use the registrymodifications.xcu configuration file in their profile like this? <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|false]</value></prop> </item> Or are we be able to toggle a feature -- gm_Enable_AT_tl_For_Current_User, with another environment variable? Admit that I have been confused about the role of the registrymodifications.xcu configuration file. I remain uncertain if it is the preferred way to configure per user settings. I has seemed like for much of the LO 3.5.x cycle--the Windows registry was not receiving keys/values for LO. Was I imagining that, or was there a problem with needing to use the WRITE_REGISTRY flag during installations?
(In reply to comment #16) Thanks for testing, I think this bug can be set back to RESOLVED FIXED. LibreOffice can be installed for a single user (ALLUSERS=0) but it is not heavily tested, so there may be problems. It installs a the SAL_ACCESSIBILITY_ENABLED environment variable for a single user. Please do not confuse LibreOffice registry and Windows registry. There is no connection between the two. It is not easy to set registrymodifications.xcu from the installer, because it is generated after the first start for the current user. In general, Windows installer does not provide tools to modify LibreOffice registry, we would need to write custom actions for that. It was easier to use an environment variable for this particular setting.
Andras, Had a go at installing LOdev36b3 with WRITE_REGISTRY=1 and ALLUSERS=0 Looked at the .msi installer with MS Orca and the ALLUSERS<>1 condition for the {1DB4C8BF-F67B-3B75-1E87-59623251CC0B} component assigned for the "g_r_enable_at_tools_for_current_user" keypath. Not sure, but is the registry value of "Environmnet" supposed to do anything as far as recording the SAL_ACCESSIBILITY_ENABLE variable? Also, even though run as ALLUSERS=0, the {4C351054-35E3-B0AD-2FAF-1284487BB288} component for ALLUSERS=1 condition was executed and the SAL_ACCESSIBILITY_ENABLE variable was created in HKLM\SYSTEM\CurrentControlSet\Control\SessionManager\Environment. Is that correct? Afterward when running from install user account, the Use Java JRE asserts--but the Accessibility - Use Assistive technology tools does not. So think there may be some issue with the for current user only. Here is a log snippet of the components being registered with ALLUSERS=0. MSI (s) (FC:78) [12:28:39:948]: Executing op: ComponentRegister(ComponentId={4C351054-35E3-B0AD-2FAF-1284487BB288},KeyPath=02:\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\SAL_ACCESSIBILITY_ENABLED,State=3,,Disk=1,SharedDllRefCount=0,BinaryType=0) 1: {FF86D9AC-DE11-4FA2-A134-362C6796F0BF} 2: {4C351054-35E3-B0AD-2FAF-1284487BB288} 3: 02:\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\SAL_ACCESSIBILITY_ENABLED MSI (s) (FC:78) [12:28:39:948]: Executing op: ComponentRegister(ComponentId={1DB4C8BF-F67B-3B75-1E87-59623251CC0B},,State=-7,,Disk=1,SharedDllRefCount=0,BinaryType=0) 1: {FF86D9AC-DE11-4FA2-A134-362C6796F0BF} 2: {1DB4C8BF-F67B-3B75-1E87-59623251CC0B} As an aside, wouldn't another option for handling current user only in the .msi installer be an action for the installer to go ahead and create the HKCU\Software\LibreOffice\Accessibility\AtToolSupport -- SupportAssistiveTechnology value? Looking at the /core/vcl/source/app/settings.cxx that looks to still be intact as a test on Windows, but then still have the issues of a JRE and a working Java Access Bridge.
Hello After install the feature is not enabled: Tools> Options> Accessibility> Support assistive technology... is still not checked Platform : windows 7 64bits & Version 3.6.1.2 (Build ID: e29a214) Regards
We look to also have issues with it in LOdev 3-7 build of master. Uninstall everything for LOdev (user profile and Windows registry for a clean install. Run from command prompt "run as administrator" with WRITE_REGISTRY=1 parameter. As the GUI install ran, checked the "support Assistive technology tools" on the install panel. Andras can probably explain better, but IIRC we can not directly set LibO registry values in registrymodification.xcu without doing Microsoft Installer custom actions in the MSI package. So instead the installer sets an environment variable SAL_ACCESSIBILITY_ENABLED which gets read for each first use of LibO and based on that flag is supposed to write the VCL:ConfigurableSetting['Accessibility'] EnableATToolSupport set as true into each users registrymodification.xcu I verified that the SAL_ACCESSIBILITY_ENABLE SZ variable was written to the windows registry. But with this LOdev -3-7 build of master, it looks like the registry creation process does not complete. Rather than a full registry, what I see following a first launch: Common/Internal -- CurrentTempURL Common/Misc -- FirstRun -> false Recovery/RecoveryInfo -- SessionData -> false Views/Dialogs -- 17015 - replace - UserData - WindowState Setup/L10N -- ooLocale -> en-US Setup:Factory -- ooSetupFactoryWindowsAttributes Setup/Office -- LastCompatibilityCheckID 0> b66021 Setup/Office -- OfficeRestartInProgress -> false Setup/Office -- ooSetupInstCompleted -> true and the ~15 line template for UserProfile/Data Which looks to be an abbreviated registry--where unfortunately the EnableATToolSupport registry setting is not being set at all. Also, the javasettings_Windows_x86.xml in the user\config is not fully built. They both look like template data, so something with this build at least is broken. If this enhancement gets reworked for better reliability--it would be very useful to folks needing AT if the "use Accessibility checkbox" and SAL_ACCESSIBILITY_ENABLED variable parsed actions could also completely enable the JRE and Java Accessibility Bridge.
With the 3.6.4 final release, the Support assistive technology tools check box is not resulting in fully functional AT during installation for Windows Java Access Bridge based users as desired. See this Accessibility ML thread: http://nabble.documentfoundation.org/libreoffice-accessibility-Latest-LibreOffice-and-Java-access-Bridge-tt4022968.html
As of the 4.2.0.4 final release, the check box is correctly setting SAL_ACCESSIBILITY_ENABLED, and is activating JRE Java Access Bridge AT tool support in the UI and the per-user 'registrymodifications.xcu' settings. And for 4.3.0.0alpha+ builds of master, Java Access Bridge support has been removed, and when an AT is detected in use the IAccessible2 native Windows bridge activates. So now the same behavior for UAA native bridges all supported OS. @Andras, might need to double check with the Michael's, but believe that for builds of 4.3.0 master, the installer code for a GUI check box and the setting of the SAL_ACCESSIBILITY_ENABLED environment variable probably can be removed.