356863 - right-hand account settings panels are not accessible

Status: RESOLVED FIXED

(Thunderbird :: Account Manager, defect)

Description

[Lynn Monsanto]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20060921 Ubuntu/dapper-security Firefox/1.5.0.7
Build Identifier: version 3 alpha 1 (20061013)

The right-hand account settings panels are not accessible. The AT-SPI returns a panel containg another panel. Both panels have the name: chrom://messenger/content/am-smtp.xul. None of the internal components are accessible when recursively descending the accessibility hierarchy. Some components like buttons and checkboxes are spoken correctly by the Orca screen reader. Other components, like combo boxes, are not spoken correctly.

Reproducible: Always

Steps to Reproduce:
1. Start Thunderbird and launch the account settings dialog
2. Start at-poke and expand Thunderbird
3. Note that the right-hand settings panel contains only a single panel with no subcomponents
4. Start the orca screen reader and tab through the right-hand panel. Note that only some of the components are spoken correctly. Also note that "chrom://messenger/content/am-smtp.xul" is spoken as the name of the account dialog.

Actual Results:  
See details and steps-to-reproduce above

Expected Results:  
The entire accessibility hierarchy in the right-hand panel should be accessible by the AT-SPI.

This is an accessibility bug. Contact [e-mail] for more information.

Comment 1

[Evan Yan]

Attachment: patch

nsDocAccessibleWrap shouldn't impl QueryInterface, that will override the QI implementation in nsDocAccessible, and make xul doc accessible object QI to nsIAccessibleText, which caused this bug.

Comment 2

[Evan Yan]

Aaron,

The patch fixed the problem of not exposing children of xul doc, but doesn't deal with the problem that the name of the panel is a chrome url.

the right-hand panel is a <iframe>, which will dynamically load some <page> into it when user clicks on the left-hand items.
we didn't define a 'title' attribute for these <page>s, so GetName will fall down to use the chrome url as it's name.

It seems not a good solution to add 'title' attribute for each <page> manually. 

do you have any idea on this?

Comment 3

[Alfred Peng]

Checking in accessible/src/atk/nsDocAccessibleWrap.h;
/cvsroot/mozilla/accessible/src/atk/nsDocAccessibleWrap.h,v  <--  nsDocAccessibleWrap.h
new revision: 1.10; previous revision: 1.9
done
Checking in accessible/src/atk/nsDocAccessibleWrap.cpp;
/cvsroot/mozilla/accessible/src/atk/nsDocAccessibleWrap.cpp,v  <--  nsDocAccessibleWrap.cpp
new revision: 1.33; previous revision: 1.32
done

Comment 4

[Evan Yan]

leave this bug OPEN since the problem talked in comment #2 is not solved yet.

Comment 5

[Lynn Monsanto]

Hi Evan, I understand why you want to keep the bug open, but this is no longer a problem for Orca.  Thanks for your work!

Comment 6

[Evan Yan]

Thanks for your feedback, Lynn.
I'm closing this bug.