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 <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.
Lake is gone.
Paul, I think bryner should get this; he has already taken similar bugs from saari.
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. Gracefully declining.
*** 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 browser. 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.