Last modified: 2011-03-13 18:05:40 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 13919 - Add tabindex=1 to Search field of Main Page
Add tabindex=1 to Search field of Main Page
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
unspecified
All All
: Lowest minor (vote)
: ---
Assigned To: Nobody - You can work on this!
: accessibility, easy
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-01 18:34 UTC by David R Tribble
Modified: 2011-03-13 18:05 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description David R Tribble 2008-05-01 18:34:33 UTC
Add a "tabindex=1" attribute to the "Search" field of the
Main Page.  This will make it easier for users to search
from the Main Page, since all it takes then is a single
keystroke (Tab) to position the cursor in the "Search" field.

Currently the default behavior in most (all?) browsers when
viewing the Main Page is to give focus to the first link in the
page.  The "Search" field is many, many Tab keystrokes away,
forcing the user to use the mouse instead of the keyboard.

True, the "Search" field has an "accesskey=F" setting, but
not many users know how to activate it.  (I didn't find
out until recently and by accident that FireFox uses Alt-Shift-F
for this.)  And generally speaking, hotkeys are not nearly
as convenient to use as the Tab key.

Using "tabindex" also has the benefit of not affecting any
existing behavior, since there are no "tabindex" attributes
used anywhere else on the Main Page, and its use does not
force the focus to be set (until the user hits the Tab key).

This also makes the Main Page easier to use for access-impaired
users.

See also:
  Bug #1864 Cursor should be placed in the search box (2005-04-10)
Comment 1 Brion Vibber 2008-05-01 21:57:27 UTC
tabindex=1 would interfere with all other forms, by interjecting the sidebar search field into the middle of them.

A larger number, which would always appear after foreground forms, might be more appropriate. However, this would require *all* other forms to have tabindexes added to their fields or, again, I believe it'll pop up before them in tab order.
Comment 2 David R Tribble 2008-05-01 23:07:05 UTC
(In reply to comment #1)
> tabindex=1 would interfere with all other forms, by interjecting the sidebar
> search field into the middle of them.
> 
> A larger number, which would always appear after foreground forms, might be
> more appropriate. However, this would require *all* other forms to have
> tabindexes added to their fields or, again, I believe it'll pop up before them
> in tab order.

Excuse my ignorance, but I don't follow you.  What other forms
are there on the Main Page?

Any <input> fields that do not have a tabindex attribute are
assumed to have indexes greater than those that do, so that
tabbing through them gives focus first to those with tabindexes
(in relative numeric order), followed by those that don't
(in the order that they appear in the HTML doc).

So this means that if the Search field is the only <input>
field with a tabindex, it will get focus first (when the
user presses Tab), and subsequent Tabbing will then give
focus to the other <input> fields in the order that they
appear in the doc, i.e., in the order that they currently
get focus today.
Comment 3 Brion Vibber 2008-05-01 23:12:18 UTC
1) There might be any number of forms on a main page, depending on the extensions in use on that site. However it would be nonsense to set such a tabindex on a site's main page only, since the main page has the same ui as everything else on the wiki.

2) Right, that's my point above. Setting any tab index on that field alone would interfere with other forms which do not have explicit tabindexes, by coming before them in tab order despite not being a prominent UI element.
Comment 4 David R Tribble 2008-05-01 23:22:44 UTC
(In reply to comment #3)
> 1) There might be any number of forms on a main page, depending on the
> extensions in use on that site. However it would be nonsense to set such a
> tabindex on a site's main page only, since the main page has the same ui as
> everything else on the wiki.
> 
> 2) Right, that's my point above. Setting any tab index on that field alone
> would interfere with other forms which do not have explicit tabindexes, by
> coming before them in tab order despite not being a prominent UI element.

Okay, I see now.

Like you say, adding a large tabindex=100 (for example) would
do the trick, but only if all other forms also have (lower)
tabindex settings.  Which is probably too much to ask for,
and might have unintended interaction consequences when multiple
forms are presented on a page.

So does that mean that there is no simple way to allow
the user to Tab to the Search field without complicating
all of the other elements/pages?

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links