As tabbing does not work and Ctrl+Tab is not implimented nore are shifted Shortcuts the Sidebar is totally dependent on the Mounse for most operations. You can't even open and close with out the mouse though you can remove it totally.

Yeah, this fits in with our 'people with disabilities shouldn't use our product' initiative. I'd expect this to be nsbeta3-, not because I feel it should be, but because many other accessibility bugs which are more significant were marked as such. cc'ing matthew so he can add this to his W3C accessibility bug dependency list, and steve since he'd probably be the one to implement this...

nav triage team: we need to look at accessability in its whole, not just small pieces. mpt, do you have a master list of accessability issues? If so, please start a new bug on "overall accessability" with that list and cc johng, michaell, jar and others so pdt can look at the issue.

Johng, I'm not a programmer, I can't fix the sidebar problem. Reassigning back to Don. As implied in <http://critique.net.nz/project/mozilla/general/interface/keys/>, I suggest Ctrl+Tab/Ctrl+Shift+Tab to cycle between main content-->location bar-->sidebar tabs-->sidebar content-->main content, and Tab/Shift+Tab within the sidebar tabs to cycle through tabs (just as within content areas it cycles through links). Bug 24413 is tracking violations of the W3C User Agent Accessibility Guidelines, which are fairly comprehensive (and for which Mozilla is hopelessly doomed for 5.0). I've added michaell@netscape.com to the CC list for that bug; the others you mentioned are already there. Accessibility bugs which wouldn't be dependent on that bug would be: * bugs making life difficult for those with motor disabilities (e.g. buttons which were unreasonably small and/or didn't have a menu equivalent), * problems with chrome making life difficult for those with attention problems (e.g. gratuitous animation in non-content areas), * wording or iconography which causes unnecessary grief for mentally retarded users (e.g. <http://www.asktog.com/readerMail/2000-01ReaderMail.html#anchor13>), * interface elements making life difficult for partially sighted or color-blind users (e.g. the toolbar icons in the Modern skin, or the unknown-state and new-mail icons in 4.x). If you feel a need to set up separate tracker bugs for any or all of those issues, go right ahead. But perhaps an `accessibility' keyword would be more appropriate?

I have bug 30864 which mentions Ctrl-Tab in general (but went way off track). So I'll take this one, also. I believe Varada is working on Ctrl-Tab somewhere in mailnews. We need a simple strategy, or we just won't be able to do anything. mpt's description here seems plausible. What about the ambiguity with links inside sidebar tabs? Sorry I can't do more with this. Just pushing it along to try to get things closer to resolution. This is marked UE1 so it will come up later this week when we meet to deal with those bugs.

Just attached the HTML page for the Keyboard Navigation Spec. The Gifs are missing and the internal links won't work for non Netscape but the importiant things for this bug ar there and do not need the graphics.

Marking [nsbeta3+] just so I can justify looking at this more closely. I'm not sure this is shaping up as a manageable item for PR3, though.

We could maybe do this without doing the full-blown keyboard navigation spec thing attached to

...this bug (I meant to conclude).

PDT thinks this is a P5.

At the verry least the open sidebar panel should be included in the Tab cycle. The items in the open panel should work like a web page.

