Community
Participate
Working Groups
<Note by jkingdon (Kingdon, James (J.B.)), 2006/02/21 10:18:00, seq: 1 rel: 0 action: open> Testing the default tab order, the focus visits hidden fields in the collapsed sections: After expanding and collapsing the sections the tab order is correct, so it looks like a problem with the initial set-up of the editor. The collapsible sections are controlled by two elements, a visual triangle and a text 'link' containing the name of the section. Both elements are on the tab path. When the editor is first opened the triangles read as "zero closed outline" or "zero expanded outline" and the text elements read as their content followed by the word "link". 1) Why do the triangles read as "zero"? 2) When a section is collapsed or expanded by pressing enter on the triangle, the read text is not updated to reflect the changed state, i.e. expanding a closed section causes the words "closed outline" to be spoken, and closing an expanded section produces the words "expanded outline". 3) Further presses of enter on the triangle produce no spoken output at all. 4) After a period of tab navigation in the editor, the triangles, section titles and the 'edit' links all lose their original spoken text and read as "custom control" 5) Randomly, tab navigation in the server editor whilst running window eyes results in a complete crash of eclipse with jvm exit code 128. This intermittent problem can be hard to reproduce, but occurred three times this morning. <Note by jkingdon (Kingdon, James (J.B.)), 2006/02/22 09:45:15, seq: 4 rel: 0 action: note> Kenneth suggested that the problems might be with the Window Eyes screen reader, so I checked the server editor with JAWS. The behaviour is much better, problems 2 and 4 are definitely not present, and I also saw no crashes whilst testing with JAWS, so 5) may be specific to Window Eyes as well. The read out for a triangle widget is better than with Window Eyes and includes the name of the section. I would recommend taking the 'link' text item off the tab path to avoid the redundancy and suppressing the distracting 'zero' value for the triangle widget. Since this defect is now a record of incompatibility with Window Eyes plus a suggestion for improvement, I'll downgrade the severity.
Chris, we should implement improvements as described at the end of the comment: <quite> I would recommend taking the 'link' text item off the tab path to avoid the redundancy and suppressing the distracting 'zero' value for the triangle widget. </quote>
I just took a look at the accessibility of ExpandableComposites and Sections for bug 229494. I found that the twisties no longer read "zero" on focus. Regardless I have improved how the twisties are read by screen readers, so that suggestion will be addressed. As far as removing the link from the tab path goes, it is only added if the appropriate style bit (FOCUS_TITLE) is set on the ExpandableComposite/Section, so this is up to the implementer. Since bug 229494 will address the only outstanding issue, I'm going to close this as a DUPLICATE. Kenneth, please feel free to test this further and open new bugs once the patch for bug 229494 goes into HEAD after 3.4 is declared. *** This bug has been marked as a duplicate of bug 229494 ***