I am a bit confused in what to use for rendering data. My scenario is that I have to render count and I am not sure about using span or label.
<span id="spnCount"></span>
or
<label id="lblCount"></label>
A label is used when you have a form or input elements - the label is associated with an input element. Span is a general container for any inline content. I think you want a span in this case
Span
The <span> tag is used to group inline-elements in a document.
The <span> tag provides no visual change by itself.
The <span> tag provides a way to add a hook to a part of a text or a part of a document.
Label
The <label> tag defines a label for an element.
The <label> element does not render as anything special for the user. However, it provides a usability improvement for mouse users, because if the user clicks on the text within the <label> element, it toggles the control.
The for attribute of the <label> tag should be equal to the id attribute of the related element to bind them together.
Every single person who "answered", simply copy-pasted documentation that describes the intended use-case. However, nobody explained the differences, or the WHY behind why you SHOULD use one or the other.
The reality is, either one will technically work, so it honestly does not even matter. You could use any number of other similar tags, including the <i> tag (properly styled with a class). Assign it a unique id, use document.getElementById(), or use nodes, etc, do what you want. The only people who care are semantic purists.
The label "can" and "should" be used with a form input element, true. But it is NOT TRUE that it CAN NOT or MUST NOT be used in any other way. Which means it CAN and COULD be used in other ways.
First of all, notice how <label> is simply used as a label "for an element". It does not say what TYPE of element. It does not say it must be an input element or a form element. Indeed, non-form elements can have controls associated with them for provide a user experience, which perhaps manipulate objects with CSS and so on, and a label may simply connect the text to any such things. The form could exist invisibly on page. Who knows.
Why might it be a bad idea to use a standalone label? If your document might exist for a long time, through several browser versions and HTML standards updates, the definition of <label> might change to more strictly enforce association with form input elements, then you might have a problem. But the same is true for just about any other aspect of any of a number of specifications we rely upon just to render a page.
It's probably a very rare scenario that such a change would occur, and you'd likely not even work at the same company or on the same project team, so in all honesty, who really cares except purists?
Well, maybe anyone who is visually impaired if they rely on some technology that treats a <label> different than <span>, which could confuse the technology or the user or both. I don't have any experience with such accessibility devices, but that might be a better reason WHY.
Another valid reason is <span> is shorter to type than <label>.
And another reason might be subtle differences in the way that a search engine ranks your page or references content if using <label> vs <span>. This is a bit of a stretch, because such algorithms are generally not publicly available, but it's possible. One engine might produce better results one way, another engine may prefer the other way, and another engine may not care either way.
All that said, without any further knowledge of context, I'd probably go with <span> as it seems the most generic and least contentious way of doing things. But I felt the question lacked a thorough answer, as answers usually involve a comprehension of why.
If your data is a result of calculation, the output HTML5-element probably fits best for your purpose.
The tag defines a label for an element. If you are not using for input element, span can be used.
A label is used in combination with a form input element. In some browsers the label can be clicked to activate the input element.
label is used for labeling form controls in html. It also has for attribute where you can set id of the control which this label related to. span used in case when you need to display some literal data.
"The <label> tag defines a label for an <input> element."
http://www.w3schools.com/tags/tag_label.asp
Related
I'm adding various Accessibility standards to our enterprise platform UI framework. We use a web client, DOM elements, etc. We render all of the framework in the DOM, but widgets in the framework can (and have for years) been put together in non standard ways by customers to build out various pages of their UI.
I've managed to cover and handle much of the specifications (I think), but I have a specific case, where we have "texty labely widgets" that are used to describe various "input / formlike widgets". Their only connection as far as the DOM goes is a common parent "container" element, a variable distance up the tree.
The ARIA guidelines I'm coming across (which at any point I may have misunderstood) suggest I need to use aria-labeledby="id_of_text_label_widget" on the actual form element. Meaning what I have now is:
<div id="parent_label_value_widget_001">
<div class="inputLabel">This is visible Label Text</div>
<div class="various_other_junk_in_here"></div>
<div class="some_wrapper_around_the_input">
<input id="I_am_the_form_input_in_question_with_a_very_long_id" value="42">
</div>
</div>
I could easily add the aria-labeledby attr to the input, but it means I'd need to add an id to the inputLabel element. And while this seems like not a big deal (it's slightly more complicated because what you see in the DOM is the result of a far more complicated render cycle from a WYSIWYG editor of disconnected widgets), it happens to be, with no possibility for change, that our ids are incredibly long already. Due to huge pages, sometimes tens of thousands of fields and nested dynamic things, etc
Our Ids make up 60% of our payload. And I'd effectively have to double that chunk by adding a new id to every label element, and our content isn't gzipped. So that's what I'm trying to avoid. I actually also don't want to do it for other reasons, as the label widget and the input widget actually know nothing about one another, so I'd have to write some extra render logic to have the input widget pull the id from the sibling label widget.
My question is: does anybody have any other solutions?
Things I've imagined:
A. Is there some technique using aria-label, where I could label the parent container and have screen readers know how to link the internal label and input?
B. I could duplicate the label text from the label widget onto the input widget and use aria-label="duplicated text". I could do this server side with some pain, or client side with some clumsy walking logic, but would rather avoid the duplication, and the extra logic. But if I do that, then do I need to aria-hide all the existing label widgets?
C. Is there some shorthand for <label for=""> or aria-labeledby="" where instead of an id, it can reference elements by css selector, or proximity? (Dreaming, I know), but it's a shot.
D. Make the user opt in to aria support, and only then do they get the doubled package size. (yeah, I know gzip would solve alot of this, but it's a long story why it's not in place).
The short answer is that <input> elements need some kind of label and that label has to be directly associated with, or "tied to", the <input>. "Proximity" is not a direct association. That is, just because a label is "close" to the input in the DOM, that doesn't tie the two elements together.
Some screen readers will try to look for some text to use as a label if one is not explicitely found, but that usually involves going to the previous sibling of the <input> in the DOM and if that sibling has some kind of text associated with it, then treat that like the label. Sometimes it works and sometimes it doesn't. I would not rely on it.
For example,
<label>password</label>
<p>should contain upper and lower case letters, a number, and a special character</p>
<input>
In this case, the "should contain..." text will be treated as the input's label, which is wrong. It doesn't matter that there is a <label> element prior to the <p>. There is nothing in the DOM tying the <label> to the <input>. The above example should be written as:
<label for="pw">password</label>
<p id="rules">should contain upper and lower case letters, a number, and a special character</p>
<input id="pw" aria-describedby="rules">
This associates both text elements with the input. The <label> is tied directly via the for attribute (and the ID on the <input>) and the description of the password is tied via the aria-describedby on the <input>.
So the first choice of labelling an input should be with native html, if possible. Use the for attribute of the <label>.
Another way to label, as you noted, is using the aria-label or aria-labelledby on the <input> itself. While this will give the input an accessible name for screen readers, it won't help sighted users. The aria-label is not a visible thing. However, in your case, it looks like there is already a visual label (even if it's not officially "tied" to the input).
So, to comment on your four proposals (A-D):
A. You can put aria-label on the parent container but the <input> would still need to be told to look at the parent to retrieve the label, and that's done with aria-labelledby on the <input> (and would require an ID on the parent so you can point to it.).
B. If you put the aria-label directly on the <input>, then yes, you should set aria-hidden="true" on the visible label, otherwise a screen reader user can navigate to the visible label text and then navigate to the input and hear the same text again. But that's an odd solution. If the text is already visible, the best thing is to put an ID on the visible text and associate it with the <input> via aria-labelledby.
C. Worth a short, but no.
D. This is a friendly place so all ideas will be considered, but please do not do this. Do not segregate different types of users or force people to opt-in to an accessible site.
It sounds like your main argument for not creating an accessible solution is the size of your page. Not to be dramatic, but that wouldn't hold up in court. That is, if your site ended up being the defendant in litigation, arguing that you didn't implement accessibility because you didn't want the page load to be larger would not be a valid reason. That's just an implementation problem on your end.
I know that you can use both but is it better to use one over the other? If so, why?
Example of "for" attribute:
<input type="text" id="male"><label for="male">Male</label>
Example of wrap:
<label>Age:<input type="text"></label>
Semantically, both possibilities are the same. But depending on what layout you want, there are advantages and disadvantages for the two possibilites. For example, if you want that the label is at an entirely different place, it would not make any sense to put the input into the label. But if you want to be able to make a hover-effect via css, that sets e. g. a background for both the label and the area around the input, it would be better to put the input into the label.
according to
http://www.w3.org/TR/2008/WD-WCAG20-TECHS-20080430/H44.html
some assistive technologies do not correctly handle implicit labels
So when you wrap, you may also want to provide the "for" attribute to the label element.
The wrap allows to drop the for attribute, which in turn allows to omit the `id' attribute on the input element. Great for templates or any forms that need to be used in multiple instances on a page.
It doesn't matter. Both accomplish the same things in terms of defining the relationship between the label and field.
Embedding the input in the label also affects the wrapping behaviour. <label><checkbox/>Value with spaces</label> will wrap as a single unit by default. Whereas <checkbox id="check"/><label for="check">Value with spaces</label> will wrap the text with breaks at spaces and will wrap the label to a new line but leave the checkbox above.
If it counts for anything, frameworks like ASP.NET put the label element next to the input/select/textarea elements and use the label's for attribute.
The 'label for' syntax means the label you have created is intended to be a label for the input with id 'inp'. If you click this label in most browsers the cursor focus will land on the 'inp' input element. It's a nice little way of linking a label with its corresponding form control.
I'm not aware of compatibility issues, or any around performance. To me it seems syntactically sound, and as far as I'm aware the CSS spec claims that both are valid.
The relationship is more explicitly defined when using the for syntax, although I believe most browsers implement the same behaviour for both.
A matter of preference, I think. Personally I would use the for syntax as I think it makes more semantical sense than for the input element to be a part of its label element.
I know that you can use both but is it better to use one over the other? If so, why?
Example of "for" attribute:
<input type="text" id="male"><label for="male">Male</label>
Example of wrap:
<label>Age:<input type="text"></label>
Semantically, both possibilities are the same. But depending on what layout you want, there are advantages and disadvantages for the two possibilites. For example, if you want that the label is at an entirely different place, it would not make any sense to put the input into the label. But if you want to be able to make a hover-effect via css, that sets e. g. a background for both the label and the area around the input, it would be better to put the input into the label.
according to
http://www.w3.org/TR/2008/WD-WCAG20-TECHS-20080430/H44.html
some assistive technologies do not correctly handle implicit labels
So when you wrap, you may also want to provide the "for" attribute to the label element.
The wrap allows to drop the for attribute, which in turn allows to omit the `id' attribute on the input element. Great for templates or any forms that need to be used in multiple instances on a page.
It doesn't matter. Both accomplish the same things in terms of defining the relationship between the label and field.
Embedding the input in the label also affects the wrapping behaviour. <label><checkbox/>Value with spaces</label> will wrap as a single unit by default. Whereas <checkbox id="check"/><label for="check">Value with spaces</label> will wrap the text with breaks at spaces and will wrap the label to a new line but leave the checkbox above.
If it counts for anything, frameworks like ASP.NET put the label element next to the input/select/textarea elements and use the label's for attribute.
The 'label for' syntax means the label you have created is intended to be a label for the input with id 'inp'. If you click this label in most browsers the cursor focus will land on the 'inp' input element. It's a nice little way of linking a label with its corresponding form control.
I'm not aware of compatibility issues, or any around performance. To me it seems syntactically sound, and as far as I'm aware the CSS spec claims that both are valid.
The relationship is more explicitly defined when using the for syntax, although I believe most browsers implement the same behaviour for both.
A matter of preference, I think. Personally I would use the for syntax as I think it makes more semantical sense than for the input element to be a part of its label element.
I've noticed that a HTML label tag doesn't need the 'for' attribute when you put your input element into the label element:
<label><input type="text">Last name</label>
But I was wondering what's the best practise. Can anybody help me with that?
Thanks!
It's used for accessibility for screen readers and the like i.e.
use_the_label_element_to_make_your_html_forms_accessible
So you should use it. And here is a link to convince you about the importance of accessibily.
And here is a little story - making your site accessible can benefit all users - i always was amazed at the amount of effort civic authorities went to for wheelchair accessibilty until I had a daughter and use a push chair. I think websites follow the same rule - everyone benefits.
Apologies for the polemic
Both the W3 HTML 5.2 standard and the WhatWG Living Standard state (in almost exact terms, quote is from the latter):
The for attribute may be specified to indicate a form control with which the caption is to be associated. If the attribute is specified, the attribute's value must be the ID of a labelable element in the same tree as the label element. If the attribute is specified and there is an element in the tree whose ID is equal to the value of the for attribute, and the first such element in tree order is a labelable element, then that element is the label element's labeled control.
So it's okay to use it that way in terms of following the HTML standard.
The for attribute doesn't make much difference with a text input, but is very useful with a checkbox input, as it allows users to click on the label as well as the checkbox itself:
<label for="chk">Checkbox</label><input type="checkbox" id="chk" />
You can include the input in your label and it is associated with the label, or if for some reason you have to have your label element elsewhere in the DOM, you can specify it's meaning with the for attribute. It never hurts to use the forattribute though either way :)
We were discussing with a co-worker and trying to decide on what HTML element to use for a form validation error message.
One of us is saying that we should use a span or a div because it is a part of an input field, and the other is saying that it should be a p element because it is a text.
What do you guys think?
I believe you should use a <label> which directly associates the error message with the input element.
quoting the W3 specs
The LABEL element may be used to attach information to controls.
and
More than one LABEL may be associated with the same control by creating multiple references via the for attribute.
See also Error Message: <span> vs <label>
In principle, the choice of element should be dictated by the meaning, not by "how and where you want to display" it (as #Babiker suggested). That's kind of the whole idea, not to mention the effects the choice will have on (for example) visually-impaired users (for whom the "where you display it" may be totally lost).
It does seem unfortunate that even HTML 5 doesn't have an element for this. Perhaps 'aside' (http://www.w3.org/TR/html5/sections.html#the-aside-element) would be the closest? The spec describes it in Section 4.3.5 as:
The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content. Such sections are often represented as sidebars in printed typography.
The element can be used for typographical effects like pull quotes or sidebars, for advertising, for groups of nav elements, and for other content that is considered separate from the main content of the page.
WCAG2.0 guidelines, on
1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.
Lists as sufficient techniques.
G138: Using semantic markup whenever color cues are used
And
H49: Using semantic markup to mark emphasized or special text
Based on those, I infer that the only appropriate tags for errors are <em> and <strong>
Using <label> in not enough as it shows relationship between the label content and the target field, but doesn't communicate the importance of the content.
There is no right tag to use for an error message. It all depends on how and where you want to display the error. Once you decide on these things, your choices will be narrowed, as tag properties and limitations differ. But how did <p> come in this?
Just throwing into the jar: What about <ul>-Elements. If an input-field's validation fails for more than one reason, than you may want to attach more than one error-message to that field.
Example for an file-upload-field:
The file you tried to upload has the wrong format. (Only png, gif and jpg are allowed)
The file you tried to upload is to large. (Max 1MB)
and so on...
The Zend-Framework Error-Decorators for example are using ul-Elements.
However if I had to choose, between div, p and span, my choice would be div. Best stylable (Background-color for example).
You could use
<pre>Error</pre>