Closed Bug 356617 Opened 13 years ago Closed 12 years ago
folder properties accessibility: no relationship between page tabs and page contents
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:126.96.36.199) Gecko/20060921 Ubuntu/dapper-security Firefox/188.8.131.52 Build Identifier: version 3 alpha 1 (20061013) According to the AT-SPI, the folder properties dialog contains a page tab list and one scrollpane which contains the components of all the pages. In other words, there is no relationship between a page tab and the contents of the page. This means an assistive technology cannot present the contents a page because it cannot determine what is in the page, and what belongs in another page. This is a significant accessibility problem which makes the folder properties inaccessible to a person with a visual disability. Reproducible: Always Steps to Reproduce: 1. Start Thunderbird and launch the folders properties dialog 2. Launch at-poke 3. Notice there is one page tab list and one scrollpane containing the contents of all the pages. Actual Results: The AT-SPI reports one scrollpane with the contents of all pages. Expected Results: The AT-SPI should report the contents of each pages.
firefox also has the some problem. like tabs in preference->advanced.
Status: UNCONFIRMED → NEW
Component: General → Disability Access APIs
Ever confirmed: true
Product: Thunderbird → Core
Version: unspecified → Trunk
To add more to this...the containment hierarchy for pages and page tabs as represented by Gecko is quite different from what we see with GAIL. In GAIL, a page tabe list contains page tabs and the contents of a page tab are represented as children of the page tab. In Gecko, the page tab list and page tabs are represented in a separate hierarchy from the contents of the page tab. Thus, it is quite difficult (impossible?) for an assistive technology to tell if a user is in the content area of a Gecko page tab or not.
willie and lynn, if bug 357969 is solved with solution 2. do you think your problem here is solved?
Nian: I don't understand the solution being proposed. :-( Is it as follows? 1) We'll end up with a hierarchy similar to that presented by GTK+: Page tab list | +---Page tab | | | +---contents of page tab | +---Page tab | | | +---contents of page tab |... 2) The only thing showing in the hierarchy will be the Page tab list, the page tab that is active/focused, and the page tab's contents? If so, I think we might be able to work with this.
I think the solution 2 doesn't make much different to current behavior. Contents of non-active/focused tab don't have ATK_STATE_SHOWING. We don't have a problem unless the dialog has a scrollbar.
(In reply to comment #4) > Nian: I don't understand the solution being proposed. :-( Is it as follows? > > 1) We'll end up with a hierarchy similar to that presented by GTK+: > > Page tab list > | > +---Page tab > | | > | +---contents of page tab > | > +---Page tab > | | > | +---contents of page tab > |... > > 2) The only thing showing in the hierarchy will be the Page tab list, the page > tab that is active/focused, and the page tab's contents? > > If so, I think we might be able to work with this. > solution 1 is like page tabs --page tab 1 --page tab 2 --page tab 3 ..... --page tab 1 container ----page tab1 content --page tab 2 container ----page tab2 content .... solution 2 is just same as you described in 2
I'm having trouble understanding how to manage this non-standard split hierarchy where the page tabs are in one hierarchy and the contents are in another. If one gives focus to an object in the contents of a page tab, how do I know which page tab it's "in"? This is important information to be able to present and it's not clear to me how to do this.
The primary issue is the correct parent-child relationship between a tab and the container. Assistive technologies expect something like page tab list ... page tab 1 ...... pane ......... text or some other components ... page tab 2 ...... pane ......... text or some other components ... page tab 3 ...... pane ......... text or some other components Start up gedit and create three documents. You will end up with three page tabs, one for each document. Run at-poke and you will see a structure like the one above. This is the structure assistive technologies like Orca need.
Severity: major → critical
Hi guys. Thanks for all your effort so far. Right now, there are only two critical accessibility bugs: this one and bug 365973. If you can fix these two, Thunderbird accessibility will be a lot better. Thanks!
not sure what should be the solution. cc aaron i think make an accessible object for the container(here is tabpanel) will be helpful for at tools to know the structure of the tree. hence help the user. that will be decoupled into two seperate bugs. 1)bug 357969 and 2)bug 366527. aaron and ginn, what's your opinion?
Assistive technologies need to be able to recursively ascend and descend the object hierarchy. This is a pretty important requirement.
per comment #11, mark as a dupe of bug 366527. (since bug 357969 is resolved)
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 366527
You need to log in before you can comment on or make changes to this bug.