Community
Participate
Working Groups
Build Identifier: SWT v3659c We have our own version of ToolBar control. It is not OS native based. It draws the UI by itself. To support accessibility, we do the same thing as initAccessible() in SWT CTabFolder. So like CTabFolder, we have only 1 accessibility object in our version of ToolBar. Now we want to support various Accessibility events, so that JAWS can receive the events, then change the accessibility properties. The problem is currently SWT provides only Accessible.sendEvent(int event, Object eventData). It does not allow us to specify childID. To do that, we know we need to instantiate Accessible object by calling constructor Accessible(Accessible parent), but actually we implemented only 1 Accessibile object (and not creating Accessible(Accesssible parent)). So we don't want to rewrite our current accessibility code. So, we would like to propose SWT to have: Accessible.sendEvent(int event, Object eventData, int childID) Reproducible: Always
Created attachment 198356 [details] proposed patch for Win32 This is a proposed patch we created. For now Win32 only. Any comments would be appreciated.
Any comments ? Do you think the idea of having Accessible.sendEvent with childId param makes sense ? We would like SWT team to review our proposed patch asap, so that we can add it in our modified version of SWT in our product, then in the future, we will simply upgrade to the future version of SWT when SWT adds the method.
I am reluctant to add this API, because it is Windows only, and it would never be useful on other platforms. The platform Accessibility APIs have moved away from child ID's - they are a bit of a historical artifact from MSAA. Even the latest Windows Accessibility API (called UI Automation) uses accessible objects instead of child ID's. Most of the events that are listed in the javadoc for sendEvent(event, data) are from IAccessible2, which does not even have the concept of a childID, so most of those events won't work with a childID anyhow. Which events do you need to send? Is it value_changed? state_changed? If it's only one specific event, then I think (?) I would rather create a method like setFocus(childID), rather than another sendEvent. I need to discuss it with SSQ, however it would help to know what events you are using. I assume your code is tested and working and you have seen Windows AT respond to your sent events?
Hi Carolyn, For now, we need ACC.EVENT_STATE_CHANGED & ACC.EVENT_NAME_CHANGED to support childID at least. But we may need to add other EVENT_*_CHANGED events supported. I tested CTabFolder with MSAA AccEvent32.exe on Windows, and CTabFolder has the same issue. So you prefer having Accessible.stateChanged(in childID) or Accessible.nameChanged(int childID) ?
Have you tried your toolbar with a real AT, like a sreen reader? (I mean, like JAWS or Window-Eyes or NVDA or Hal. Narrator does not count, and AccEvent does not count either unless you are debugging a problem with a real AT). What bug did you see with CTabFolder? The screen readers don't always need all of the events that can be generated. In fact, they ignore some of them. I'm just trying to figure out if you really need them, and why.
(In reply to comment #5) > Have you tried your toolbar with a real AT, like a sreen reader? We are using JAWS on Windows. So far we are seeing 2 issues... 1) When focusing our custom toolbar button(tool item) with CHECK style then pressing space key, JAWS announces "space" only. It should announce "space checked" or "space unchecked". (We need to fire EVENT_STATE_CHANGED.) 2) When focusing our custom toolbar button with PUSH style then pressing space key, we changes the button text. But JAWS does not announce the text change. (We need to fire EVENT_NAME_CHANGED.) > What bug did you see with CTabFolder? Sorry if I confused you. Actually I have not tested it, just looked at the source code of CTabFolder, and just wondered CTabFolder does not have any code to handle EVENT_*_CHANGED events. For now, we don't need any fix for CTabFolder.
Created attachment 200116 [details] patch to add new sendEvent api Here is the patch for all platforms. Please apply this patch, and re-try your case on Windows. I still need to write up a test case to test on cocoa and gtk. This new api will be @since 3.8. It will only work for certain events (i.e. the ones corresponding to MSAA, which are the only ones that might need a childID). If it is called with any other events, then nothing will be sent. Here is the javadoc: /** * Sends a message with event-specific data and a childID * to accessible clients, indicating that something has changed * within a custom control. * * NOTE: This API is intended for applications that are still using childIDs. * Moving forward, applications should use accessible objects instead of childIDs. * * @param event an <code>ACC</code> constant beginning with EVENT_* indicating the message to send * @param eventData an object containing event-specific data, or null if there is no event-specific data * (eventData is specified in the documentation for individual ACC.EVENT_* constants) * @param childID an identifier specifying a child of the control * * @exception SWTException <ul> * <li>ERROR_WIDGET_DISPOSED - if the receiver's control has been disposed</li> * <li>ERROR_THREAD_INVALID_ACCESS - if not called from the thread that created the receiver's control</li> * </ul> * * @see ACC#EVENT_DESCRIPTION_CHANGED * @see ACC#EVENT_LOCATION_CHANGED * @see ACC#EVENT_NAME_CHANGED * @see ACC#EVENT_SELECTION_CHANGED * @see ACC#EVENT_STATE_CHANGED * @see ACC#EVENT_TEXT_SELECTION_CHANGED * @see ACC#EVENT_VALUE_CHANGED * * @since 3.8 */
Fixed - released patch in comment 7. This will be in Eclipse 3.8/4.2 M3 and onward. http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=7c05ea712090d921560edc39e2f8b7fcc08d357e
