Community
Participate
Working Groups
I'm working on acc support on a custom tree. I add an AccessibleControlListener to tree control. BUT it doesn't provide a way to navigate children and brothers.
You need to implement getChildCount, getChildren, and getChild in your AccessibleControlListener. The child ID's or accessible child objects are up to you - it is your custom tree. As for navigating, I am marking this as a duplicate of 158394 which requests new "relations" capabilities. *** This bug has been marked as a duplicate of bug 158394 ***
We have implemented all APIs in current AccessibleControlListener. But it still did not work. In MSAA, there are 2 important APIs: accNavigate and get_accParent. The AccessibleControlListener does not expose those APIs, so we can not implement them. Some screen readers depend those APIs to navigate the tree. Without those APIs, some screen readers(like WindowEyes) won't read the tree item. I think those APIs are what wasleski said "the enhancement for the additional navigation capability". That is what we need.
Is this bug really a dup of 158394? Should it be re-opened to consider providing access to the missing accNavigate and accParent functions?
Not a duplicate. This is a specific request for navigation API for the Tree control.
We implemented the methods in AccessibleControlListener below: public void getChildAtPoint(AccessibleControlEvent e) {} public void getLocation(AccessibleControlEvent e) {} public void getChildCount(AccessibleControlEvent e) {} public void getDefaultAction(AccessibleControlEvent e) {} public void getFocus(AccessibleControlEvent e) {} public void getRole(AccessibleControlEvent e) {} public void getSelection(AccessibleControlEvent e) {} public void getState(AccessibleControlEvent e) {} public void getChildren(AccessibleControlEvent e) {} public void getValue(AccessibleControlEvent e) {} We also implemented the methods in AccessibleListener: public void getName(AccessibleEvent e) {} public void getDescription(AccessibleEvent e) {} There are 2 methods in Accessible we need to implement, but they are not exposed: int accNavigate(int navDir, int varStart_vt, int varStart_reserved1, int varStart_lVal, int varStart_reserved2, int pvarEndUpAt) { if (iaccessible == null) return COM.CO_E_OBJNOTCONNECTED; // Currently, we don't let the application override this. Forward to the proxy. int code = iaccessible.accNavigate(navDir, varStart_vt, varStart_reserved1, varStart_lVal, varStart_reserved2, pvarEndUpAt); if (code == COM.E_INVALIDARG) code = COM.S_FALSE; // proxy doesn't know about app childID return code; } /* get_accParent([out] ppdispParent) * Ownership of ppdispParent transfers from callee to caller so reference count on ppdispParent * must be incremented before returning. The caller is responsible for releasing ppdispParent. */ int get_accParent(int ppdispParent) { if (iaccessible == null) return COM.CO_E_OBJNOTCONNECTED; // Currently, we don't let the application override this. Forward to the proxy. return iaccessible.get_accParent(ppdispParent); } From Qian Lang
CAR, can you comment on this? I'm pretty sure it's a "no go" for 3.2.x. For one thing, it seems like new API is requested which is a no-no for this sort of release.
I also don't think we can put new API in for R3.2.2. The alternative is to help them find a way to get their use case to work without using new API. (I.e. is there a workaround?)
I'm afraid I cannot add any new api for 3.2.x. However, I'll research your request for 3.3. I do need to be careful, however, because of the new api that may be added due to bug 158394 - the function of both of these things is very similar, and I don't want to be providing new api if they are going to be creating a different api to do basically the same thing. As for possible work-arounds... is your custom tree implemented using a Canvas and drawing everything on it, or is your custom tree implemented using an lot of child widgets?
Our custom tree is implemented using a Canvas and drawing everything on it.
Carolyn, what are the results of your research in putting a fix in 3.3?
I don't understand what it is that Window-Eyes won't read. I took our emulated Tree from the Motif platform and ran it on Windows, and both JAWS and Window-Eyes can read the tree items just fine. As long as you are using GC.drawString and GC.drawFocus to do your drawing and focus ring, you should be fine.
Can you give us a small stand alone snippet that shows the problem? We believe you, but we don't have anything to debug and test on our end.
We don't have a snippet that shows the problem, so not for 3.3.
We will try to provide you with the code snippet by the end of May.
Beth, for an API request the end of May (actually, probably right now) is too late for 3.3.
We understand, it's ok to defer this bug to next release when you can make API update.
We can't add new api for a point release, and I can't replicate the problem in order to think about a work-around unless I get a snippet that shows the problem.
We tested this bug with Jaws9.0 and Windows Eyes. The result which Jaws read customized tree is correct. The result which Windows Eyes read tree is partially correct. We think there are some implementation difference between these two tools. But not caused by get_accParent and accNavigate API call. But we suggest SWT exposes these two APIs because we do not know which tool will use two APIs to read our tree.
Any updates on this for 3.4?
This looks like it's a problem with the readers. If that's true, I don't like the idea of adding the API just because "we don't know...".
Now we have a custom tree which is based on SWT. To support acc, for each tree node, we need to know its parent's info and its brothers' info. But now, we can not find a way to get them. If you have a workaround, please tell me.
You are correct that this API is missing from SWT's accessibility story, and that having it would probably make it easier to implement a custom tree. Accessibility tools such as screen readers probably expect this API to be available for all custom controls implemented for Windows, because it is required API for MSAA. Having said that, it is interesting that JAWS works with your custom tree. One of the (very large) roadblocks to implementing a cross-platform API for accNavigate is that the concept does not even exist on the other platforms, although there are rumours that perhaps something similar called AtkCollection may be added to ATK some day: http://live.gnome.org/GAP/Collection Have you had a chance to test your custom tree on Linux GTK? There is currently no equivalent function on the Macintosh that I can see, on either Carbon or Cocoa. The closest thing I see is the DisclosedRowsAttribute and DisclosedByRowAttribute, which are only ever provided by Outline (tree & table) controls, whereas accNavigate is supposed to be provided by all controls. Have you had a chance to test your custom tree on Mac OS X Carbon? The bottom line is that if you want your custom tree to work on GTK and OS X, you probably should not rely on accNavigate. As for get_accParent, I believe it should be possible to expose this as API. The OS call for ATK is atk_object_get_parent, for OS X Carbon the attribute is kAXParentAttribute and for Cocoa it is NSAccessibilityParentAttribute. I did try to expose this as API back in 2001 when the SWT api was first implemented, and the only thing I recall about it is that it broke many things, so I took it out (at the time, MSAA was the only game in town, so I only tried it on Windows). I am sure that the MSAA implementation is more robust by now. Now, back to your current tree problem: your custom tree does not work with Window-Eyes. It is past API freeze for 3.4, so even exposing getParent must be deferred. I am unlikely to expose accNavigate as API until at least one more platform supports the concept. So what we need to do is figure out why your tree is not working with Window-Eyes. If you can send me the code for your tree, plus a snippet that just creates your tree in a shell with enough content for testing, then I can have a look at it. If I can figure out a fix, I will send it to you. Also, I know one of the main developers at GWMicro, so if I discover a problem in Window-Eyes, I can let him know. In the latter case, I would need to create an executable from the snippet you send, so that he has something to test against. So in summary, I can't help you until you send me code. See comment 12.
Created attachment 95031 [details] code snippet for custom tree acc support This is a simple code snippet to implement a custom tree. When arrow up/down, windows eyes can not read items. It's strange that Jaws can read it correctly. I know the roadblocks to expose the two apis now. It is not an urgent requirement for us.
The snippet in comment 23 works for me under WindowEyes. I am running WindowEyes version 6.0 - what version are you running? I also tried this with JAWS 8.0, and inspect32, and in all cases, the tree items are read correctly. I am on XP SP2, and the VM I was using is 1.5.0_02. I will leave the bug open to consider adding getParent one day, but I think there is no urgency. Thank-you for providing the snippet. Code is worth 1000 words <grin>.
FYI, in Eclipse 3.6, we will handle get_accParent transparently. We will not be exposing accNavigate, as the MS documentation advises against it. Your snippet worked for me (see comment 24) so there is nothing further to do here. Closing bug.
accNavigate should be exposed or (probably) properly implemented in the proxy. My problem: I am trying to add accessibility support to TuxGuitar, an open-source tablature editor. For this, I would like to expose a tablature editor as a list of beats. I created appropriate accessible adaptors to expose name, role, childCount and children. But when I try to navigate the control with NVDA, an open-source screen reader for windows (http://www.nvda-project.org), it reads as the control has only one child, the first beat. When i try to go to the next object while navigator is on a first beat, it fails. I have made some investigations, which showed that NVDA does accNavigate(childID,NAVDIR_NEXT) on an object which raises an error, so it things that there is no other children. NVDA is an example of AT, which strongly depends on accNavigate for object navigation. While we has display hooks for handling cases like custom drawn trees, we do need accessibility support from underlying application for things like tablatures when it is nearly impossible to grap an useful info from the screen itself. If you don't want let users override accNavigate, please, implement it in the proxy so that it handles NAVDIR_PREVIOUS and NAVDIR_NEXT for iterating over available children. Also I am looking for an ability to create accessibles for entities, which aren't represented by SWT controls. For example, measures are drawn directly on the canvas, so they don't have their own controls but i want to expose them as individual objects which have their own childs (beats). Is it a candidate for another ticket?
