23914 - Start tabbing navigation from first visible element, not top

Status: RESOLVED WONTFIX

(SeaMonkey :: General, enhancement, P3)

Description

[Sean Richardson]

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

[shuang (gone)]

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. 

Comment 2

[leger]

Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.

Comment 3

[Eli Goldberg]

QA Assigning non-confidential New/Assigned User Interface: Design Feedback bugs 
to Matthew Thomas ([e-mail]).

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 [e-mail].)

Comment 4

[Matthew T (active 1999-2002)]

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

Comment 5

[Jesse Ruderman]

See also bug 66597, "tab while insertion point is in text focuses from 
beginning of document".

Comment 6

[Matthew T (active 1999-2002)]

This would contravene the Macintosh HIGs, which say that the position of the 
scrollbar shouldn't affect the position of the caret
<http://developer.apple.com/techpubs/mac/HIGuidelines/HIGuidelines-
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

[Blake Ross]

Lake is gone.

Comment 8

[Peter Trudelle]

Paul, I think bryner should get this; he has already taken similar bugs from
saari.

Comment 9

[Zach Lipton [:zach]]

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

Comment 10

[Asa Dotzler [:asa]]

updating to new owner. sorry for the spam.

Comment 11

[Aaron Leventhal]

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

Gracefully declining.

Comment 12

[André Dahlqvist]

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

Comment 13

[Joanne Hunter]

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

[Jesse Ruderman]

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.

Comment 15

[Joanne Hunter]

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

Comment 16

[Jesse Ruderman]

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

Comment 17

[Tydr Schnubbis]

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

Making this an option wouldn't hurt anyone, would it?

Comment 18

[Boris Zbarsky [:bzbarsky]]

*** Bug 188104 has been marked as a duplicate of this bug. ***

Comment 19

[Jesse Ruderman]

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

Comment 20

[sacrat]

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.