This RFE is abstracted from bug 21502. The reporter suggests having tabbing
navigation begin at the topmost element that may receive focus that is visible,
rather than the topmost such element on the page.
A user who has limited use of his or her hands and has difficulty using or
cannot use a mouse may find it very useful to not have to TAB through all the
links and form element on a page to get back to a point that he or she has
already scrolled to.
I have no idea if this is already planned, how difficult it would be to
implement, or who would implement it, but this idea does have some merit,
especially for non-form tab-navigable elements.
If the user wants to tab to an element that is not visible because it is above
the viewport, it would be faster and easy enough to [PgUp] to where it is
visible and tab down again to the element than to tab through several pages
worth of links - at least for pages with many screenfuls of content and many
links per screenful.
This proposal would not be as suitable for webpages with very long content but
few links, if the link wanted is above, at least for those with serious
impairments to the use of their hands. CTRL-HOME and or SHIFT-TAB would make it
relatively easy to move to the top or up in the tabbing sequence, but those who
would most benefit from this on pages with many links would have the most
problems typing key combinations (although this is what StickyKeys are for).
I believe it is part of the bug #24413 ( a tracking bug about acceesibility).
also reassign it to lake so she can take a look and see who is actually
responsible for implementing keyboard navigation.
Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.
QA Assigning non-confidential New/Assigned User Interface: Design Feedback bugs
to Matthew Thomas (email@example.com).
Matthew Thomas is now the QA owner for the User Interface: Design Feedback
component. (Bugs that involve UI issues in the Netscape-branded Mozilla browser
should continue be QA assigned to firstname.lastname@example.org.)
*** Bug 54500 has been marked as a duplicate of this bug. ***
See also bug 66597, "tab while insertion point is in text focuses from
beginning of document".
This would contravene the Macintosh HIGs, which say that the position of the
scrollbar shouldn't affect the position of the caret
214.html#HEADING214-15>, since the position of the caret is what is determining
which element will get tabbed to next. Occasionally it's worth contravening
platform guidelines, but usually it isn't.
Lake is gone.
Paul, I think bryner should get this; he has already taken similar bugs from
Chaning the qa contact on these bugs to me. MPT will be moving to the
owner of this component shortly. I would like to thank him for all his hard
work as he moves roles in mozilla.org...Yada, Yada, Yada...
updating to new owner. sorry for the spam.
Hmmm ... I think this isn't especially helpful, and would most certainly mess up
users with no vision at all.
*** Bug 98896 has been marked as a duplicate of this bug. ***
Why is this considered a Bad Thing? It's confusing for those of us who are used
to Opera's "q" and "a" link selection shortcuts. It's also exceedingly annoying
to have the page view jump up several screens worth on a large page if
the tab key is accidentally hit.
At least make it a pref, or something...
One thing you'll notice pretty quickly if you test this bug in Opera is that on
pages with complex layouts, it's hard to predict where q or a will take you, and
what you have to do to focus the link you want to follow. q and a take you to
different places depending on whether a page has left or right sidebars for
navigation, and if a page has both sidebars, you can't get where you want using
this feature. I don't know if that's more or less confusing than tabbing from
the last focused element when it's scrolled off.
Point: on pages with sidebars, q and a aren't all that user-predictable (I
believe it starts based on the link's location in the underlying HTML, so if
the sidebar appears in the HTML before the content (bad design! bad!), it can
mess things up)
Counterpoint: If it starts at the wrong link with "q', you can always cancel
the highlight and start with "a" instead, and vice versa. And that still has
no impact on its usability elsewhere.
Again, it could at least be made a pref... (I'd try contributing code, if I
wasn't hopeless with C, let alone C++ :( )
*** Bug 183647 has been marked as a duplicate of this bug. ***
In my opinion, this feature (as an option might be best) would complement the
type head find feature, and make Phoenix' keyboard navigation superior to that
of Opera. I expect that it would make more users than me make the switch. This
shortcoming is mostly what's keeping me from switching to an otherwise superior
Making this an option wouldn't hurt anyone, would it?
*** Bug 188104 has been marked as a duplicate of this bug. ***
*** Bug 358364 has been marked as a duplicate of this bug. ***
I personally see no reasons why this cannot be implemented. There're surely technical limitations but overall (as many have noted) straightforward navigation is more looking like a bug than feature. Before a solution is found (Opera behaviour or somewhat different) keyboard-only navigation in FF would become a real pain.