Closed
Bug 98896
Opened 23 years ago
Closed 23 years ago
tabbing shouldn't change user-changed scrolling position
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Tracking
()
People
(Reporter: cesarb, Assigned: aaronlev)
References
()
Details
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3+) Gecko/20010906 BuildID: 2001090608 When the user manually changes his scrolling position on the page (be it via PgUp/PgDn or scrollbars), pressing the tab key should select the first visible link in the page, not the first link on the page. Same for Shift-Tab (which should select the last visible link). After that, tabbing should be allowed to scroll the page (via the normal order), until the user manually changes his position (ArrowUp, for instance). Reproducible: Always Steps to Reproduce: 1. Go to a page longer than the brower window (if you use more than 800x600, www.mozilla.org probably won't do; try slashdot then) 2. Select the content area (by clicking on the background) 3. Use PgDn to scroll down 4. Use Tab a few times Actual Results: The first link in the page was selected Expected Results: If the last action in the current window was not tabbing inside the content area, And the current tabbing focus is outside the visible portion of the content area, Then: Select the first/last link in the tabbing order which is inside the visible portion of the content area (depending on shift state). Else: Select the next link to tab to using the normal algorithm. Jumping to the beginning to the document loses the visual tracking of where we are in the document. This means that using Tab to select a link is next to useless unless you are using it from the beginning, and thus force keyboard people (Space/Space/PgDn/PgUp/Arrow/Arrow/etc) to lift hands and go to the mouse to select a link. On the other hand, if you are already using Tab, there is no problem in it moving the screen, since that's probably what you want. I believe the pseudo-algorithm I gave above follows the principle of least surprise, and that if it were implemented, I would be using the mouse a lot less :P The same algorithm can be used without problem for tabbing in forms (like this one).
Comment 1•23 years ago
|
||
This is a dupe of 23914, which was marked WONTFIX. Bug #66597 seams somewhat related too and that one is still alive. I'm marking this bug a dupe of 23914. *** This bug has been marked as a duplicate of 23914 ***
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 2•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. How would it happen? Users with no vision at all would use only TAB, right? Besides, a) It can be a pref b) As things are now, using Tab mess up users with vision to the point it's useless and I have to use the mouse, all the time. Also, did we ask any blind user about it, or are we just guessing?
This isn't the case, however arguing in a bug that is resolved as a duplicate is absolutely useless, i'd suggest using the newsgroup npm.accessibility iirc. vrfy dupe. fwiw some third parties might implement this and are certainly free to implement this for their own use.
Status: RESOLVED → VERIFIED
Updated•5 years ago
|
Component: Keyboard: Navigation → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•