forked from amazingfate/loongoffice
b80be50268
Non ASCII characters like åäö can be used as accelerator keys (Alt+<x>). This already works however at the moment it is not exposed properly to accessibility tools such as screen readers. After this patch at least NVDA gets information about accelerator keys that are non ascii. On Linux we need to adapt code in vcl/unx/atk/a11y/atkaction.cxx. There is also vcl/source/window/dlgctrl.cxx#Window::GetActivationKey should probably have similar treatment and I guess that it is related to accelerator keys in dialogs but I need to confirm that. I'm a bit unsure how to best do that so I'll save it for later. Change-Id: I1f1509a26d781011d217670266bd10b2107811d5 Reviewed-on: https://gerrit.libreoffice.org/19078 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
Windows Accessibility Bridge. This code provides a bridge between our internal Accessibility interfaces (implemented on all visible 'things' in the suite: eg. windows, buttons, entry boxes etc.) - and the Windows MSAA / IAccessible2 COM interfaces that are familiar to windows users and Accessible Technologies (ATs) such as the NVDA screen reader. The code breaks into three bits: source/service/ + the UNO service providing the accessibility bridge. It essentially listens to events from the LibreOffice core and creates and synchronises COM peers for our internal accessibility objects when events arrive. source/UAccCom/ + COM implementations of the MSAA / IAccessible2 interfaces to provide native peers for the accessibility code. source/UAccCOMIDL/ + COM Interface Definition Language (IDL) for UAccCom. Here is one way of visualising the code / control flow VCL <-> UNO toolkit <-> UNO a11y <-> win a11y <-> COM / IAccessible2 vcl/ <-> toolkit/ <-> accessibility/ <-> winaccessibility/ <-> UAccCom/ Threading It's possible that the UNO components are called from threads other than the main thread, so they have to be synchronized. It would be nice to put the component into an UNO apartment (and the COM components into STA) but UNO would spawn a new thread for it so it's not possible. The COM components also call into the same global AccObjectWinManager as the UNO components do so both have to be synchronized in the same way. So we use the SolarMutex for all synchronization since anything else would be rather difficult to make work. Unfortunately there is a pre-exising problem in vcl with Win32 Window creation and destruction on non-main threads where a synchronous SendMessage is used while the SolarMutex is locked that can cause deadlocks if the main thread is waiting on the SolarMutex itself at that time and thus not handing the Win32 message; this is easy to trigger with JunitTests but hopefully not by actual end users. Debugging / playing with winaccessibility You need to enable 'experiemental mode' in Tools->Options. After that NVDA should work as expected. In order to use 'accprobe' to debug it is necessary to override the check for whether an AT (like NVDA) is running; to do that use: SAL_FORCE_IACCESSIBLE2=1 soffice.exe -writer Then you can use accprobe to introspect the accessibility hierarchy remotely, checkout: http://accessibility.linuxfoundation.org/a11yweb/util/accprobe/