decreased prio to P3, deferred to 3.3.1 release

Adjusted subcomponent. It is the similar problem like with main-window.

What's wrong with Alt-Left/Alt-Right? I think there are serious KB
usage problems in the Output Window, but this is not one of them IMHO.
However behavior ought to be consistent between types of windows. I
just today filed a KB bug for utilities re. tabbing in the Search
dialog (where Alt-Left etc. do not work, as they are not top
components, so focusing the tabs is really necessary).

The problem is that alt-arrow is not consistent with the Java Look and
Feel Guidelines and most of the other tabbed panes in NetBeans.
Consistency is crucial here, and we can get it by following the
existing guidelines whereever possible.

The JLF guidelines (and the search window, by the way) specify that
right/left arrow (without modifier) should navigate among tabs,
control-up/down arrow moves between the tab and the content pane, and
control-pgup/pgdn move among content panes without need to put focus
on the tab.

The only problem I see with the search window is that it moves focus
away from the tab after each arrow press. Otherwise, it is perfectly
accessible and follows the guidelines.

The fact that the output window has some other mechanism to move among
tabs means that it is basically not keyboardable, because a user has
no way of knowing that that window works differently from all the
others. This lack of consistency is what made me think it wasn't
keyboardable, and that same lack is what Jesse think that the search
window is not keyboardable.

We need to follow the guidelines whenever we can so that keyboard
access is reliable, and not different for each window.

It's not different for each window. I don't doubt that the shortcuts
are not the JLF-mandated ones, but the shortcuts for switching tabs in
the Output Window are the standard NB ones used for all dockable top
components, including editor tabs and tabs in the Explorer. If you
want to switch Alt-Left to Ctrl-PgUp globally, I guess you could, but
there is no problem with consistency here. The Search window is a
dialog and the tabs are not dockable windows and so are not controlled
in the same way (also no Window menu operations for them, etc.).

BTW the problem of a user not knowing what KB shortcuts actually work
is, I think, a general one and not going to be solved by adhering here
and there to JLF guidelines. (Many other things specified by the JLF
do not in fact work at all, or do not work on common platforms due to
shortcut conflicts, so reading the JLF guide is not going to be much
practical help to a user, even if he knew what the JLF guide was and
where to find it.) For global commands and editor commands
customizable in the IDE, these are easily listable from the Options
dialog; however there should be a general guide shipped with the IDE
giving KB tips for unlisted shortcuts (low-level focus operations
rather than IDE commands) and information on how to do certain things
which are not really obvious. For example, it is now at last possible
to move from the Explorer to the Property Sheet, select a property,
and change its value, and move back, all using tabs. But I was not
able to do it without asking the property sheet developer how it was
supposed to work. Simple dialogs with mnemonics and usual focus tab
order need little explanation, but many more compact GUI objects in
the IDE require a little training I think.

Well, switching tabs via Alt+arrows is not good for blind users.
Screen readers read only focused component by default. So it is
important to allow switching tabs while tabbed pane is and stays
focused. Alt+arrows is just shortcut, when user knows(sees) where it
is switching to.

Makes sense, ignore most of my previous comments then.

Duplicate of more general bug.

*** This issue has been marked as a duplicate of 17449 ***

Resolved for 3.4.x or earlier, no new info since then -> verified.

Resolved for 3.4.x or earlier, no new info since then -> closing.