Bug 13942 - Allow @autofocus on any element with @tabindex
Summary: Allow @autofocus on any element with @tabindex
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: contributor
QA Contact: HTML WG Bugzilla archive list
URL: http://dev.w3.org/html5/spec/associat...
Keywords: a11y
: 24124 (view as bug list)
Depends on:
Reported: 2011-08-29 04:41 UTC by Leif Halvard Silli
Modified: 2013-12-17 11:21 UTC (History)
11 users (show)

See Also:

Demo page (the demo immitates a frameset page) (2.96 KB, text/html)
2011-08-29 04:41 UTC, Leif Halvard Silli

Note You need to log in before you can comment on or make changes to this bug.
Description Leif Halvard Silli 2011-08-29 04:41:37 UTC
Created attachment 1026 [details]
Demo page (the demo immitates a frameset page)


* @autofocus is currently permitted only on 5 elements: button; input; keygen; select; textarea
* HOWEVER, javascript is used to set focus also on other elements. One usecase can be elements that imitated a frame: If the main content of the page is kept inside that element, then authors would like to give focus to that element, so that the user can start to scroll the page by pressing the SPACE key.
* Of course, it must continue to only be permitted to have a single @autofocus per page.

EXAMPLE PAGE: (also available as attachment): http://tinyurl.com/4xy4nr8


  Currently, one must use javascript to do this. This means that autofocus can't be set whenever javascript is disabled or when the author is unfamiliar with javascript.


   If a page contains e.g. a <button autofocus> element, the author might still use javascript to give focus to another element than the one with @autofocus set - making @autofocus virtually useless. But, if autofocus could be used to give focus to any element with @tabindex, then the author is more likely  to keep @autofocus and javascript in sync (e.g. if he/she uses javascript to target legacy browsers).
Comment 1 Leif Halvard Silli 2011-08-29 05:14:27 UTC

It is currently rather common to "imitate frames" by using position:fixed banners and menus on the top of the page.  However, authors often do not realize that this simplistic approach typically will cause the banner to hide content when the user is SPACE key scrolling. 

   Example: http://www.gp.se/ 
               (Swedish news paper with a banner that hides content - 3 to 4 lines -  when SPACE key scrolling.)

Some are are aware of the issue, and creates a banner that is so low that it doesn't create problems.

   Example: http://www.bt.no/
                 (Norwegian newspage where a fixed menu of low hight  
                 "pops up" when user is scrolling.I)

On the other side, there exists more "true" frame imitations, which however suffer from the problem of getting focus on the content element.

   Example: http://www.cssplay.co.uk/layouts/fixit.html
                  (A complete frame emulation which suffer from lack of  interactivity, 
                   since it doesn't give focus to the main content element.)

And lastly, frame pages and iframe pages are still in use - and often critisized. However, fact is that frame pages and iframe pages are simpler to give focus to (via Javascript) than it is to give focus to emulated frames: Firefox has a bug when it comes to setting focus on "imitation frames": https://bugzilla.mozilla.org/show_bug.cgi?id=682763 And Opera has a similar bug. These bugs are not present for "real" frame and iframe elements, where it is easy and safe to set the focus.

     Example  of frame based page: http://di.se
                    ( This page does not seem to manage focus - so it is not an example in that regard.
                       So this page ony shows that setting focus via javascript can be a challenge to
                      authors ... Please see the mozilla bug above for test frame and ifram tests. ) 


@autofocus on any element with @tabindex will *not* be able to *automatically* solve all the above problems. However, I believe it would: make socalled "CSS frames" (that is: imitated frames) a more serious alternative. We have been bashing frames for a long time, but when one actually try to do CSS frames, then one stumbles on some much of the same problems. Permitting @autfocus on any element with @tabindex, could raise awareness about the correct way as well as raise the awareness of what it actually takes to imitate frames.
Comment 2 Leif Halvard Silli 2011-08-29 12:03:53 UTC

]] The autofocus content attribute allows the author to indicate that a control
<INS>or specially focusable element</INS> is to be focused as soon as the page
is loaded, allowing the user to just start <INS>interacting with the element
via the keyboard (for example </ins> typing<ins> or SPACE key scrolling a
scrollabel element)</ins> without having to manually focus the main control
<INS> or specially focusable element</INS>. [[
Comment 3 Ian 'Hixie' Hickson 2011-12-09 23:33:00 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:

Status: Rejected
Change Description: no spec change
Rationale: Let's see how people do with autofocus on <input> before we start making it even easier to move focus around.
Comment 4 Leif Halvard Silli 2013-12-17 11:21:20 UTC
*** Bug 24124 has been marked as a duplicate of this bug. ***