356617 - folder properties accessibility: no relationship between page tabs and page contents

Status: RESOLVED DUPLICATE of bug 366527

(Core :: Disability Access APIs, 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)

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.

Comment 1

[Evan Yan]

firefox also has the some problem. like tabs in preference->advanced.

Comment 2

[Willie Walker]

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.

Comment 3

[Nian Liu(n/a in a long time)]

willie and lynn, if bug 357969 is solved with solution 2. do you think your problem here is solved?

Comment 4

[Willie Walker]

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.

Comment 5

[Ginn Chen]

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.

Comment 6

[Nian Liu(n/a in a long time)]

(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

Comment 7

[Willie Walker]

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.

Comment 8

[Lynn Monsanto]

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.

Comment 9

[Lynn Monsanto]

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!

Comment 10

[Lynn Monsanto]

Fixed a typo in comment #9.  The other critical bug is bug 365866

Comment 11

[Nian Liu(n/a in a long time)]

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?

Comment 12

[Lynn Monsanto]

Assistive technologies need to be able to recursively ascend and descend the object hierarchy. This is a pretty important requirement.

Comment 13

[Ginn Chen]

per comment #11, mark as a dupe of bug 366527. (since bug 357969 is resolved)

Comment 14

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1527381