Closed
Bug 23914
Opened 25 years ago
Closed 23 years ago
Start tabbing navigation from first visible element, not top
Categories
(SeaMonkey :: General, enhancement, P3)
SeaMonkey
General
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: sidr, Assigned: mpt)
References
Details
(Keywords: access, Whiteboard: [p-opera])
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•25 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
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•24 years ago
|
||
QA Assigning non-confidential New/Assigned User Interface: Design Feedback bugs to Matthew Thomas (mpt@mailandnews.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 elig@netscape.com.)
QA Contact: elig → mpt
Comment 5•24 years ago
|
||
See also bug 66597, "tab while insertion point is in text focuses from beginning of document".
Assignee | ||
Comment 6•23 years ago
|
||
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 8•23 years ago
|
||
Paul, I think bryner should get this; he has already taken similar bugs from saari.
Comment 9•23 years ago
|
||
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...
QA Contact: mpt → zach
Comment 11•23 years ago
|
||
Hmmm ... I think this isn't especially helpful, and would most certainly mess up users with no vision at all. Gracefully declining.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
Comment 12•23 years ago
|
||
*** Bug 98896 has been marked as a duplicate of this bug. ***
Comment 13•22 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•22 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•22 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++ :( )
Comment 16•22 years ago
|
||
*** Bug 183647 has been marked as a duplicate of this bug. ***
Comment 17•22 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 browser. Making this an option wouldn't hurt anyone, would it?
Comment 18•22 years ago
|
||
*** Bug 188104 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Product: Browser → Seamonkey
Comment 19•18 years ago
|
||
*** Bug 358364 has been marked as a duplicate of this bug. ***
Comment 20•18 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.
Description
•