I have a rough idea that it hops from <input> to <input> but is there any documentation for it? My purpose was to look for a way to set focus only in css.
If by "focus" you mean the focused element when tabbing through elements in a rendered page, then the tabindex=nn attribute defines the tabbing order.
According to the W3C Documentation
The following elements support the tabindex attribute: A, AREA, BUTTON, INPUT, OBJECT, SELECT, and TEXTAREA
See also Creating Logical Tab Order with the Tabindex Attribute
Related
This is more a historical or why question.
Unlike buttons, links tend to have a tabIndex of -1 as default value. I know this is because:
https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/tabindex
If not specified default value is -1
But buttons have a tabIndex automatically, so the question is: What was the rationale behind deciding that links shouldn't need to have a tabIndex bigger than 0? and because of that the Tab key should ignore the links in a default state.
HTML 5.1¹ defines what user agents should do when the tabindex attribute is omitted:
The user agent should follow platform conventions to determine if the element’s tabindex focus flag is set […]
The spec suggests a few elements that should get this flag, including a elements (as long as they have an href attribute) and button elements.
So user agents that follow the spec’s recommendation² don’t make a distinction between a and button elements with regards to the default focus behaviour.
I’m not sure why the linked MDN page contains the quoted statement (it seems to be wrong). Maybe it’s a misunderstanding of what the spec says about the tabIndex IDL attribute?
The tabIndex IDL attribute must reflect the value of the tabindex content attribute. Its default value is 0 for elements that are focusable and -1 for elements that are not focusable.
¹ HTML 5.1 is, as of now, the latest W3C Recommendation. But previous HTML W3C Recommendations and WHATWG’s HTML Living Standard probably don’t define this aspect differently w.r.t. to a and button.
² It’s not a requirement, as the spec uses should instead of must.
The MDN page you quote is the definition of the tabindex global attribute . This does not apply specifically to button or links.
In fact, tabindex can have four type of values:
when unset : the element can't be focused programmatically, with the keyboard or with the mouse
-1 : the element can be focused programmatically or with the mouse
0 : the element can be focused programmatically, with the keyboard or with the mouse
any value >0 : do not use this. Never. Not accessible.
The default values for link (a[href] and button) or other interactive elements (like form fields) is 0
The assertion that the default value for any other element is -1 is false. The default "value" for those other elements is to not define this attribute
I'm trying to find a list of elements that are tabbable.
Adding tab-index to elements make them tabbable.
Some elements are tabbable by default like <input>.
Is there a list of these elements that are tabbable by default?
And optionally, why are they tabbable by deault?
The easiest way to find answers to such questions is by looking at the spec
I believe the list you are looking for is:
a elements that have an href attribute
link elements that have an href attribute
button elements
input elements whose type attribute are not in the Hidden state
select elements
textarea elements
Editing hosts
Browsing context containers
To answer your optional question: they are "tabbable" by default for usability issues. If you follow the principals of making a good, user friendly app, it should allow for a consistent navigation and discoverability among other things.
So, by making them "tabbable", in the order they appear in code, the default behavior is to allow the user to complete a form from top to bottom, with minimal clicks and moving around, this making the "thinking process" about what should be filled next unnecessary
https://allyjs.io/data-tables/focusable.html is probably the most comprehensive list I've ever found. Not only does it go over what is "expected" by the spec but also how all major browsers actually behave.
At https://www.w3schools.com/tags/att_global_tabindex.asp, it talks about the tabindex attribute in HTML 4.01, and how only certain elements could enter the tab order through the tabindex attribute.
Those elements were: <a>, <area>, <button>, <input>, <object>, <select>, and <textarea>.
I've been working with tab stuff for a few months now, and that list seems to fit with I've noticed as naturally tabbable.
I have noticed on webkit browsers that anchor elements do not receive focus when clicked. Inputs and divs (with tabindex set) do. Of course, tabbing will set focus to an anchor, as will javascript .focus().
My questions: Why does this happen? and does anyone know any tricks to make an anchor receive focus upon click?
I think you should add tabindex to anchor tag.
Following link will help: tabindex usage
I have a quick question about the usage of the for attribute in <label> tags. I know they should refer to the id of the input element they label, but I often see it being used to refer to the name attribute of some <input> tag in HTML forms. Is this valid usage?
Additionally, how should I label a set of, say, <input type="radio"> tags? They each require an individual label, of course, but how do I correctly label the group they form?
Thanks in advance!
The label element is defined in HTML 4.01 so that the for attribute “matches field ID value”. This is even a purely syntactic requirement: the attribute is declared with type IDREF, and this implies that an HTML validator issues an error message if the value does not match an id attribute value in the same document. In HTML5, the formalism is different, but the principle is the same.
Thus, it must match an id attribute value, and this is enforced by browsers: the element won’t act as a label for anything, functionally, is this requirement is violated. The page would still work, but with reduced usability and accessibility. The same value may appear as a name attribute value, too, since such attributes have a name space of their own, so to say.
There is no way to “label” a set of radio buttons, or other controls, in the sense that label defines labels (i.e., clicking on a label element typically focuses on the associated control). And no need either.
You can, and normally should, have a heading-like caption for a set of radio buttons, explaining what they are about. But that’s not a job for label. You can use a suitable heading element (e.g., h2), for example. A construct specifically designed for the purpose is the legend element in a fieldset element. It can contain a brief description of the radio buttons wrapped inside a fieldset.
The for attribute says which element the label is meant for or belongs to.
http://www.w3schools.com/tags/att_label_for.asp
Is it possible to control tabindex with CSS and if yes, which browsers support it and on which elements?
EDIT
I should say, my goal is to catch keydown events on a div. I saw this page http://www.quirksmode.org/js/events/keys.html# that tests keyboard events and it shows that the only way keydown fires on anything other than document and body or some kind of form element or link is to have tabindex declared on it. But I read on W3C site:
The following elements support the
tabindex attribute: A, AREA, BUTTON,
INPUT, OBJECT, SELECT, and TEXTAREA.
So I am a little confused, what to do in order to be standarts compliant and make my use case work?
EDIT2
My whole use case is a div with a lot of content with an artificial scroll bar. I am able to scroll it with mouse events but no luck with the keyboard so far.
Update 2017
As pointed out by #Wallop in the comments, the nav-index property was dropped from the spec in 2015 due to "lack of implementation interest".
Take a look at the nav-index property introduced by W3C in CSS3-UI.
This property has exactly the same behavior as a tabindex and is applicable to any element.
The ‘nav-index’ property is an input-method-neutral way of specifying the sequential navigation order (also known as "tabbing order").
This property is a replacement for the HTML4/XHTML1 attribute ‘tabindex’
Being probably the best standards-compliant solution for the use case, nav-index is interpreted only by Opera so far (as of June 2012) and is also marked as "Feature at risk" by W3C, therefore may be dropped any time.
Alternative cross-browser solutions are:
non-standards-compliant: set the tabindex attribute on a DIV. This will work in all common browsers.
standards-compliant: replace DIV by an anchor element (A) without a href attribute set, style it with display: block and add the tabindex attribute.
With respect to BoltClock´s point, I agree that the tabbing order is very logical (both the text selection order and tabbing order are closely related to the sequence in which elements are aranged in the document). On the other hand, CSS has a wider purpose today. It can manipulate not just the content of a document (content property) but also the behavior when and if events are to be fired: i.e. using pointer-events, display or z-index the pointer event's order will change. If these are very basic CSS properties, why you should not be able to influence KeyBoardEvents, too?
This is a bit old but now there are css options like -moz-user-focus. I'm sure there is a webkit equivalent.
https://developer.mozilla.org/en-US/docs/CSS/-moz-user-focus
user-focus is the standard cross browser attribute.