259052 - No accessible object for items (Glossary, Index, Search, Contents) on Help dialog

Status: RESOLVED WONTFIX

(Core :: Disability Access APIs, defect)

Description

[Louie Zhao]

For Gnopernicus, steps to Reproduce:
1. Press <F1> to open help window
2. Press <F6> to switch to the left pane
3. Press <Tab> to focus 4 items (Glossary, Index, Search, Contents) one by one

Actural Result:
Nothing is reported.

Expected Result:
braille should output: Glossay, Index, Search, Contents one by one

In addition, GOK can't grab 4 buttons (Glossary, Index, Search, Contents) in
UI-Grab.

Comment 1

[Louie Zhao]

There is no accessible object for button whose class is "box-texttab" because
"box-texttab" is defined in theme and has not implement nsIAccessible interface.
The attached patch is to implement nsIAccessible for "box-texttab" under each theme.

Here, I have a question about XBL:

Why can't <binding id="sbtab" extends="xul:button">
(http://lxr.mozilla.org/seamonkey/source/themes/classic/communicator/sidebar/sidebarBindings.xml#8)
inherit nsIAccessible from 
"chrome://global/content/bindings/button.xml#button" since "xul:button" is
defined in xul.css as "chrome://global/content/bindings/button.xml#button"
(http://lxr.mozilla.org/seamonkey/source/xpfe/global/resources/content/xul.css#108)
?

If this can work, we don't have to implement nsIAccessible for <binding
id="sbtab" ...> under each theme.

I have tried to replace 'extends="xul:button"' with
'extends="chrome://global/content/bindings/button.xml#button"' for <binding
id="sbtab">. Although it fixed this bug, the appearance of the button has been
changed. Is there any difference between "xul:button" and
"chrome://global/content/bindings/button.xml#button"?

I can't find answer from the current XUL/XBL document. Can someone who is
familiar with XUL/XBL give some light on these questiones? Thanks very much.

Comment 2

[Louie Zhao]

Attachment: proposed patch

Comment 3

[[e-mail]]

extends="xul:button" just means that gecko creates a button frame.
(It does this automatically for a xul button, checkbox or radio).

You can't have implementation in the theme, it won't work.

I didn't actually think that the buttons were focusable.

For some reason the focus setting when you use alt+shortcut isn't working :-(

Comment 4

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

Attachment: something related

this attatchment is for making sidebar tab keyboard accessible and at the same
time as a side product, making help accessible for sun mozilla1.7. due to the
code difference, some part in the patch is not suitable for community mozilla.
i create a bug 256815

Comment 5

[Louie Zhao]

Comment on attachment 158718 [details] [diff] [review]
proposed patch

The patch has been obsolete.

Comment 6

[Aaron Leventhal]

Attachment: Legitimize sidebar tabs as real tab widgets, created by a <tabbox orient="horizontal"> with a child <tabs> which itself has <tab><tabpanel> pairs as children

The help.xul changes are large because the contents tab has been moved first in
the order, and because the indent changed on the other tabs since the <tree>s
are now wrapped in <tabpanel>s.

Comment 7

[[e-mail]]

Comment on attachment 180664 [details] [diff] [review]
Legitimize sidebar tabs as real tab widgets, created by a <tabbox orient="horizontal"> with a child <tabs> which itself has <tab><tabpanel> pairs as children

Because this is patched Firefox help, I can only make general comments.

>+    // Initialize index
>+    expandAllIndexEntries();
Might want to do this in a select event handler to defer this until the index
is opened.

>+    // Initial focus in first tree view
>+    setTimeout("helpTocPanel.focus()", 0);
I'm not keen on the string form of setTimeout, although here it's shorter.

>+tab + tabpanel /* Sidebar tabpanel */
>+{
>+  visibility: collapse;
>+  -moz-box-orient: vertical;
???

I'm not convinced that you should overload the meaning of tab. All you need are
the correct accessible objects, right? But if you do want that, then I think
Ben made it so you can set an initial index.

Comment 8

[Aaron Leventhal]

(In reply to comment #7)
> I'm not convinced that you should overload the meaning of tab. All you need are
> the correct accessible objects, right? But if you do want that, then I think
> Ben made it so you can set an initial index.

In my opinion these are tabs. They look and act like them. Ctrl+tab moves
between them. Selecting them makes a different pane visible. Otherwise, what
kind of widget should they be?

Or perhaps you are saying they can might tabs in terms of accessibility objects,
but not in toolkit. I was hoping to keep it this way, not just for Firefox help
but this patch would make it's way into Seamonkey. It will be a lot more work to
redo this by moving it into a new XBL-based XUL widget. (That's why I asked what
you thought of this approach on IRC last week). :/

How does setting initial index relate to the problem of what widget is used?

Comment 9

[Aaron Leventhal]

We need this for Firefox help to be accessible.

Comment 10

[Aaron Leventhal]

(In reply to comment #7)
> >+tab + tabpanel /* Sidebar tabpanel */
> >+{
> >+  visibility: collapse;
> >+  -moz-box-orient: vertical;
> ???

Which part is the question for?
tab + tabpanel is the shortest way to specify a tabpanel in vertical set of
tabs, since they are set up like this:
<tabbox orient="horizontal"> 
  <tabs>
     <tab/>
     <tabpanel/>
     <tab/>
     <tabpanel/>
     <tab/>
     <tabpanel/>
  </tabs>
  <browser/> <!-- or some other client area -->
</tabbox>
The visibility: collapse is there because most of the tabs are hidden. Another
style rule unhides the currently selected tab.
The -moz-box-orient is probably optional, but it seems like most vertical tab
panels use vertically organized children.

Comment 11

[[e-mail]]

(In reply to comment #8)
>How does setting initial index relate to the problem of what widget is used?
Switching to a tabs widget made the first tab was selected by default, although
I thought I saw Ben check in some code that you could use to change that.

Comment 12

[Aaron Leventhal]

(In reply to comment #11)
> Switching to a tabs widget made the first tab was selected by default, although
> I thought I saw Ben check in some code that you could use to change that.
I want to make Contents the first tab anyway. It's confusing to a screen reader
user to arrive in a group of tabs at the end, instead of the start. Besides,
putting Contents first puts them in alphabetical order (Contents, Glossary,
Index, Search). Why does it need to be last?

Comment 13

[Jeff Walden (gone starting June 8)]

Comment on attachment 180664 [details] [diff] [review]
Legitimize sidebar tabs as real tab widgets, created by a <tabbox orient="horizontal"> with a child <tabs> which itself has <tab><tabpanel> pairs as children

I'm nowhere near qualified enough to review this yet; my guess is you probably
want mconnor instead.

That said, if indeed you ask him, I don't know what response you'll get.  He's
not a fan of multiple-panel sidebars, and he's been wanting to make some
changes to Help's UI to get rid of them for a while.  That might take
precedence over this, although I can't say that for certain.  (If he does
accept them, I would bet he'd ask for the xul.css changes to be moved into
Help's CSS stylesheets so as to localize the cruftiness, but that's just a
guess.)

Comment 14

[Aaron Leventhal]

Help has been redesigned and there is no longer a need for this fix.

The new help should be checked in very soon.

Comment 15

[Firefox Bug Husbandry Bot]

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