I'd like to take advantage of the improved semantics of html5. I'm creating a search area, and the search area should have a background and contain search related things, like autocomplete and search hints.
Is there some consensus around what type of element something like a search area should be wrapped in?
Should it be a NAV because searching is a method of navigation?
Should it be a SECTION because it's a discreet section of the page?
Should it be a DIV because the wrapping of search related elements has no clear semantics?
The markup is something like this:
<?whatElement?>
<input type="search" placeholder="Search for a name or ID..." required />
Search
</?whatElement?>
Thanks for your thoughts.
I am aware this question already has a chosen answer, but it ranked so high in my Google search for "semantic search form" that I feel the need to contribute what I believe to be a slightly better answer, semantically and from a standards standpoint.
<section role="search">
<form action="#" method="get">
<fieldset>
<legend>Search this website:</legend>
<label for="s">
<input type="search" name="s" id="s" placeholder="Search..." maxlength="200" />
</label>
<button type="submit" title="Search this website now">Submit</button>
</fieldset>
</form>
</section>
Of course, I made a series of assumptions and populated the HTML with some default values (action, get, the id and name of the input, etc) and with no classnames for the elements (which I always tend to use in favor of generic element names or, Heaven forbid, IDs) but you should adapt to your own needs.
For example, some additions on top of the excellent contributions above: the first child of any form should always be a <fieldset> tag and have a <legend> attached (visible or not - https://www.w3.org/TR/WCAG20-TECHS/H71.html ), and all <input> tags should have a connected <label> tag through the for and id properties (https://www.w3.org/TR/WCAG20-TECHS/H44.html - I find it easier to just wrap the input in the label so as not to forget connecting them). All call to action elements should have a title (for SEO and usability, to reinforce the action the user is about to make just before she makes it), etc.
The HTML5 specification says this about the section element:
Role must be either region, document,
application, contentinfo, main,
search, alert, dialog, alertdialog,
status, or log
so I would use that.
How about:
<form>
<input type="search" name="" value="" />
<input type="submit" value="Search" />
</form>
<section role="search">
The role attribute is an ARIA landmark:
A landmark region that contains a collection of items and objects that, as a whole, combine to create a search facility.
Related
<input type="search" placeholder="search" />
The screen reader ignores this when search field is focused! What attribute to be added so that the screen reader would say "This is a search box " Thanks.
The way to make it accessible is use text and markup around the input element rather than attributes. This way, you don’t rely on any specific support to some special attributes (which greatly varies across browsers). Example:
<form action=... role="search">
<h2>Search this site</h2>
<label for="q">Keywords:</label>
<input type="search" id="q" name="q">
<input type="submit" value="Search">
</form>
Then it is OK that the input field is spoken as a normal text field, since the user already knows it’s for entering keywords for a search.
If you are forced to play with small input box without a label, due to site layout requirements, then accessibility is inevitably reduced. You can try to help some users with some attributes that might get recognized and used by some browsers, e.g.
<input type="search" name="q" placeholder="keywords"
title="Keywords for a site-wide search"
aria-label="Keywords for a site-wide search">
Note: The placeholder attribute should contain text that acts a hint of the expected input, rather than a general name for some functionality.
Reference for role and aria-* attributes: Using WAI-ARIA in HTML (WD).
I tend to try and steer clear of using ID's outside of functionality purposes. Which brings me to my question, when labelling items in forms there are multiple methods. I have always done this a specific way to avoid ID's; however, what are the pro's and con's of the alternate methods? Does one way have more semantic meaning to the browser than the other? How does accessibility play a role in it?
My usual method of implementation:
<form role="form" action="#" method="post" name="form" novalidate>
<label>
<span>Search</span>
<input role="search" type="search" placeholder="Search" name="s">
</label>
<button role="button" type="submit" name="s-btn">Search</button>
</form>
However, you can also use for="" and label an ID for the corresponding field. Which is obviously better served for type="radio" and type="checkbox" but does it hold any better semantic value than the above?
<form role="form" action="#" method="post" name="form" novalidate>
<label for="s">Search</label>
<input role="search" type="search" id="s" placeholder="Search" name="s">
<button role="button" type="submit" name="s-btn">Search</button>
</form>
And you can even use WAI-ARIA to label as well with ID's, should this be used in cohesion with for="" or is it a stand alone labelling method?
<form role="form" action="#" method="post" id="Form" novalidate>
<label id="s" for="sf">Search</label>
<input role="search" aria-labelledby="s form" id="sf" type="search" placeholder="Search" name="s">
<button role="button" aria-labelledby="form" type="submit" name="s-btn">Search</button>
</form>
I guess this question is brought on due to the never ending pursuit of balancing maintainability, optimizations, semantics, and accessibility.
the two methods, nesting controls into labels (implicit) and using id and for attributes (explicit) have different positives and negatives, however the current trend i've seen from professionals is to move away from implicit and more into explicit.
explicit allows more flexibility within your document(s), and html5 allows form controls to be placed anywhere within the document, so they go hand in hand in this case.
implicit can't be used for checkboxes and radios, as the label element is required to come after the input form control, so there is one limitation. implicit also had poor browser support a few years ago, and seems to still have trouble with screen readers. implicit does add to accessibility and usability, because the label's size adds to the form control's clickable surface area.
wai-aria still isn't finished, and also has problems with browser/screen reader support, but that certainly shouldn't stop you from implementing it when possible. ideally, if not supported, it will simply fail silently (like html5 inputs do with non-html5 supporting browsers), but i would be wary here and test vigilantly. different supports can also have one screen reader/browser/user agent reading both, instead of seeking wai-aria, and defaulting to imp/exp labeling.
semantics: meh. ask 10 devs, you'll get 10 answers. but the correct answer is are you using that form control properly? is it labeled correctly? properly and correctly meaning will it validate and pass accessibility testing? properly and correctly also meaning, in your personal context, in this use-case, are you using the correct control/label for the interaction you are providing the user? only you can answer the latter...if you're using posh principals, you shouldn't have any problem with either.
side note: about avoiding ids, in this case, ids are optimal and they are being used for functionality...i'm assuming the form controls are being processed on submit? i could be wrong about functionality in regards to your intended use, but they are still optimal here, if you are avoiding them for wpo: you can use ids, just don't target them in your style sheets.
I am currently writing a Java EE web-app using JSP's and I have a question regarding HTML tags.
I use fieldsets to properly structurate my forms on the main page and find myself perplexed and was wondering if the following was legal:
<fieldset id="FieldMain">
<form method="post" action="servletA">
<input name="a" type="text" />
<fieldset id="FieldA">
<input name="b" type="text" />
<input name="c" type="text" />
<input name="d" type="submit" value="Go for A" />
</fieldset>
</form>
<form method="post" action="servletB">
<fieldset id="FieldB">
<input name="e" type="text" />
<input name="f" type="text" />
<input name="g" type="submit" value="Go for B" />
</fieldset
</form>
</fieldset>
With the desired result being that when clicking the "Go for A" button it takes into account the field a, b and c (a being outside of the fieldset fieldA but inside the form A tag) while clicking go for B only takes fields e and f.
In other words, if I use field sets, can I have several forms in one single fieldset tag ? And can I have some fields outside of any fieldset tag as long as it is in the form tag ?
Thank you :-)
It's legal, but it's not entended to do this
The FIELDSET element allows authors to group thematically related
controls and labels. Grouping controls makes it easier for users to
understand their purpose while simultaneously facilitating tabbing
navigation for visual user agents and speech navigation for
speech-oriented user agents. The proper use of this element makes
documents more accessible.
Source: http://www.w3.org/TR/html4/interact/forms.html#h-17.10
As far as I remember form past discussions: it's legal according to
the letter of the standard and the DTD also makes it valid where a
block element is valid. Now as to intend, that's harder to determine,
it feels to me to be intended to be used in forms only. I don't know
why it got the far wider scope.
Also note that -despite the CSS standard not stating it should- a
fieldset creates a new stacking context (logical if you think about it
and the default way it's rendered, but not mentioned in the standard
AFAIK).
IMHO extensive use of it outside forms and/or reliance on the new
stacking context are dangerous if you want future proof code.
source: http://www.webmasterworld.com/html/3915579.htm
I've been a developer for a long time, however forms have always been my least favourite part, more specifically designing them!
I'd really like to know how you do you forms, and why. I've had a few discussions with fellow developers over <div> vs <p> on form fields. Which one would you stick with, and why?
An example of what I am talking about:
<form action="" method="post">
<p>
<label for="username">Username:</label>
<input type="text" name="username" id="username" />
</p>
<p>
<label for="submit"></label>
<input type="submit" name="submit" id="submit" value="Log In" />
</p>
</form>
VS
<form action="" method="post">
<div>
<label for="username">Username:</label>
<input type="text" name="username" id="username" />
</div>
<div>
<label for="submit"></label>
<input type="submit" name="submit" id="submit" value="Log In" />
</div>
</form>
When it comes to styling, it seems you can do pretty much the same with both, so is it just personal preference, or is there logic behind using one over the other?
Thanks for your time :)
UPDATE
I ended up following a nice article on HTML5 forms and have actually found it to allow MUCH better styling of forms. They are much more organised from a development perspective too. For anyone interested, it is located here: http://24ways.org/2009/have-a-field-day-with-html5-forms
HTML is all about semantics. There is no reason username or submit should be inside a paragraph (<p>) because it's not a paragraph.
So I would go using <div> instead. Ok, maybe <div> has no meaning at all. But it's better than <p>.
I prefer the <div> variant, because its semantics is closer on what you want to express and markup.
A <p> tag is for text paragraphs, whereas a <div> is a general block of any kind.
One option I'd like to suggest:
You could consider wrapping the input inside its label. That way you possibly can avoid additional elements. Also (if you don't need to support IE6) then this allows you to drop the for. And finally if the input is a check box or radio button, then it allows the user to click on the whole text instead of just the tiny control, just like in most operating systems:
<label>Username: <input type="text" name="username" /></label>
Also I'm not sure what the point of an empty label for the submit button is good for, except being lazy when writing the style sheet.
Just thought I'd throw my 2 cents in (assuming we all agree that semantic markup is the goal):
While one can argue that form elements themselves are not semantic, this doesn't mean that the context in which they appear is not as well. There is no "one true way" to markup all form controls.
If the control is actually appearing in a paragraph of text, that is fine - but that pretty much never happens.
If it is an ordered list of checkboxes for example, put them in an <ol> tag.
If order is not relevant, use a <ul> in that case.
If it is a label/text_input pair, one could argue that a <dl> element is appropriate
If it is a spreadsheet, use a <table> (Yes, tables can be appropriate! In fact, I've heard the (questionable) argument many times that form data is tabular)
By the way it is considered a description list in HTML5 to clear up confusion about meaning, and whether or not it's appropriate for things other than literal definition terms.
Almost no one will ever say a <p> is appropriate, but very few will argue that a <div> is inappropriate because there are no attached semantics.
Semantically, each label is bound to its control through the for attribute. There's no need to wrap the pair for semantic reasons, although you may wish to do so for styling reasons. So div is appropriate.
Similarly, grouping of controls has a dedicated element fieldset so there's no sense in using ul, ol or dl for that purpose, and using them is simply a form of listitis.
What about fieldsets ? - it is more logical for forms
And in fact you can style anything the way you want
Semantically I'd say divs make more sense simply because they have no semantic meaning and the only reason to use a block container like this is for layout purposes. That said, I use paragraphs, but completely out of habit. It's the only place I use paragraphs while not considering their semantic meaning.
English isn't my native language so I'm little confused when I see tags like...
form, input, textarea, select, fieldset, label etc..
Can you enlighten me and tell me when, why and how to use these tags to make HTML form. It's more like a SEO question even... You know, you could write like:
<form ...>
<p><input type="text" /></p>
<p><input type="password" /></p>
<p><button>I Won't Bite!</button></p>
</form>
But Google won't be happy and I'm 100% sure that it won't be correct neither. Yes, it would work, because you can style your tags to act like anything with CSS, but it still isn't correct... Enlighten me, good people!
I think the reference you're looking for is the HTML spec on the <form> element.
If you're not sure if your markup is semantically valid, you can check it using the W3C Makrup Validator, but it's generally not worth making your markup 100% valid — much more important to create a page that looks and works reasonably consistently across browsers.
As for SEO, there is a ton of relevant questions on SO already, such as What is the best way to structure an HTML document for SEO and accessibility?
<form action="W" method="X"></form>
HTML forms are pieces of codes that can be used in various functions. The most common use for is to send data to another page using GET method or POST method.
The form action value W would be replaced with the URL of the processing script.
The form method value X would be replaced with GET or POST.
<input type="text" />
The text field to get input from user.
<input type="password" />
The password field by itself only hides the text on the users screen
A secure link between the browser and server is a seperate matter
<textarea>
This puts text on a single line until the enter key is pressed
The <select> tag is used to create a select list (drop-down list).
The <option> tags inside the select element define the available options in the list.
<select>
<option value="volvo">Volvo</option>
<option value="saab">Saab</option>
<option value="mercedes">Mercedes</option>
<option value="audi">Audi</option>
</select>
The <fieldset> tag is used to logically group together elements in a form.
The <fieldset> tag draws a box around the related form elements.
<fieldset>
<legend>Personalia:</legend>
Name: <input type="text" size="30" /><br />
Email: <input type="text" size="30" /><br />
Date of birth: <input type="text" size="10" />
</fieldset>
The <label> tag defines a label for an input element.
<label for="male">Male</label>
SEO is for optimization of content so that search engines can find important keywords in the content. There is no real value in optimization of forms because that is just a markup to define input fields for user. Form is for posting data to the server. I think that many search engines even skip forms.
I kow this is very old question.
You can use asterisk '*' and space this will give you bullet point
example
/** Here is one line
* * point one
* * point two
*/
below will be the result.
Here is one line
point one
point two