Bug 374689 - [search] Difficult to Select Limit To options in Search dialog with keyboard
Summary: [search] Difficult to Select Limit To options in Search dialog with keyboard
Status: RESOLVED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.8   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: 3.8 M7   Edit
Assignee: Dani Megert CLA
QA Contact:
URL:
Whiteboard:
Keywords: accessibility
Depends on:
Blocks:
 
Reported: 2012-03-19 14:56 EDT by Max Li CLA
Modified: 2012-04-02 11:21 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Max Li CLA 2012-03-19 14:56:58 EDT
1. Open the search dialog (Ctrl+H).
2. Tab through the items until you reach the Limit To area (you mush search for either Type or Method).
3. The "Match locations" is in a different grouping from the other radio buttons, so when selecting one of the first few options then tabbing forward leads to the selection being lost and Match locations being selected.

This makes it difficult to select any of the other options, though you could Shift+Tab backwards through the entire dialog after selecting a option, but that's not a very nice experience.
Comment 1 Carolyn MacLeod CLA 2012-03-30 17:18:11 EDT
This fails item 1.2 on the accessibility checklist and must be fixed for 3.8.
Comment 2 Dani Megert CLA 2012-04-02 09:05:57 EDT
(In reply to comment #0)
> 1. Open the search dialog (Ctrl+H).
> 2. Tab through the items until you reach the Limit To area (you mush search 
> for either Type or Method).
> 3. The "Match locations" is in a different grouping from the other radio
> buttons, so when selecting one of the first few options then tabbing forward
> leads to the selection being lost and Match locations being selected.

You probably mean "hitting an arrow key", right? 'Tab' should leave the radio group.

Fixed in master: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=32bb5a8cb659c30f2b9f7df2a96540d25a6b14f7


Carolyn, I also tried to provide a better string when reading the "x of y selected" link, but it looks like getName() is not called if the control already has a text. Is there some other way to override this?
Comment 3 Carolyn MacLeod CLA 2012-04-02 10:13:48 EDT
(In reply to comment #0)
> You probably mean "hitting an arrow key", right? 'Tab' should leave the radio
> group.

I guess both tab and arrow were a problem. Arrow keys didn't traverse to "Match locations" (and they should have), and Tab key did traverse to "Match locations" (but you would have expected it to traverse to the link, or maybe to the "Search In" group). Unfortunately, when the Tab key traversed to "Match locations", it also selected it. I think that's the problem that Max was referring to.

> Carolyn, I also tried to provide a better string when reading the "x of y
> selected" link, but it looks like getName() is not called if the control
> already has a text. Is there some other way to override this?

The following is working for me, with JAWS 13 on Windows XP (SP3):
	Link link = new Link(shell, SWT.NONE);
	link.setText("<a>This is a link</a>");
	link.getAccessible().addAccessibleListener(new AccessibleAdapter() {
		public void getName(AccessibleEvent e) {
			e.result = "This is the get_accName for the link";
		}
	});

Should the link be disabled when "Match locations" is not selected? That might help a bit, because the link text wouldn't be spoken unless the user had just selected the "Match locations" radio.

With your new patch, does JAWS say "Limit to" before the link?

Also - just curious - does JAWS get the number of radios correct with your new patch, i.e. does it say, for example, "Limit to All occurrences radio button checked, one of four." (instead of "one of three"). (i.e. "Match locations" should be "four of four").
Comment 4 Dani Megert CLA 2012-04-02 11:04:21 EDT
(In reply to comment #3)
> The following is working for me, with JAWS 13 on Windows XP (SP3):
>     Link link = new Link(shell, SWT.NONE);
>     link.setText("<a>This is a link</a>");
>     link.getAccessible().addAccessibleListener(new AccessibleAdapter() {
>         public void getName(AccessibleEvent e) {
>             e.result = "This is the get_accName for the link";
>         }
>     });
> 

It doesn't work with the Windows Narrator (org.eclipse.swt.accessibility.new COMObject() {...}.method10(int[]) isn't called) and I do not have JAWS. Since you say it works, I simply added it ;-).


> Should the link be disabled when "Match locations" is not selected? 

No, this is on purpose to speed up changing and selecting the match location option. I wouldn't want to sacrifice that.


> With your new patch, does JAWS say "Limit to" before the link?

It does with the Narrator.


> Also - just curious - does JAWS get the number of radios correct with your new
> patch, i.e. does it say, for example, "Limit to All occurrences radio button
> checked, one of four." (instead of "one of three"). (i.e. "Match locations"
> should be "four of four").

I think, so though I can't test it (the Narrator doesn't tell this).
Comment 5 Carolyn MacLeod CLA 2012-04-02 11:21:35 EDT
(In reply to comment 4)
Thanks, Dani. Sorry, I thought you were using JAWS.
I'm not surprised that it didn't work with Narrator.
Just FYI, Microsoft is giving Narrator a big update for Windows 8.
I have heard that it will be a serious screen reader...   :)