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.

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.

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

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 on attachment 158718 [details] [diff] [review] proposed patch The patch has been obsolete.

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

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

We need this for Firefox help to be accessible.

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

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

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

Help has been redesigned and there is no longer a need for this fix. The new help should be checked in very soon.