Now that the blocking bug (https://bugzilla.mozilla.org/show_bug.cgi?id=366527) for bug 362627 has been fixed, we should consider including the page tab name/role in the braille context for objects in a page tab.

As a result of the bug fix, we now end up with a hierarchy of parallel objects:

+-panel
  +-page tab list
    +-page tab a (basically just a label with label for property set)
    +-page tab b (basically just a label with label for property set)
    +-page tab c (basically just a label with label for property set)
    +-page tab d (basically just a label with label for property set)
    +-page tab e (basically just a label with label for property set)
  +-scroll pane (labelled by a page tab)
    +-actual page tab a contents
  +-scroll pane (labelled by b page tab)
    +-actual page tab b contents
  +-scroll pane (labelled by c page tab)
    +-actual page tab c contents
  +-scroll pane (labelled by d page tab)
    +-actual page tab d contents
  +-scroll pane (labelled by e page tab)
    +-actual page tab e contents

This differs from GTK+, where the page tab contents are nested under the page tab object.  As such, with the GTK+ hierarchy, we easily get the page tab label and name because it's part of the object ancestry.  With the Gecko hierarchy above, it's not so easy, but I think we can work with it.

As a possible way to work this into the braille context, we could include a check for a scroll pane that's labelled by a page tab in braillegenerator.py:getBrailleContext.  If so, we add in the name and role of the page tab.  For verification of the output, the braille presentation should be very similar to the output given by a GTK+ page tab list (e.g., the gnome-terminal preferences dialog).