Community
Participate
Working Groups
Created attachment 140515 [details] Snippet for radio button grouping issue Build ID: 3.4.0 Steps To Reproduce: 1.Select Window -> Preferences.. 2.Select Team -> CVS -> Ext connection method 3.There is one radio button group with two radio buttons in this preference page, but JAWS will read each one as "one of one" More information: There is an issue between the Eclipse SWT Radio button grouping and JAWS, JAWS will separate the radio buttons into different groups if these radio buttons are not consecutive. In the attached snippet, three radio buttons in the same group, but there is a check box between radio button 2 and 3. JAWS will read these radio button as "Radio button 1 of 2", "Radio button 2 of 2" and "Radion button 1 of 1" Expected result: JAWS read these radio button as "Radio button 1 of 3", "Radio button 2 of 3" and "Radion button 3 of 3"
Does it work on Eclipse 3.5 ?
(In reply to comment #1) > Does it work on Eclipse 3.5 ? Eclipse 3.5 has the same issue
This issue severly hinders IBM's ability to claim 100% accessibility compliance for Lotus Notes 8.5.1 release. The priority of this bug report should be higher.
(In reply to comment #3) > The priority of this bug report should be higher. Adding Silenio and McQ to the CC list.
This is happening because JAWS' definition of a radio group does not match with SWT's. In particular, JAWS only considers radios to be in a common group if they are immediately adjacent in the Z-order. There are a few places in the Windows Control Panel where JAWS handles cases similar to the Team -> CVS -> Ext Connection Method preference page properly, but with a widget spy tool we found that these cases are working because the radios are in fact together in the Z-order, even though they are visually separated by other control(s). It currently seems that the only way to make a case like the Team -> CVS -> Ext Connection Method preference page work would be to create its radios first and then create/layout the other controls between them. The preference page could go out of its way to do this, but of course this is not a good solution. It would also preclude using swt layouts. We will try to contact Freedom Scientific to see if there is anything that can be done here.
SWT's FormLayout can be used to lay out controls in a different order than they were created in. Here is an example snippet, that JAWS reads correctly. import org.eclipse.swt.*; import org.eclipse.swt.layout.*; import org.eclipse.swt.widgets.*; public class RadiosWithTextBetween { public static void main (String [] args) { Display display = new Display (); Shell shell = new Shell (display); Button radio1 = new Button (shell, SWT.RADIO); radio1.setText ("Radio 1"); radio1.setSelection(true); Button radio2 = new Button (shell, SWT.RADIO); radio2.setText ("Radio 2"); Text text = new Text (shell, SWT.BORDER); text.setText ("Type text here"); FormLayout formLayout = new FormLayout (); shell.setLayout (formLayout); FormData data = new FormData (); radio1.setLayoutData (data); data = new FormData (); data.top = new FormAttachment (radio1, 0, SWT.DEFAULT); text.setLayoutData (data); data = new FormData (); data.top = new FormAttachment (text, 0, SWT.DEFAULT); radio2.setLayoutData (data); shell.pack (); shell.open (); while (!shell.isDisposed ()) { if (!display.readAndDispatch ()) display.sleep (); } display.dispose (); } } I am moving this bug to Team to ask them to rewrite the radio group portion of the Team -> CVS -> Ext Connection Method preference page to use this strategy. You should probably use a Composite so that there is only one control sibling between the radios. I suspect that others have run into this problem (since many people use SWT's GridLayout, which lays out controls in their creation order). If you are reading this bug, then the work-around is to create the radios together, and use FormLayout to insert the extra widgets between the radios. Note that, interestingly, Window-Eyes recognizes that there are 2 radios on the Team -> CVS -> Ext Connection Method preference page. So if the FreedomScientific folks want to have a crack at this, that would be great. CC'ing Frank to look into this. Frank, here's a very simple snippet that Window-Eyes reads perfectly (one of two, two of two), but JAWS gets wrong (one of one, one of one): import org.eclipse.swt.*; import org.eclipse.swt.layout.*; import org.eclipse.swt.widgets.*; public class RadiosWithTextBetween2 { public static void main (String [] args) { Display display = new Display (); Shell shell = new Shell (display); Button radio1 = new Button (shell, SWT.RADIO); radio1.setText ("Radio 1"); radio1.setSelection(true); Text text = new Text (shell, SWT.BORDER); text.setText ("Type text here"); Button radio2 = new Button (shell, SWT.RADIO); radio2.setText ("Radio 2"); GridLayout gridLayout = new GridLayout (); shell.setLayout (gridLayout); shell.pack (); shell.open (); while (!shell.isDisposed ()) { if (!display.readAndDispatch ()) display.sleep (); } display.dispose (); } } Frank, please tell FreedomScientific that one thing we do that may be a bit different is that when a BS_RADIOBUTTON gets WM_SETFOCUS, we noticed that Windows was unexpectedly setting the Radio's WS_TABSTOP style bit. We do not want this, so we clear the bit before allowing the Radio to take focus.
Created attachment 145777 [details] Fix v01 Fix suggested by Carolyn in comment 6.
Created attachment 145778 [details] mylyn/context/zip
Carolyn are you fine with the fix or did I miss something?
Sorry for the late response - I am just back from vacation. The patch looks good, and works well. JAWS now correctly says "one of two" and "two of two" for the radio buttons. Window-Eyes also works completely correctly after the patch (before the patch, it did not announce an ordinal for the first radio, although it did say "two of two" for the second radio). Please go ahead and commit the patch, and let me know which Eclipse build it will be in, so that I can verify the fix. --- Unfortunately, this only fixes one place where radios are interleaved with non-radio siblings. Frank, would FreedomScientific be willing to change their algorithm in JAWS to include all radios of a given parent, rather than only consecutive radios?
Here are some other places in Eclipse that have radios that are in the same "radio group", but they have other controls interleaved. JAWS does not read these correctly. If FS says they can't change their algorithm (i.e. possibly other applications are relying on the "consecutive radios" behavior) then I will open bugs to rewrite these cases, but I don't have time to find all cases. Also, there are many Eclipse plug-ins and plain SWT applications that I can't find cases for. 1) File->New->Java Project JRE radios: Use an execution environment JRE:, Use a project specific JRE:, Use default JRE 2) File->Import->General->Existing projects into Workspace Next> radios: Select root directory:, Select archive file: 3) File->Export->Java->Jar file Next> Select a resource to export (you need at least 1 resource in your workspace for this) Type any filename in the Jar file: text field Next> Next> Specify the manifest radios: Generate..., Use existing... Also, Seal contents radios: Seal the JAR, Seal some packages 4) Window->Preferences->Java->Code Style->Clean Up Edit... Code Organizing tab radios: Control statements: Always, Always except for ..., Only if necessary Code Style tab: Expressions radios: Always, Only if necessary 5) Window->Preferences->Plug-in Development->Target Platform Add... Next> Environment tab: Java Runtime Environment radios: Default JRE, JRE Name, Execution Environment
Can you also see the bug we reported in 287450.
Well, an interesting response from Rob at FS. He said that JAWS is already set up to figure that stuff out using IA2. If the method called GroupPosition were used. Any chance of that happening anytime soon?
(In reply to comment #10) > Sorry for the late response - I am just back from vacation. No problem, I was off for couple for two weeks as well. > Please go ahead and commit the patch, and let me know which Eclipse build it > will be in, so that I can verify the fix. Thanks for looking at the patch. It's applied to HEAD and available in builds >N20090912-2000. I will also release it tomorrow so it should be available in I20090915-xxxx. Thanks in advance for verifying it. As this seems to be no longer Team/UI specific issue I would suggest to open a separate bug (against SWT or Platform/UI) and move the discussion there. This could be either a place to discuss how the general issue should be solved (using IA2 maybe) or just a grouping bug for all the sub-bugs you mentioned in comment 11 along with bug 287450 from comment 12. I will prepare the same fix for 3.5.2 stream in a minute and once it's released there I will mark this particular issue as fixed.
Created attachment 147092 [details] Fix v01 for R3_5_maintenance stream
Released to R3_5_mainenance stream, available in 3.5.2 builds including the one being build today (ie 20090930).
<Note by lscales (Lisa B. Scales), 2010/12/08 10:25:30, seq: 23 rel: 0 action: note> I tried this on HATS 8.0 build 201011190501 using RSA 8.0 GM Build IBM? Rational? Software Architect for WebSphere Software V 8.0 (8.0.0.20100812_1346) Our HATS Auto/Disconnect and Refresh Panel has changed since I opened this defect originally but the panel still has 3 radio buttons. I used Jaws 12 and what I got was - Enable client pull (AJAX) one of one - Enable server push (applet - deprecated) one of one - Disabled - one of one So this has "somewhat" changed but the radio buttons still don't read one of three, two of three, three of three which I think should be the case. So this does not seem to be corrected. </Note by Lisa> <Note by Alex from HATS team> I tried to verify the problem with RSA801GM/JAWS12.0.522/HATS8 20101223_1201 and still can re-create the problem as Lisa indicated below on HATS. The problem also can be re-created on the other UI of RSA801 by the following steps. 1. Start JAWS 2. Start RSA801 3. Select File->New->Java Project -Use an Execution environment JRE (one of one) -Use a project specific JRE(one of one) -Use default JRE(currently 'jdk') (one of one). </Note by Alex from HATS team>
Bruce, this bug was against the UI in Team component (see the case described in comment 0). Once I had fixed this I suggested to open separate bugs to address other places with a similar flaw, see comment 14. As for the cases you described, I'm not sure about the first one, but the problem with the Java project wizard should be reported against JDT.
(In reply to comment #18) > Bruce, this bug was against the UI in Team component (see the case described in > comment 0). Once I had fixed this I suggested to open separate bugs to address > other places with a similar flaw, see comment 14. > > As for the cases you described, I'm not sure about the first one, but the > problem with the Java project wizard should be reported against JDT. Hi Tomasz, Our developer James open another defect 333448 for remaining issue. Thanks.