nav triage team: nsbeta3-, sorry :-(

Some programs use F6 for moving between panes.

huftis, that's already discussed in some of the other bugs mentioned here. I think this bug is going to get offtrack, maybe we should use a newsgroup for this mess?

see also bug 22184, which wants a way to toggle the sidebar with the keyboard. should this bug "depend" on 22184?

No. Neither bug requires the other to be fixed.

Ok, here's what i hope would be an EASY way to get to the sidebar: Go>&My Sidebar You might ask why not &S or &b. Reasons: 'Mail &Start Page' and '&Back' Yes this would only work on two windows, Navigator and Mail News [No other windows have the go menu], but some access is better than no access. [imo]These are the two places where people are most likely to use My Sidebar, yes you could use it in composer, but if you are using editor then I think you would be willing to load a navigator window to navigate the sidebar, and if you're in addressbook you very likely have a mail window or would be willing to open one. Law: assuming you ran out of rtm bugs and no one else fixed this, could you do it? I hope this takes only five minutes to do. I'm going to finish my bug mails, talk to a few people and hopefully this will get done today. Thanks mpt.

nsbeta1

this got the big minus in the sky

looking at today's bits [2001.01.10.08, mozilla], at least on linux, there is a shortcut [F9] to open and close the sidebar --at least in the composer and browser windows. would this bug cover that? or, is it asking for something more broad, like having access to the sidebar via the tabbing cycle...? if it's merely to have a simple, accelerated shortcut [provided by F9], then this should be marked fixed. [i don't currently have win32 or mac bits in front of me to verify, however.] but, again, let me know if this isn't the case here. thx!

my brain is asleep. bug 22184 answered my question. sorry about the noise!

I'd prefer not to have a distinction between a sidebar tab being focused and the panel's content being focused. That would be confusing, and would make it difficult to be able to click on a sidebar tab and immediately type into a textbox in that panel or scroll that panel with the keyboard (bug 50223). How about Ctrl+Tab for moving focus to and from the sidebar (bug 30864) and Alt+Up, Alt+Down for switching between tabs?

This whole area needs to be discussed in a keyboard UI meeting. We have them about every other Friday around 3 pm. If you're interested in joining us please email me. Our current work is posted at www.mozilla.org/projects/ui/accessibility/mozkeyintro.html Whatever we do, please let's make sure the spec is sync with Bugzilla reports.

Marking nsbeta1- bugs as future to get off the radar

Not present in Mozilla Build 2001060703. My sidebar navigation requires mouse usage. Feature: Searching through History and Bookmarks from My Sidebar...

Just filed metabug http://bugzilla.mozilla.org/show_bug.cgi?id=89148

Samir, this is probably a dup of what we already just went over. But here it is for you to look at.

Removing adequated PDT grafitti.

[re]nominating, as this was a frequent complaint during our keyboard navigation bugarama.

Alt-PgUp and Alt-PgDn works (mostly: when tabs don't overflow) as implemented by Aaron. Thanks Aaron! Is this bug open for any other issues or can I mark it fixed by Aaron (or a dupe of his alt-pg{up,dn} implementation)?

This is really just a tracking bug, adding meta, nsbeta1-

Doesn't F6 go to the sidebar? I was looking for another Sidebar bug when I noticed this one...

F6 switches between panes. In a browser window, it switches between content area frames (but not iframes), the sidebar (if the sidebar is open), and the location bar.

nominating.

Nav triage team: Let's continue using this as a tracking bug. Please file individual bugs for the specific defects and nominate accordingly. Thanks.

I was about to submit a bug regarding keyboard access to the sidebar when I found this one; apologies if this is not the right place for this comment. There are currently 3 methods of cycling between tabs with the keyboard, at least on my Windows system: (1) [Shift+]Ctrl+Tab, (2) Ctrl+PgUp / Ctrl+PgDn, and (3) Ctrl+LeftArrow / Ctrl+RightArrow. On the other hand, to switch frames the only choices are F6 or Tabbing through every link in the page. F6 is suboptimal because in most cases it requires both moving a hand away from the home (asdf / jkl;) position on the keyboard and looking down from the screen to find the F6 key. Tabbing through the links to get to the sidebar is cumbersome because it can take several seconds to arrive at the sidebar if the caret is in the middle of a long page. I humbly suggest either (1) redesignating one of the above three sets of tab-switching keybindings to switch between frames (as Ctrl+Tab used to do) or (2) designating Ctrl+UpArrow and Ctrl+DownArrow, which seem to be unassigned, for this purpose. Either of these two suggestions would permit quick, blind single-handed keyboard access to the sidebar.

You can switch sidebar tabs with Alt+PgUp/PgDn See the keyboard docs pages listed at www.accessmozilla.org

Thank you for the pointer, but there do not seem to be any key bindings that address the functionality I was attempting to describe. I'll try again. What would be useful is an easier way to cycle focus between panes or frames, like F6 does but with keys that are accessible from the home keys without looking away from the screen. There are 3 such key combinations bound to switching tabs and none for switching frames. It seems reasonable to devote one of these sets to this functionality to make keyboard navigation easier for touch typists.

This is fixed via comment #37. Comment 38 seems to be talking about cycling between panes/frames. We do have a keystroke for that -- F6/Shift+F6. We're not going to use Ctrl+Tab, because that's used for navigating browser tabs. To summarize: F9: toggle sidebar Alt+PgUp/PgDn: switch sidebar tabs, put focus there F6/Shift+F6: cycle through panes/frames, incluing the sidebar.

This should not be resolved as FIXED because of comment 37. To mark this fixed you need to point to the bug/patch that was checked in that resolved the problem. In lieu of that this should be resolved as WORKSFORME.