Details would be good....

current there is no 1-1 relationship mapped between tab and tabpanel accessible object. without that, AT users will have difficultity to know which tabpanel content is for what tab.

ref bug 357969 comment#32

william, a tmp solution here is that after 357969 is fixed, at can use showing attribute to decide current tabpanel with selected tab.

Hi Neo: I need tab information the other way around. That is, when I'm looking at a tab panel, how do I determine which tab it is in?

(In reply to comment #5) > Hi Neo: I need tab information the other way around. That is, when I'm > looking at a tab panel, how do I determine which tab it is in? > if you can navigate the tabs list, current tab has the attribute "selected"

Given a tab panel, is there a simple way for me to find the tab list? For example, will we be guaranteed that the parent of the tab panel is the same parent of the tab list?

with domnode, the structure is as below tabbox --tabs --tab1 --tab2 --... --tabpanels --tabpanel1 --tabpanel2 --...

Will this structure be guaranteed for all tab structures we will encounter from Gecko? For example, are there other tab structures besides domnodes that will be presented by Gecko via the AT-SPI? If so, will they have the same structure?

(In reply to comment #9) > Will this structure be guaranteed for all tab structures we will encounter from > Gecko? For example, are there other tab structures besides domnodes that will > be presented by Gecko via the AT-SPI? If so, will they have the same > structure? > that what XUL defines. i haven't seen any other ways. cc neil to make sure

Although I've not seen it used myself, our XUL tab code allows for intervening DOM nodes between the <tabbox> and its associated <tabs> and <tabpanels>.

(In reply to comment #11) > Although I've not seen it used myself, our XUL tab code allows for intervening > DOM nodes between the <tabbox> and its associated <tabs> and <tabpanels>. > Neil, so tabs and tabpanels are still in the same level in the parent-child tree? orca still can use tabpanel->parent(tabpanels)->previous sibling(tabs)->children(tab) to get the tab?

Although that's the only way I've seen it done, it's technically feasible for someone to come up with a different configuration which would still operate.

Ginn, can you look into this? Perhaps it's already fixed.

almost there. but we still don't have a relation between "page tab" and "scroll pane" at tools can do a counting by itself, e.g. third "page tab" in "page tab list" is for third "scroll pane" If we want to use ATK_RELATION, which one should we use? ATK_RELATION_CONTROLLED_BY/CONTROLLER_FOR?

My apologies for being confused. :-( I'm confused about what was changed and what the proposed algorithm for ATs is, and I'm also wondering how (or if) this bug is different from bug 356617? In the fourth comment of that bug (https://bugzilla.mozilla.org/show_bug.cgi?id=356617#c4), I outline what would be an expected behavior from an ATs standpoint (this is the way GTK+ does it). Is this something that cannot be achieved?

I thought we have solution #1 already. As far as relations, I don't know what GTK+ does, but controllerfor/by doesn't make sense. That relation should only be used when we want children-changed events to be spoken in regions that are controlled by the current focus. That's how ARIA live regions thinks of that relationship pair. However, I think it makes plenty of sense to use labelfor/labelledby between each tab and each tab panel. But, this might not be consistent with GTK.

> I thought we have solution #1 already. My understanding is that we don't get what GTK+ and other AT-SPI implementations give ATs, which is what we'd like: Page tab list +---Page tab | +---Some container +---Page tab | +---Some container |... (Actually, the page tab itself can act as a container). The current hierarchy we see is this: Panel +--- Page tab list | +---Page tab | +---Page tab | +---... +--- Some container (scrollpane) +--- Some container (scrollpane) ... Right now, I don't believe there is any relationship between the page tabs and the scrollpanes, which is what I'm guessing Ginn is proposing. Mucking around with accessible relations might be a way to do this, but it is going to be yet more special code that both Firefox and the ATs are going to need to deal with. Ideally, Gecko would be consistent with GTK+ here. If not, however, maybe there is just some pattern the AT could look for when attempting to determine if something is in a page tab or not. This pattern might just be that the object is nested in a scroll pane and the parent of that scroll pane is a panel that also has a child that's a page tab. If this pattern is unique and is how Gecko is going to do it, then we might be able to work with it (if our ideal of seeing consistency with GTK+ cannot be realized, of course).

I see -- yes it would be difficult to do it like GTK. What do you do with the logic where you connect the tab with the panel?

> What do you do with the logic where you connect the tab with the panel? As one switches between page tabs, Orca presents the new page tab name along with the thing in the page tab that has focus. With AT-SPI implementations that put the page tab in the hierarchy as GTK+ does, it's an easy process for us. If I recall, we currently do nothing with Firefox because we're waiting for the resolution of this bug and bug 356617.

Does it have the same behavior if focus is: 1) in the tab list, 2) in the location or search box or 3) in content? Also, since this has to do with speaking the label for something, it seems *exactly* like what the labelfor/by relationship was intended for. We're going to face this issue in ARIA page tabs as well. We can ask the authors to use the label relationship in those cases, as part of our developer docs and style guide.

I think we have two different use cases here. One is in the preferences/configuraton dialogs that Firefox brings up, and the other is in HTML content. In all cases, if the focus moves from outside a page tab to the inside of a page tab, we want to present the name of the page tab the user moved into. If the focus ends up on the page tab itself, we just present the name of the page tab. > Also, since this has to do with speaking the label for something, it seems > *exactly* like what the labelfor/by relationship was intended for. Gecko is deviating from the norm here, so we just need something we can work with. If we end up with a scroll pane being labelled by a page tab, I guess we can work with that.

Let's move ahead with the label relations solution. Unfortunately Gecko doesn't have the same object hierarchy as other things but I'd rather not change that. This makes it similar to a groupbox with a name, as you enter the groupbox it should read the focused item in addition to the label for the groupbox.

Note, there is an Javascript property called linkedPanel on each browser tab, which points to the ID of the panel it's for. Unfortunately I only see that set on the tab browser tabs.

(In reply to comment #23) > Let's move ahead with the label relations solution. Unfortunately Gecko doesn't > have the same object hierarchy as other things but I'd rather not change that. I guess label_for on tab, label_by on tabpanel. Correct?

(In reply to comment #24) > Note, there is an Javascript property called linkedPanel on each browser tab, > which points to the ID of the panel it's for. Unfortunately I only see that set > on the tab browser tabs. > Every tab (not only browser tab) can have linkedPanel property. linkedPanel can be used to link several tabs with one tabpanel element (http://xulplanet.com/references/elemref/ref_tab.html#attr_linkedpanel). It means we can use linkedPanel only after bug 345780. Also since bug 345780 should update paired relations when one of them is changed then it makes sense to fix the bug after mentioned one because otherwise we need to have specific accessible class for tabpanels.

Surkov, can you impl labelled_by/label_for these? Not as urgent as our cache/crash bugs, but important.

We need to do this for ARIA tabs as well.

(In reply to comment #31) > We need to do this for ARIA tabs as well. > how ARIA tab and tabpanels are related? Can I assume if I select first tab then first tabpanel is visible?

I think Aaron is talking about DOM elements marked up (with ARIA) role tab, and tabpanel. They need to also have the relationships (labelled_by/label_for). Aaron is the onus on the DHTML author or FF for this relationship?

(In reply to comment #33) > I think Aaron is talking about DOM elements marked up (with ARIA) role tab, and > tabpanel. They need to also have the relationships (labelled_by/label_for). Sure Aaron is talking about this. But I mean which tab is label for which tabpanel and visa versa?

(In reply to comment #33) > Aaron is the onus on the DHTML author or FF for this relationship? > If I treat Aaron correct then dhtml author is able to set relationship but if he didn't care about this then FF should care. But by what algorithm?

You're right, ARIA author needs to put labelledby -- I forgot about that.

(In reply to comment #36) > You're right, ARIA author needs to put labelledby -- I forgot about that. > So, I shouldn't care now about ARIA tab/tabpanel, right?

Right. My mistake.

Looks good to me. 2 comments. 1) + // XXX: It makes sense to require the interface from xul:tab to get linked + // tabpanel element. This comment is for the code above not below, right? I think it should move to in front of + nsAutoString linkedPanelID; + content->GetAttr(kNameSpaceID_None, nsAccessibilityAtoms::linkedPanel, + linkedPanelID); 2) + while (childAcc) { + if (Role(childAcc) == nsIAccessibleRole::ROLE_PROPERTYPAGE) { + if (tabIndex == 0) + break; + + tabIndex--; + } + + nsCOMPtr<nsIAccessible> acc; + childAcc->GetNextSibling(getter_AddRefs(acc)); + childAcc.swap(acc); + } + + if (tabIndex == 0) + NS_IF_ADDREF(*aRelatedAccessible = childAcc); I think we should put "NS_IF_ADDREF(*aRelatedAccessible = childAcc);" together with "break;", so we can save a "if (tabIndex == 0)".

with ginn's comments

checked in

in-testsuite?

in-testsuite+ from bug 475330