The spec says the following about the <nav> element (emphasis mine):
The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links.
It never specifically says that <button> is disallowed, and nowhere it says that only <a> elements should be used for navigation (yet it mentions "links"), but all the examples seem to be a bunch of anchors in lists. The one example (11) that isn't a list still has only anchor elements for navigation inside.
The next example (12) shows an example of navigation within application, but uses anchors again.
So, are button elements allowed inside <nav>?
In HTML 5.2, section 4.8. is about links:
Links are a conceptual construct, created by a, area, and link elements, that represent a connection between two resources […]
As one would expect, the definitions of a ("a hyperlink"), area ("a hyperlink"), and link ("the link(s)" etc.), all refer to links, while the definitions of button and input don’t.
So:
A nav element should contain elements with href attribute (a/area/link). Otherwise it wouldn’t be warranted to use nav in the first place (exceptions aside).
A nav element may also contain buttons. For example, a button that is used to toggle between showing all levels of the navigation, and showing only the top-level. (However, if the buttons are used for navigation, they should be links instead of buttons anyway.)
The HTML5 Standards allows any kind of flow content inside of <nav>-tags and <button> tags are considered being flow content, but you should consider to avoid them for semantical reasons. Buttons based on <button> are UI elements which are exclusively javascript driven (or in some tricky scenarios by the default behavior of the browser when using forms) without any functionality or semantical reference towards an 3rd party reference. Therefor using <button>-tags inside of <nav>-tags makes no sense for clients/robots who do operate without considering javascript.
Modern UI-Frameworks like Bootstrap, Semantic-UI or others do provide the ability to implement buttons in multiple ways (as <button>-tags as well as <a>-tags). Taking such abilities into account, you should prefer to rely on <a>-tag based buttons for semanatic reasons.
Depends how you define "allowed".
It is valid HTML, but you may want to read up on accessibility and the difference between a button (that should signal clickable actions) and a link (that should navigate somewhere).
http://web-accessibility.carnegiemuseums.org/content/buttons/
I was wondering, can you make an element that is not an anchor (<a>) tag (for ex. <div>, <span>, etc.) behave like an anchor tag? (Link to page on click).
Or, are there any other elements that behave the same?
Only partially.
You can give any tag a tabindex to make it focusable.
You can give any tag a click event listener that sets location.href.
You can't make anything other than a real link react to :link and :visited in CSS
That leaves aside issues of getting (for example) screen readers to recognise the element as a link and annouce it to the user, and for search engines to recognize it as a link and follow it, and the JS simply failing.
In short: If you want a link, then use a real link. HTML is a semantic markup language. Use the semantics it comes with. Don't try to fake the behaviour that comes with the semantics using other elements.
So I was able to get my page working just fine with the NDVA screen reader, however, when testing in JAWS, it tabs to the span, but doesn't read the text.
<span tabindex="0" title="whatever">whatever</span>
UPDATE:
What I am trying to achieve is a I have a few elements which expand/collapse certain sections of the site I'm building. These functional elements, however are not links.
Reponse to #discojoe (thanks for the response)
Adding a TABINDEX="0" attribute will insert the SPAN/DIV element into tabbing list in natural order (whereas by default, they're usually not added to the tabbing list). This allows screen readers to tab to that element, and is working just fine. Specifically, my problems is JAWS will just tab to that element, it just doesn't read it.
I agree, using TABINDEX="n" (where n > 0) is a bad thing which messes with the natural order of the tabbing list, and I am not doing that.
Also, you can use TABINDEX="-1" to remove an element from the tabbing list if it's placed in there by default (example an A or INPUT tag).
I have already tried using tags, however, when user hits enter on this link (to trigger the onclick event), it does something (not quite reloading, but kinda re-initializing) to the page which delays the animation associated with that element. I find that to be a bad experience to both normal and disabled users.
using the # tag in the A tag adds the hash tag to the page title in IE.
Additionally, using A tags makes the screen reader read out "LINK" before/after each element, and since they're not actually links, I feel this is negative impact on accessibility.
I would first want to know why you are using a span element and not a standard a href element? What is it you are wanting to achieve? It may help if you can provide more context\code.
I've just tried this and am getting the same issue; whilst I can arrow through the document and have a span read out to me, I cannot then tab to it and have it read out.
Using something instead like
Whatever
works fine.
There are additional problems around using the tabindex attribute, specifally for keyboard users. On a page that users the tabindex attribute, the tab focus order will first of all go through all of the elements with tabindex specified, and then run through all the elements without it, in source code order.
A good general rule is to either use tabindex for all keyboard accessible elements, or for none of them, to get around this problem.
I realise in this case, you are likely using tabindex to just provide keyboard accessibility for this one item, so this issue may be irrelavant if you use the a href approach mentioned, but I wanted to mention it for completeness
First of all, reading "link" before such elements does not impact accessibility in a negative way, I'd say, it's quite opposite: you warn the user that he/she can click the element in such a manner.
Here you have a couple options:
Use quite a lot of ARIA: add the link role to your span elements, properly code your expanding/collapsing menus (with corresponding ARIA roles and states).
Use <a href="#" as suggested by #discojoe but add event.preventDefault() (in jQuery) or return false; (in vanilla) so the page would not reinitialize.
If you need more suggestions, please post some code or a link to your page.
Use anchor tag for screen reading simple text related works. You can simply do :-
<a href="javascript:void(0);" title="What you want to be read by jaws></a>
That's it. I tested it with JAWS.
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.
When looking at most sites (including SO), most of them use:
<input type="button" />
instead of:
<button></button>
What are the main differences between the two, if any?
Are there valid reasons to use one instead of the other?
Are there valid reasons to use combine them?
Does using <button> come with compatibility issues, seeing it is not very widely used?
Here's a page describing the differences (basically you can put html into a <button></button>)
And another page describing why people avoid <button></button> (Hint: IE6)
Another IE problem when using <button />:
And while we're talking about IE, it's
got a couple of bugs related to the
width of buttons. It'll mysteriously
add extra padding when you're trying
to add styles, meaning you have to add
a tiny hack to get things under
control.
Just as a side note, <button> will implicitly submit, which can cause problems if you want to use a button in a form without it submitting. Thus, another reason to use <input type="button"> (or <button type="button">)
Edit - more details
Without a type, button implicitly receives type of submit. It does not matter how many submit buttons or inputs there are in the form, any one of them which is explicitly or implicitly typed as submit, when clicked, will submit the form.
There are 3 supported types for a button
submit || "submits the form when clicked (default)"
reset || "resets the fields in the form when clicked"
button || "clickable, but without any event handler until one is assigned"
This article seems to offer a pretty good overview of the difference.
From the page:
Buttons created with the BUTTON element function just like buttons
created with the INPUT element, but
they offer richer rendering
possibilities: the BUTTON element may
have content. For example, a BUTTON
element that contains an image
functions like and may resemble an
INPUT element whose type is set to
“image”, but the BUTTON element type
allows content.
The Button Element - W3C
Inside a <button> element you can put content, like text or images.
<button type="button">Click Me!</button>
This is the difference between this element and buttons created with the <input> element.
Quote
Important: If you use the button element in an HTML form, different browsers will submit different values. Internet Explorer will submit the text between the <button> and </button> tags, while other browsers will submit the content of the value attribute. Use the input element to create buttons in an HTML form.
From : http://www.w3schools.com/tags/tag_button.asp
If I understand correctly, the answer is compatibility and input consistency from browser to browser
I will quote the article The Difference Between Anchors, Inputs and Buttons:
Anchors (the <a> element) represent hyperlinks, resources a person can navigate to or download in a browser. If you want to allow your user to move to a new page or download a file, then use an anchor.
An input (<input>) represents a data field: so some user data you mean to send to server. There are several input types related to buttons:
<input type="submit">
<input type="image">
<input type="file">
<input type="reset">
<input type="button">
Each of them has a meaning, for example "file" is used to upload a file, "reset" clears a form, and "submit" sends the data to the server. Check W3 reference on MDN or on W3Schools.
The button (<button>) element is quite versatile:
you can nest elements within a button, such as images, paragraphs, or
headers;
buttons can also contain ::before and ::after pseudo-elements;
buttons support the disabled attribute. This makes it easy to turn
them on and off.
Again, check W3 reference for <button> tag on MDN or on W3Schools.
Although this is a very old question and might not be relevant anymore, please keep in mind that most of the problems that the <button> tag used to have don't exist anymore and therefore is highly advisable to use it.
In case you cannot do so for various reasons, just keep in mind to add the attribute role=”button” in your tag as of accessibility.
This article is quite informative: https://www.deque.com/blog/accessible-aria-buttons/
Quoting the Forms Page in the HTML manual:
Buttons created with the BUTTON element function just like buttons created with the INPUT element, but they offer richer rendering possibilities: the BUTTON element may have content. For example, a BUTTON element that contains an image functions like and may resemble an INPUT element whose type is set to "image", but the BUTTON element type allows content.
Use button from input element if you want to create button in a form. And use button tag if you want to create button for an action.
<button>
by default behaves like if it had a "type="submit" attribute
can be used without a form as well as in forms.
text or html content allowed
css pseudo elements allowed (like :before)
tag name is usually unique to a single form
vs.
<input type='button'>
type should be set to 'submit' to behave as a submitting element
can only be used in forms.
only text content allowed
no css pseudo elements
same tag name as most of the forms elements (inputs)
--
in modern browsers, both elements are easily styleable with css but in most cases, button element is preferred as you can style more with inner html and pseudo elements
As far as CSS styling is concerned the <button type="submit" class="Btn">Example</button> is better as it gives you the ability to use CSS :before and :after pseudo classes which can help.
Due to the <input type="button"> visually rendering different to an <a> or <span> when styled with classes in certain situations I avoid them.
It's very worth noting the current top answer was written in 2009. IE6 isn't a concern now days so <button type="submit">Wins</button> styling consistency in my eyes comes out on top.
I just want to add something to the rest of the answers here. Input elements are considered empty or void elements (other empty elements are area , base , br , col , hr , img , input , link , meta , and param. You can also check here), meaning they cannot have any content. In addition to not having any content, empty elements cannot have any pseudo-elements like ::after and ::before, which I consider a major drawback.
There is a big difference if you are using jQuery. jQuery is aware of more events on inputs than it does on buttons. On buttons, jQuery is only aware of 'click' events. On inputs, jQuery is aware of 'click', 'focus', and 'blur' events.
You could always bind events to your buttons as needed, but just be aware that the events that jQuery automatically is aware of are different. For example, if you created a function that was executed whenever there was a 'focusin' event on your page, an input would trigger the function but a button would not.
<button> is flexible in that it can contain HTML. Moreover, it is much easier to style using CSS, and the styling actually gets applied across all browsers. However, there are some drawbacks regarding Internet Explorer (Eww! IE!). Internet Explorer does not detect the value attribute properly, using the tag's content as the value. All of the values in a form are sent to the server-side, regardless of whether or not the button is clicked. This makes using it as a <button type="submit"> tricky and a pain.
<input type="submit"> on the other hand doesn't have any value or detection issues, but you can't, however, add HTML like you can with <button>. It's also harder to style, and the styling doesn't always respond well across all browsers. Hope this helped.
in addition, one of the differences can come from provider of the library, and what they code. for example here i'm using cordova platform in combination with mobile angular ui, and while input/div/etc tags work well with ng-click, the button can cause Visual Studio debugger to crash, surely by differences, that the programmer caused; note that MattC answer point to the same issue, the jQuery is just a lib, and the provider didn't think of some functionality on one element, that s/he provides on another. so when you are using a library, you may face an issue with one element, which you won't face with another. and simply the popular one like input, will mostly be the fixed one, just because it's more popular.
It's also worth mentioning , that the disabled attribute doesn't work well on button for ios- safari (see also - # Khris Vandal comment ).
This happened to me as well .