Bugzilla – Full Text Bug Listing
| Summary: | [Dialogs] Cannot read indirect child controls in dialogs with JAWS | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | mojit |
| Component: | UI | Assignee: | Tod Creasey <Tod_Creasey> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | carolynmacleod4, david_williams, dbennett, dipalerm, for.work.things, kmbauer, n.a.edgar, omosaiye, paulacox, Tod_Creasey, turnham, veronika_irvine |
| Version: | 2.0 | Keywords: | accessibility |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | |||
| Bug Depends on: | 21771 | ||
| Bug Blocks: | |||
|
Description
mojit
That dialog is built by the UI team. If the label has or can be given an id, then scripting could be used to read it when it changes. Dialogs can be read using the JAWS cursor. Please elaborate on the id for the label required - this label is defined in the superclass and so it would be possible to give it a name for all MessageDialogs. Also please let us know about how to use a script in JAWS to test this. As stated before JAWS cursor or INS-B are not adequate solution to this problem since the user has no idea when an error is displayed on the screen. The Accessibility center should be contacted for guidance on fixing this problem. any new updates on this problem? In the latest SWT and UI plugins it is now possible for the title of a message box to be read using JAWS. As the label is the first widget created and now a child of the shell it is read both when then dialog comes up and when Ins-B is used to read the entire dialog. Other widgets must still be tabbed to but they can all still be read so in most cases all widgets are accessible to JAWs and in all cases the main message will be found by JAWS. JAWs will read any widgets that are direct children of the shell which in the new implementation is only the label. To make the buttons children of the shell would require a breaking API change which may be considered for 3.0 as a large number of dialogs are subclasses of MessageDialog. There will be a new build sometime on the week of the 15th of July that will have this new support. Reducing to P3 as error messages are now accessible. Marking as later as making any more of the widgets direct children of the shell will require an API change. The fixes Tod refers to above were released in yesterday's integration build. *** Bug 15576 has been marked as a duplicate of this bug. *** With the fix in yesterday's build, JAWS now reads the title and message of a message dialog when it appears and when using Ins+B. This is a major improvement, but does not solve the problem in general. Other controls on the dialog which are not direct children of the shell are still not read. This includes the OK/Cancel buttons, and any other controls added by subclasses of MessageDialog. For example, in the delete project dialog (select a project and choose delete), the radio buttons for "Also delete contents" / "Do not delete contents" are not read automatically when the dialog appears or when using Ins+B. If the controls can take focus, then they can be read by giving them focus. If there are other labels in the dialog, they still cannot be read. Also, for wizard dialogs, property dialogs and the preferences dialog, the title will be read, but other controls such as the descriptive label will not be read since they are not direct children of the shell. It will be very difficult for us to fix this in general, and next to impossible to change this without introducing breaking API changes. We should encourage Henter Joyce to include indirect children of the shell when reading the dialog when it appears, and when using Ins+B. Correction: the SWT fix to use role=dialog instead of role=client did not make it into yesterday's integration build, but it is available in the last nightly build (20020617 nightly). It will be in next Tuesday's integration build. Correction to the correction: 20020717 nightly Reopening PR so that we can track progress with Henter-Joyce. As of build 20020723 the direct children of the shell of a dialog will be read. However the Ins B (read in Tab Order) feature does not currently work - SWT is still investigating what information JAWS is asking for. Renaming to Cannot read tab order with JAWS as the error message can now be read. There are still two main problems: 1. When a dialog first appears, JAWS reads the title, the direct children of the shell, and the control that has focus, but does not read indirect children (exception: it will read the focus control even if it is an indirect child). 2. When using Ins+B to read the dialog, it has similar limitations. However, the underlying behaviour is different. Unlike case 1, JAWS actually asks for the indirect controls and for their name, state, role, etc. However, it ends up not reading the information it requested. Need to include the fixes for this in 2.0.1 (including the SWT dialog class change). Fixes have been released to the 2.0.1 stream. Marking for 2.1 as we will need support from Hentor Joyce to go any further. Comments from Accessibility Center: <SR: Freedom has not responded to notes we sent on their support for indirect children. I need to understand how you determined that "JAWS has the capability to pick them up". I'm trying my dev contacts at Freedom to see if we can get an answer from them.> When we implement the Windows IAccessibility interface JAWS is asking the widget for the accessible value but does not report it to the user. Veronika can elaborate. *** Bug 19924 has been marked as a duplicate of this bug. *** *** Bug 8879 has been marked as a duplicate of this bug. *** Cannot commit to this for 2.1. Waiting to hear from accessibility center on feedback from Freedom Scientific re bug 21771, on which this bug depends. Tried this again with the JAWS 5.0 upgrade (5.00.809). I think I see what you are saying about INS+B not reading all of the controls, but I am not sure that this is really required to read this dialog (or similar dialogs). All controls can be read when they have focus - including the error message label (now an edit box) that was the original problem. Note that bug 21771 does not have anything to do with this dialog, as all of the buttons in this dialog are standard OS buttons with WindowText (i.e. set using SWT's API: Button.setText). What I am saying is that I think this bug report can be closed, because I think the dialog is accessible. Please advise. We have done all that is possible here - Bug 21771 describes any other work than can be done. Marking closed |