Community
Participate
Working Groups
RC6 It is not possible to navigate to the help button in the wizard dialog using the keyboard. This is not a showstopper as F1 still works but it should be accessbile via the keyboard navigation.
This is problematic because we do not want that button to get focus. If we allow focus, when the user clicks on the button, the focus will be given to the button, and it will find context help for that button, rather than the widget that was previously in focus. The current behavior of the button is identical to F1. Some users have expressed concern about this because it depends on what's currently in focus and they may not know this. Instead, I would like to see if it makes more sense to have the button provide some more general help (say, at the page level), regardless of what's in focus. This would allow us to give the button focus, and it would always behave the same way on a given page.
There is a difference between allowing navigation and clicking on the button. For a user that is relying on a screen reader to tell them what the control does this button will be effectively invisble if they can't tab to to it. This does not invoke the button - it just allows information to be read. I think you will also find that in the vast majority of cases the help for a dialog will be the same for all controls - I expect this would cause very little confusion if the general help for the dialog is invoked. When I press F1 on any of the other buttons I get context sensitive help (try it in the New Project dialog) so this button should behave the same way
Ok. I'll see if it's possible to prevent focus from going to the button when clicked, while still allowing traversal and focus otherwise.
*** Bug 160370 has been marked as a duplicate of this bug. ***
Reassigning to platform-ua-inbox@eclipse.org
Created attachment 213353 [details] Screenshot of MS Word "Paragraph" dialog
I am going to close this as "Works For Me". The user can type F1, and it really doesn't matter that there's no way to give focus to the button. I have attached a similar dialog from MS Word. Notice that they put their non-focusable help icon in the title bar of the dialog, next to the close box. It is slightly clearer to the sighted user that the button probably doesn't take focus, however our button has a "washed out" appearance, which is a visual indicator that the button won't take focus. In either case, the "help" button isn't expected to take focus. In both cases, the user knows that they can click the non-focusable button or type F1. I am closing this bug because it keeps hanging on to the accessibility checklist year after year and it takes time to re-read the bug report and decide that isn't a problem, year after year. It's time to close the issue, either as WorksForMe (i.e. type F1) or "won't fix" (i.e. no, we won't be adding some crazy ui-breaking hack that allows a button to be clicked without taking focus).
> some crazy ui-breaking hack that allows a button to be clicked without > taking focus Oops... actually, ToolItems with FLAT style don't take focus when they are clicked, and yet you can traverse to them with the keyboard. Just FYI, however, because I still think this bug should remain closed.
