Bugzilla – Full Text Bug Listing
| Summary: | [Help][Context] F1 accessibility - no indication that help view has opened (since there is no focus change) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Jamie Liu <liuj1> | ||||
| Component: | User Assistance | Assignee: | Chris Goldthorpe <cgold> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | aabbott, cgold, daniel_megert, hokamoto, michaelvanmeekeren, raji | ||||
| Version: | 3.4 | ||||||
| Target Milestone: | 3.4.1 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Jamie Liu
Bug 234806 is closely related to this. The user using a screenreader may be better off if they set their preferences so that F1 help opens an infopop. This can be done via Window/Preferences and selecting the Help page in the preference dialog. Chris, even if the user enables infopop in the Help pref page, infopop still displays "Open in dynamic help". so I think the user will still encounter the same issue. Can we hide "Open in dynamic help" link in infopop programatically ? Right now there is no way to hide the "Open in dynamic help" link. Maybe there should be since other have requested hiding it. See Bug 150108. More info: at the bottom of each infopop there is still a link to the Help Pane, and if the user clicks it, we have the same problem (no knowledge that the Help Pane has opened). Notes Domino: Eclipse dev thinks there is a workaround. Hiro reviewed and responded to Bugzilla report that the workaround provided is not acceptable. This is a failure of checkpoint 2.2 and must be fixed in 8.5. This bug must be put on the critical bug list and a target fix date established. Escalated via email from Pete Miller/Westford/IBM to Pat Huff/Raleigh/IBM 07/11/2008 09:28 AM How do you suggest that I fix it? It's not obvious how you could make this work in a way that satisfies users with screen readers without negatively impacting gthe user experience for everyone else. If I add a customization preference to allow the suppression of the "Open in help view" link, which has also been suggested in Bug 150108 would that be an acceptable solution? That way F1 help could open an infopop and every link on the infopop would open something accessible. I've been looking into this some more. The other thing which could be done is to bring the help view to the foreground and give it focus when F1 is pressed. I get the impression that a design decision was made not to give the help view focus but I think that giving the help view focus may be the better way to go. The normal sequence is to hit F1 and then select one of the links in the help view so it probably makes more sense to give focus to the help view than to leave it wherever F1 was pressed. The only time when this would not be the desired behavior would be if you pressed F1 for a menu item, unfortunately the help view does not have a way to distinguish that case. Created attachment 107519 [details]
Patch
I have done testing on the attached patch and it works well. I don't see any negative effects of this change, the manu item behavior is the same with and without this patch. Fixed in HEAD, will port to 3.4 maintenance stream also. Patch committed to 3.4 maintenance stream. Seting state to FIXED. Thanks, Chris. Just tried this out with JAWS and it works well. Didn't see any negative impact, either. *** Bug 120631 has been marked as a duplicate of this bug. *** *** Bug 234806 has been marked as a duplicate of this bug. *** Chris I guess the target is wrong (should be 3.4.1). Yes, good catch - it's 3.4.1. Can we apply this patch to 3.4? If you want to add this patch to the 3.4 sources and run against Eclipse 3.4 it will work fine. Great, thanks. |