366527 - build 1-1 relation between tab and tabpanel for accessible object

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

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

Comment 1

[Mike Connor [:mconnor]]

Details would be good....

Comment 2

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

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.

Comment 3

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

ref bug 357969 comment#32

Comment 4

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

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

Comment 5

[Willie Walker]

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?

Comment 6

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

(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"

Comment 7

[Willie Walker]

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? 

Comment 8

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

with domnode, the structure is as below

tabbox
  --tabs
    --tab1
    --tab2
    --...
  --tabpanels
    --tabpanel1
    --tabpanel2
    --...

Comment 9

[Willie Walker]

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?

Comment 10

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

(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

Comment 11

[[e-mail]]

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>.

Comment 12

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

(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?

Comment 13

[[e-mail]]

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.

Comment 14

[Aaron Leventhal]

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

Comment 15

[Ginn Chen]

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?

Comment 16

[Willie Walker]

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?

Comment 17

[Aaron Leventhal]

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.

Comment 18

[Willie Walker]

> 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).

Comment 19

[Aaron Leventhal]

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?

Comment 20

[Willie Walker]

> 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.

Comment 21

[Aaron Leventhal]

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.

Comment 22

[Willie Walker]

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.

Comment 23

[Aaron Leventhal]

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.

Comment 24

[Aaron Leventhal]

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.

Comment 25

[alexander :surkov (:asurkov)]

(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?

Comment 26

[alexander :surkov (:asurkov)]

(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.

Comment 28

[Aaron Leventhal]

Surkov, can you impl labelled_by/label_for these?

Not as urgent as our cache/crash bugs, but important.

Comment 29

[alexander :surkov (:asurkov)]

Attachment: wip

Comment 30

[alexander :surkov (:asurkov)]

Attachment: wip2

Comment 31

[Aaron Leventhal]

We need to do this for ARIA tabs as well.

Comment 32

[alexander :surkov (:asurkov)]

(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?

Comment 33

[David Bolter [:davidb] (NeedInfo me for attention)]

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?

Comment 34

[alexander :surkov (:asurkov)]

(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?

Comment 35

[alexander :surkov (:asurkov)]

(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?

Comment 36

[Aaron Leventhal]

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

Comment 37

[alexander :surkov (:asurkov)]

(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?

Comment 38

[Aaron Leventhal]

Right. My mistake.

Comment 39

[alexander :surkov (:asurkov)]

Attachment: patch

Comment 40

[Ginn Chen]

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)".

Comment 41

[alexander :surkov (:asurkov)]

Attachment: patch2

with ginn's comments

Comment 42

[alexander :surkov (:asurkov)]

checked in

Comment 43

[alexander :surkov (:asurkov)]

in-testsuite?

Comment 44

[alexander :surkov (:asurkov)]

in-testsuite+ from bug 475330