Apache OpenOffice (AOO) Bugzilla – Issue 56539
accessibility : sub-menus not detected with Jaws
Last modified: 2007-02-02 11:40:07 UTC
Jasw can read the menus but doesnot detect the sub-menus (like File->New), the user has to use the arrow key to (which he can't do If he uses Jaws). Maybe the informations needed for the accessibility API are only partially implemented.
Added "accessibility" keyword
ES->MT: as described. Broken since OOo 2.0. (-> PP3)
Philipp, can you please have a look at that? IMHO we changed menu implemenmtation to be system menus in 2.0?
Taking that change back does not fix the problem, so i don't think the vcl system menu change did this. The menu events inside vcl get sent or else Zoomtext would also not work. tbe told me there were many changes in the accessibility bridge for this or that ATTool; however i wouldn't know. I think it would be best if someone looked into this who actually knows what he's doing.
The reason might be that SELECTED state changes are partially disabled on Windows due to #i15942#.
MT->OBR: Please handle with #i15942#, or pass to TBE when changes in menu UAA implementation are needed.
The workaround for issue 15942 is actually in toolkit, not in any of the bridges => re-assigned.
The fix for #i15942# can be disabled by setting the environment variable SAL_ACCESSIBILITY_ENABLE_MENU_SELECTED. TBE->ES: Can you please test, if Jaws and ZoomText read menus, when SAL_ACCESSIBILITY_ENABLE_MENU_SELECTED is set.
Jaws doesn't read menus, but only menu items. In order to read both, it is required, that a menu fires a state change event for selected and for focused. A menu item must fire a state change event for armed and for focused. The impact for the accessible menu implementation is to fire additional events, adjust the accessible state set, change the semantics of selected for menus and change the implementation of XAccessibleSelection. As proposed by OBR, when reworking the accessible menu implementation to such an extent, also the requirements from Gnome should be taken into account. The idea is to skip the armed state for both, menus and menu items. When a menu or menu item is highlighted, the selected state should be set and a state change for selected should be fired. Up to now, the semantics of selected for a menu means, that the corresponding popup menu is open. This should be changed, so that a menu is selected, if it is highlighted, independent of an open popup menu. In addition, if a menu or menu item is highlighted, the focused state should be set and a state change for focused should be fired. Special cases taken into account are when a popup menu is opened (then the first item of the popup menu gets the focus) or closed (then the menu gets the focus back). In addition the inital focus of the menu bar or a context menu must be taken into account. Whereas XAccessibleAction should still open a sub menu or emulate the click on a menu item, XAccessibleSelection should only highlight a menu or menu item. As Jaws won't read menu items, when a state changed for focused and selected is fired, the idea is to map a state changed selected to a state changed armed in the Java bridge.
In the java_uno_accessbridge there's also an additional fix required, that menu items are focusable.
TBE->MD: As discussed, please set target to OOo 2.0.4.
.
accepted
In order that Jaws reads menus and menu items it is required, that a menu fires a state change event for selected and a menu item a state change event for armed. Note, that state change events for focused are not necessary. This was wrongly stated in one of my previous comments.
TBE->OBR: As discussed, the following fixes are needed in the Java UNO AccessBridge: o state set: - map state selected to armed for menu items - set state selectable for menus, don't set for menu items - set state focusable for menus and menu items o state change events: - map state change selected events to state change armed for menu items o selection changed events: - filter out selection changed events for menu items (otherwise Jaws reads menu items twice)
reassigned to OBR
Missed the 2.0.4 code freeze gate - sorry.
In addition to the things mentioned above, I changed: o accessible selection of menus - map addAccessibleSelection(n) to n.doAccessibleAction(0) for menu-items
obr -> es: please verify.
Verified in tbe28
set target to 2.1
Fix but failed in master. Reset to 2.2.
ES->TBE: as discussed with MD. We reset to 2.2. Sorry!
TBE->ES: As we found out, Jaws reads also submenus in the master. Whereas Jaws read e.g. 'New submenu' in CWS tbe28, Jaws reads only 'New' in the master. Please write a follow-up issue with target OOo 2.3.
reassigned to ES
As discussed with MD/TBE: this has been correctly integrated but there is a 2. bug now (not due to the CWS).
Ok in OOF_m5