Bugzilla – Full Text Bug Listing
| Summary: | [content assist][correction] additional info should be accessible | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Tom Hofmann <eclipse> |
| Component: | Text | Assignee: | Markus Keller <markus.kell.r> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P2 | CC: | benno.baumgartner, carolynmacleod4, daniel_megert, darin.eclipse, dipalerm, kai-uwe_maetzel, markus.kell.r, Olivier_Thomann, philippe_mulet, zina |
| Version: | 2.1 | Keywords: | accessibility |
| Target Milestone: | 3.4 RC1 | Flags: | philippe_mulet:
pmc_approved+
|
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | |||
| Bug Depends on: | 232038 | ||
| Bug Blocks: | |||
|
Description
Tom Hofmann
Maybe the Java UI could help out here by allowing F2 to give the content assist focus or something? Kai, does this sound feasible? *** Bug 216943 has been marked as a duplicate of this bug. *** >Maybe the Java UI could help out here by allowing F2 to give the content >assist focus or something? We are currently working on this but it might not make it into 3.5 (see bug 112921) as this could destabilize the other rich hovers. Carolyn, could we do something here using an org.eclipse.swt.accessibility.AccessibleListener on the table/list? When is getHelp(...) triggered? Could we return the additional info text there? I will ask the FreedomScientific guys if there is a key sequence in JAWS that results in IAccessible::get_accHelp being called. By 'guys', of course I meant 'developers' <g>. Moving to RC1. After looking at this with the latest version of JAWS, 9.0, I have a couple of thoughts: 1. When testing, you should always use the latest version of JAWS as that is the most proficient. Go to http://www.freedomscientific.com/products/fs/jaws-product-page.asp and select Free Demo. 2. If the yellow box had a role of ToolTip, I would expect JAWS to read it, assuming that JAWS tooltip verbosity is set on. 3. A better solution might be for the user to be able to focus on the yellow box and have a cursor appear there. Then the JAWS user could arrow up and down and read it a line at a time. That would be easier ti=o understand than hearing it all at once. >After looking at this with the latest version of JAWS, 9.0,
Do you know how/when the getHelp(...) text is requested by JAWS?
I actually don't know that JAWS ever requests the Acc_Help. That's why I suggested a class of tooltip because we know that JAWS can read tooltips as they appear. Carolyn is working on an example to see what JAWS' reaction will be. Does SWT.TOOL make it a tooltip? If so, this is already the case. Creating a Shell with SWT.TOOL style didn't actually give the Shell TOOLTIP role, so I wrote the code to do that. With that code, inspect32 reports the tooltip (but it doesn't have any name info). Unfortunately, neither JAWS nor Window-Eyes notices when these fake tooltips are opened. So I didn't release the "tool shell replies tooltip role" code, because it doesn't fix the problem. So I tried sending a fake focus event, i.e.: NotifyWinEvent (EVENT_OBJECT_FOCUS, shell_handle, OBJID_CLIENT, CHILDID_SELF); but this didn't help either. JAWS & W-E must be keying off of the window class instead of the role, and if so, fake tooltips will always be ignored. I can't spend any more time on this at this point because of RC1 obligations. The next step would be to test whether some other WinEvent (other than EVENT_OBJECT_FOCUS) makes any difference, and then to ask whether the screen reader folks are willing to look for tooltip role as well as window class. The get_accHelp angle might be interesting in future - neither screen reader currently supports a keystroke that speaks the help text, but both companies seem willing to look into supporting it in future. It might be that JAWS reacted to the tooltip, but did not say anything as it expected the text to be in the Name property. Carolyn will test this theory when she gets past her current crunch in a couple of weeks. Accessibility is an important part of the 3.3 release and a fix for this bug has been promised. In order to fix this we need to add three methods to an API class but those methods will not be API, as they will have the @noreference and @nooverride tag: org.eclipse.jface.text.AbstractInformationControlManager.getInternalAccessor() org.eclipse.jface.text.AbstractHoverInformationControlManager.getInternalAccessor() org.eclipse.jface.text.source.AnnotationBarHoverManager.getInternalAccessor() Strictly speaking this is not an API change. Philippe, can you approve? The complete fix can be seen in the patch attached to bug 112921. This is indeed not an API change. Please double check this usecase with Olivier, as I understand API tooling may not deal properly (yet) with some of it. Adding a method in this case is ok and is not seen as a breakage. However right now we might report this as being a new API post API freeze. I'll double check what API tools is reporting in this case. See bug 231850. So feel free to release and I'll take care of supporting this case for 3.4. This got fixed through bug 112921 i.e. we now allow to set focus into the additional info popup. There's a problem though under Linux regarding the Browser widget (see bug 232038). verifying verified in I20080516-1333 that it is possible to set focus into the additional info pop up with the tab key. |