Start tabbing navigation from first visible element, not top



19 years ago
12 years ago


(Reporter: sidr, Assigned: mpt)




Firefox Tracking Flags

(Not tracked)


(Whiteboard: [p-opera])



19 years ago
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).

Comment 1

19 years ago
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. 
Assignee: shuang → lake

Comment 2

19 years ago
Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.
Component: UE/UI → User Interface: Design Feedback

Comment 3

19 years ago
QA Assigning non-confidential New/Assigned User Interface: Design Feedback bugs 
to Matthew Thomas (

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
QA Contact: elig → mpt

Comment 4

19 years ago
*** Bug 54500 has been marked as a duplicate of this bug. ***

Comment 5

18 years ago
See also bug 66597, "tab while insertion point is in text focuses from 
beginning of document".
Keywords: access

Comment 6

18 years ago
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.

Comment 7

18 years ago
Lake is gone.
Assignee: lake → hangas

Comment 8

18 years ago
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, Yada, Yada...
QA Contact: mpt → zach
updating to new owner. sorry for the spam.
Assignee: hangas → mpt

Comment 11

18 years ago
Hmmm ... I think this isn't especially helpful, and would most certainly mess up
users with no vision at all.

Gracefully declining.
Last Resolved: 18 years ago
Resolution: --- → WONTFIX

Comment 12

18 years ago
*** Bug 98896 has been marked as a duplicate of this bug. ***

Comment 13

17 years ago
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...

Comment 14

17 years ago
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.
Whiteboard: [p-opera]

Comment 15

17 years ago
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++ :( )


16 years ago
Component: User Interface Design → Browser-General

Comment 16

16 years ago
*** Bug 183647 has been marked as a duplicate of this bug. ***

Comment 17

16 years ago
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. ***
Product: Browser → Seamonkey

Comment 19

12 years ago
*** Bug 358364 has been marked as a duplicate of this bug. ***

Comment 20

12 years ago
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.
You need to log in before you can comment on or make changes to this bug.