I'm helping a friend develop an application that involves the following form setup. There's one element (the user's group) that's different from the others, in that it has to be approved by an admin before it can be changed.
Her goal was to make that distinction clear to the user, and the way she wanted to do that is to have the user's current group display as text at first, then have that effectively turn into a select element when the user clicks the Edit Group button.
We have all that in place with no issues, the only question is about the correct semantic choices for the text element representing the user's current group.
We wanted to preserve the same semantic pattern of the label-input pairs from the form above, but we weren't sure how to best represent that when the input is replaced with plain text (we notably care about this as it relates to accessibility). The current draft is to use a description list; is that the best choice for this occasion?
Thank you!
<form action="/user-settings" method="POST">
<label for="username">Username</label>
<input id="username" type="text"/>
<label for="email">Email</label>
<input id="email" type="text"/>
<input type="submit" value="Submit"/>
</form>
<hr>
<dl>
<dt>Group</dt>
<dd>{{ current_group }}</dd>
</dl>
<button>Edit Group</button>
<form action="/group-change-request" method="POST" class="hidden">
<select><!--group options--></select>
<input type="submit" value="Request Group Change"/>
</form>
I would probably display the group as an <input readonly> instead of as plain text so that the user can still tab through the interface and hear the label of the field (assuming you have a <label for="id"> for the readonly field like you do for the other fields).
I would also include some visibly hidden text (but "visible" to a screen reader) that explains why the field is readonly and how to make it editable. Something like:
<label for="myid">group</label>
<input readonly id="myid" aria-describedby="desc">
<span id="desc" class="sr-only">The group is protected until you select the "Request Group Change" button</span>
You can see the "sr-only" class here: What is sr-only in Bootstrap 3?
Related
A client needs to create quite a complex form. We use <fieldset>/<legend> to group certain elements together. But it's not enough - even if we nest them.
Think about the following:
<form>
<fieldset>
<legend>Your personal details</legend>
<label>First name: <input name="first_name"></label>
<label>Last name: <input name="last_name"></label>
<fieldset>
<legend>Gender</legend>
<label>Male: <input type="radio" name="gender" value="male"></label>
<label>Female: <input type="radio" name="gender" value="female"></label>
<label>Other: <input type="radio" name="gender" value="other"></label>
</fieldset>
</fieldset>
</form>
Imagine this is only a small part of a bigger form. For example, we could have a "postal address" and a "billing address". Would we need to "indent" the whole thing once more using <fieldset>/<legend>s?
<form>
<fieldset>
<legend>Postal address</legend>
<fieldset>
<legend>Your personal details</legend>
...
<fieldset>
<legend>Gender</legend>
...
</fieldset>
</fieldset>
</fieldset>
<fieldset>
<legend>Billing address</legend>
...
</fieldset>
</form>
Or should we rather use headings?
<form>
<h2>Postal address</h2>
<fieldset>
<legend>Your personal details</legend>
...
<fieldset>
<legend>Gender</legend>
...
</fieldset>
</fieldset>
<h2>Billing address</h2>
...
</form>
While it's probably valid to nest <fieldset>/<legend>s, I would not over-do it. Party because JAWS will announce the <legend> for each contained input element (in contrast to NVDA that will only announce it once, when reaching the first contained input element).
On the other hand, headings will not be announced at all by desktop screen readers when jumping between form elements using Tab/Shift-Tab. So its information will easily be missed.
What do you think about that, dear screen reader experts? Should we use aria-describedby to attach the headings to the subsequent <fieldset>? What if there's more than one <fieldset> below that heading?
I feel there's no perfect solution here. Any suggestions, please?
It's perfectly valid to nest fieldset+legend, but as you ahve said, some screen readers will repeat it for each of the elements under that legend.
It makes a lot of totally useless redundency.
There is certainly no perfect solution, and no normative solution on this either, but I would go for an hybrid structure.
Use legend only for the deepest level, where elements are really close together such as male/female, yes/no, etc. (i.e. groups of radio buttons), and headings for all the rest and intermediate levels. For example:
<h2>Personal information</h2>
<fieldset>
<legend>Gender</legend>
...
</fieldset>
<fieldset>
<legend>Marital status</legend>
...
</legend>
</fieldset>
<h2>Billing address</h2>
...
<h2>Delivery address</h2>
...
Headings have a great bonus advantage, there are shortcuts keys to jump directly to them. It's especially useful when you want to modify only one or two particular fields in the whole form. You can't do this with legend.
IF you are afraid that the screen reader user miss "Personal information", "Billing address" and "Delivery address", you may use aria-labelledby refering two IDs:
<h2 id="billingAddressHeading">Billing address</h2>
<p><label id="streetLabel" for=street">Street: </label>
<input type="text" aria-labelledby="streetLabel billingAddressHeading"/>
</p>
If you use two IDs like that only on the first field of the group, you make sure that the screen reader won't uselessly read the group label for each of the fields.
Be careful to not forget to reference the label itself in aria-labelledby, because it replaces completely the <label>.
Note that, technically, you are also allowed to use fieldsets without legen.
<h2 id="billingAddressHeading">Billing address</h2>
<p><label id="streetLabel" for=street">Street: </label>
<input type="text" aria-labelledby="streetLabel billingAddressHeading"/>
</p>
As a final note, if you find the form getting too complex, it's maybe the time to think about splitting it into several smaller pages.
I have a label extra description and an input field.
I am a bit unsure if the extra description belongs to the label field wrapped in a span like this:
<label for="phone">
Telephone
<span>For the delivery</span>
</label>
<input type="text" name="phone">
This way the description is clickable. But I am not sure if this is the correct approach with a11y in mind and semantic markup.
Does the extra informations belong to the label or should it be separated and how should it be formatted?
First, I always map the <label> to the id of the field instead of its name (particularly important for radio buttons and checkboxes):
<label for="phone">
Telephone
<span>For the delivery</span>
</label>
<input type="text" name="phone" id="phone">
Your approach is not wrong. If you are concerned about verbosity for screen readers (maybe as the result of user testing) then you can shuffle that a bit and use aria-describedby:
<label for="phone">
Telephone
</label>
<span id="phoneAddl">For the delivery</span>
<input type="text" name="phone" id="phone" aria-describedby="phoneAddl">
aria-describedby still associates it with the field, but announces it after the field and with a brief pause. It has not effect on anything other than a screen reader.
But to your point about the larger click area, and given that semantically it is fine to leave it in the <label>, I would just leave it there as in your example.
It also means you are not relying on ARIA to do the work of a native element (though it is not quite doing the same thing).
I am working on an assignment and am a little lost. The question states:
Create a label element with the text Username. Within the label element, insert
an input box for the username field. Make the field required and add the title Supply
your username
Here is what I have. I am mainly confused on the title portion. Any help is greatly appreciated, and feel free to correct me on the other parts. Thank you
<form id="survey" name="survey"
action="www.sblogger/cgi-bin/subcomments"
method="post">
<fieldset id="commentFS"
<label>
Username
<input id="username">
required="required"
</label>
</fieldset>
</form>
You just need to add a title attribute on the input field. Also the label tag can stay on it's own, which leaves to:
<form id="survey"
name="survey"
action="www.sblogger/cgi-bin/subcomments"
method="post">
<fieldset id="commentFS">
<label>Username</label>
<input id="username"
title="Supply your username"
required>
</fieldset>
</form>
The assignment is not well-defined, since it does not say what kind of a title should be included. It may refer to an advisory title that may be presented to user in some situations (e.g., on mouseover), as assumed in #Jeffrey’s answer. It may also refer to text that appears inside the input box when it is empty, in which case you would use the placeholder attribute. It can also refer to visible text before the input box; this would be the most reasonable setup. Even then, there are several alternatives. It could be just text before the label and the input box, or it could be wrapped in a heading element, or even a legend for a fieldset. The following example is based on the wild assumption that such a legend is desired (which might be a wrong guess if you have actually been told to use the fieldset element, as you are using, although there is no reason to use it in a simple case like this).
<form id="survey" name="survey"
action="http://www.example.com/cgi-bin/subcomments"
method="post">
<fieldset id="commentFS">
<legend>Supply your username</legend>
<label>
Username
<input id="username" name="username"
required="required">
</label>
</fieldset>
<input type="submit" value="Submit">
</form>
Notes: The attribute required="required" (or just required unless you have been told to use XHTML syntax) must appear inside the <input ...> element, not after it. And the input element needs a name attribute, otherwise the data in it will not be sent at all to the server.
I'm working on a HTML5 form and I want to float some input elements and their labels. Its this the best way to do it?
<form>
<fieldset class="float_left">
<label for="login">Login ID #</label>
<input type="text" name="login" id="login">
</fieldset>
<fieldset class="float_right">
<label for="password">Password</label>
<input type="password" name="password" id="password">
</fieldset>
<span class="forgot_login float_left">Forgot your login information?</span>
<input type="submit" value="LOG IN" class="form_button float_right">
</form>
I seen people wrap them in divs, lists, etc. I want to follow the best practice. Should I also wrap every label and input elements with a fieldset even if I don't plan on styling it? Ex:
<form>
<fieldset>
<label for="name">Full Name:</label>
<input type="text" name="name" id="name" placeholder="First Name" class="float_left">
</fieldset>
<fieldset>
<label for="email">Email:</label>
<input type="email" name="email" id="email" placeholder="Ex: johndoe#gmail.com" class="full_input">
</fieldset>
<fieldset>
<textarea rows="3" name="message" id="message" placeholder="1000 Character or less" class="full_input"></textarea>
</fieldset>
<input type="submit" value="SEND" class="form_button float_right">
</form>
Thanks.
The primary, original purpose of a fieldset is to convey a contextual association between multiple input fields to non-visual agents. It is expected that a screen reader is going to read the legend text, then the first field, then the legend, then the next field... As in: "Address: Street 1... Address: Street 2... Address: City..."
For sighted people, a fieldset does visually imply a container-type relationship of the same kind: those fields are related by context, but only when there are multiple fields.
So it never makes semantic sense to have a single label/field (a label is not a field, in that it does not accept input) in a fieldset. It's just annoying to people using screen readers (because it behaves like a redundant label). To sighted people it destroys the implication of relationship if you use it for single fields and also multiple fields, and takes up a lot more space.
In short, use it sparingly, semantically, and correctly - not as a styling device.
For a 'neutral' container, use a div or a span, because they carry no semantic information. List structures, paragraphs, all other elements have semantics and you need to be careful about how you use them.
People will tell you crazy things about the semantics of HTML elements. Don't take anyone at their word, including me. Go read the spec and know it for yourself.
Using fieldset for a combination of a label and a control is illogical, though formally valid: a fieldset is supposed to be a set of fields.
Other than that, the question is largely a matter of opinion and debate. HTML5 more or less favors p for such a pair, but that causes an empty line by default, so div is a more reasonable choice. There are also good reasons to use a table element, with one row for each label/control pair.
Unless you plan to use a fieldset legend then I wouldn't bother using fieldsets. Bootstrap forms is a nice way to get started too http://getbootstrap.com/css/#forms there is no best way though.
You often see people using a wrapper div because it helps with creating a neater row i.e. apply padding to a wrapper instead of to all elements within it or floating all elements within a parent and applying a clear-fix element at the bottom to wrap correctly.. or just float the parent as well.
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.