The new page info screen has not gone through an accessibility review. It needs to be tested with Window-Eyes, JAWS, LSR and Orca to look for problems. Right off the bat I noticed the MSAA focus events weren't being fired as I arrowed across the buttons on the top, which means those items wouldn't get spoken. Don't bother testing with LSR and Orca until we fix the Linux crasher bug 377767.

Category list: Screen readers report five items, but there seem to be only four. Is there a fifth that only appears in certain situations? General, Media, work as expected. Permissions: Tab only identifies "use default check box" instead of reading each option. Actual: "Use default check box checked". Expected: Cookies: Use Default check box checked". Once a check box is unchecked, it's associated radio buttons aren't grouped with the option. Actual: "Allow radio button checked". Expected: "Cookies: allow radio button checked". Security: Window-eyes works as expected. Jaws: Website identity group works as expected. Privacy group: Jaws does not speak the label of each field, only the Privacy grouping. Actual: "Privacy: read-only edit read-only: no". Expected/Window-eyes: Privacy History: Have I visited this website before today?: read-only edit: no". Jaws has excessive verbiage: Actual: "Website identity verified by: read-only edit read-only: Thawte Consulting". Expected: Website identity verified by: read-only edit: Thawte Consulting". Jaws verbiage problem is ongoing, not associated with this bug.

Tim, can you ask the appropriate front-end folks whether they want separate bugs filed for each of those items? Most of the work should be marked as blocking Firefox 3 unless there's a good reason not to.

Using Orca 2.19.90 pre and Minefield from August 3: 1. Page tabs are not spoken as such. Orca only says "General" without giving a specific window type. 2. General Page: a) The first Text field has no label spoken, and Orca does not detect one using flat review. b) Security Information for this Page: Panel title is spoken, Associated text is not spoken, only the More button is announced. 3. Media Page: a) Address column header is spoken, but right arrowing does not speak Type column header. Instead, focus jumps to the next address (using the Minefield start page as an example), another Right Arrow jumps to the type "background". 4. Permissions Page: a) Permissions for: label is not spoken. b) Load Images, Open Popup Windows, Set Cookies, Install Extensions or Themes: All these panel labels are not spoken. Orca only announces "use defaults checkbox checked" for each item. c) Same is true for the radio buttons if one of the above checkboxes is unchecked. The panel labels are also not spoken for any of the radio buttons. 5. Security Page: a) Privacy and History Panel: None of the labels for the edits are spoken. The label of the panel itself is spoken when first tabbing into it.

According to Accerciser, I see the following problems/oddities: 1) There is an extra scrollpane with an empty list as a child between the Media and Permissions panes. 2) There are no label relations set for the Permissions items. 3) The Media scrollpane->tree has an odd hierarchy. It contains a 'list' with 'table cell' children, including three extra children. Each extra child is a repeat of the last valid child. 4) Much of the textual information shows up as an 'entry' instead of 'text'.

Regarding Scott Haeger's comment 4: For item #2 (no label relations), that seems like an obvious problem where they probably forgot the control attribute for <label> and <description> elements. For item #4 (ROLE_ENTRY instead of TEXT), that must mean they used <textbox> -- perhaps readonly textboxes. That might be on purpose to make it easier to copy and paste the text.

Why is there qawanted on this bug? In the latest-trunk from today, 09-07-04, the groupings are still not spoken on the Permissions tab.

I am currently testing out fixes for some of these, especially the groupings and one of the missing label relations, which is actually only a typo in the id (a lowercase t instead of an uppercase T). There is one major issue, regarding the Security And Privacy page: Sentences like "Have I visited this web site before?" etc., are XUL:description elements. They must be, because they may wrap, as seen in one instance. And even though these XUL:description elements have a control attribute, the XUL accessibility does not associate them as labels with the desired controls. Aaron, would it be feasible to implement something like this: 1. If a XUL:description element has a control attribute, treat it as if it was a label for a control. 2. If it does not, use the current behaviour/accessibility implementation.

This patch addresses the following issues: 1. HostName label not spoken. This was a simple typo, a lower-case t was being used where an upper-case T would have been appropriate. 2. Associated the labels for the different permissions radio groups. This does not solve the problem of the checkboxes only speaking "Default", but not which item should be left at the default. 3. On the Security & Privacy page, added hidden labels for the textboxes whose prompts are not spoken by JAWS and Orca. On this, I have the following questions: 1. Is the visual appearahce of the dialog page altered by adding a hidden label? 2. Is this a proper method to explicitly label something for accessibility if no visually visible cues are possible?

This patch gets rid of the hidden labels, and converts the XUL:description elements into XUL:label elements. If the label's caption is enclosed within opening and closing tags like XUL:description elements, it also wraps. So simply changing the tag was sufficient to get things talking, and still retain the normal visual layout. Joanie, can you test this on Linux and see if you find anything odd?

This patch assigns the wairole:group to the boxses that enclose the checkboxes. Once bug 388185 is checked in, this should enable all the groupboxes to speak properly. It worked with JAWS with my compiled test build that also contains patch for bug 388185.

Turning this bug into a metabug that depends on at least two other bugs that I'll create shortly.

Should this be closed up or is there something else to do? All dependencies have been fixed.

Setting this bug to resolved. All bugs this bug depends on have been resolved.