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>
Related
I currently have an id attribute on each section heading in a HTML document, so that URLs can be generated with a hash fragment that links directly to that section in the document. For example:
<h2 id="section3.4">Section 3.4 - Foo</h2>
This would, of course, be linked as page.html#section3.4.
I would like to offer an alternative formatting for that fragment, e.g. page.html#s3.4. The exact formatting is arbitrary and not important here.
Obviously one cannot simply apply multiple ID tags to a single HTML element in order to achieve this. The solution, it seems, is to add a secondary tag to the page at the same position as the heading, e.g.:
<h2 id="section3.4">Section 3.4 - Foo</h2><xyz id="s3.4"></xyz>
Is there a standard or preferred tag type that is used for this purpose? Searching around, I was surprised to find no "best practice" answer for this.
Technically the tag type is arbitrary, since any element with an id attribute should work, but picking canvas or script, for example, is clearly silly. I've seen a suggested, but I'm not sure that is semantically correct, since a is supposed to create an anchor to a location, not be a location.
One thought I had was to have the enclosing section tag's ID be the target, but that doesn't enable an arbitrary number of alternate fragment names, and technically it isn't linking to the same location since the bounding box is subject to CSS.
I feel like the ideal element would be one that is guaranteed to have no visual presence on the DOM, hold the same vertical position as the adjacent element, have no side effects, and which makes semantic sense as a positional marker, all while also not having any impact on accessibility (e.g. screenreaders). However, I cannot think of such an element. Is there a standard that I missed? If not, which tag might be the best option?
In inline contexts, use a <span> element wrapping the text inside the appropriate heading.
<h2 id="section3.4"><span id="s3.4">Section 3.4 - Foo</span></h2>
In block contexts, use a <div>.
Both are semantically neutral. And this approach ensures the heading text receives appropriate focus regardless of which fragment identifier is used.
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 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
I'm editing books/articles in HTML. These texts were printed once and I scan them, convert them into an intermediate XML-Format and then I transform them into HTML (by XSLT). Because some of those texts are extinct from the market today and are only available through the major libraries I want to publish them in a way so that people could possibly cite them by referring to the page numbers in the original document. For this purpose my intermediate XML-format has an element that marks a page-break. Right now I'm working on the XML->HTML transformations and I'm wondering myself how to transform these page breaks in HTML. They should not appear in the final HTML by default (so a simple | doesn't fit) but I plan to wrap these documents with some lightweight JavaScript that will show the markers when needed. I thought about <span>s with a | in it that are hidden by default.
Is there a better, possibly 'semantic' way to this problem?
Page breaks are very much a thing of layout, and HTML isn't designed to describe layout, so you aren't going to find anything that is semantic for this within the language.
The best you can hope for is some sort of kludge.
Since a page break can occur in the middle of a paragraph, and <p> elements can contain only inline elements you can eliminate most of the options from the outset.
The two possibilities that suggest themselves to me are <span> and <a>. The former has no semantics, that latter is designed to be linked to (with a name attribute) or from (with an href attribute), and you could consider a page from an original document something that you might wish to link to.
No matter what element you use, I wouldn't include a marker in it and then hide it with CSS. That sort of presentational flag is something I would consider adding via :before in a stylesheet (combined with a descendent selector for a body class that can be toggled with JS since you want the toggle)
Alternatively, if you want to take a (very) broad view of the meaning of "HTML" you could consider the l element (from the defunct XHTML 2 drafts) and markup each line of the original document. Adding a class would indicate where a new page began (and you could use CSS counters and borders to clearly indicate each page and number it should you so wish). Pity the browser vendors refused to get behind a real semantic markup language and favoured HTML 5 instead.
Use a <div class="Page"> for each page, and have a stylesheet containing:
.Page {
page-break-after: always;
}
Maybe you can use an xml tag not parsed/interpreted by html like <pagebreak/>.
In this way viewing the html the tag will be not rendered but using jQuery or any other Javascript library, transform, when asked, these particular tags in standard or whatsoever visual mark.
I think this can be a semantic approach...
I see the <p> tag used a lot in the code of others but have never used it in my own work.
I'm wondering what advantage this gives over using a <div> tag?
Are there any benefits I could get
from incorporating the <p> tag
into my pages?
Is there any disadvantage in only
using <div> tags without <p>?
DIV indicates a separate section on a page, which is not semantically connected to the others. With P tags you indicate that this piece of text is broken into paragraphs but it still stays a single entity.
ADDED: With "semantics" people usually refer to the possibility to extract information from HTML as to what various elements of a page represent and how they are related to each other, as opposed to treating the whole HTML as just a markup to be rendered. For example, when you do menus it is recommended that you use ULs (unordered list) for that purpose, because it will be possible to learn from the markup that all LIs (list items) contained within a particular list probably mean choice options of the same level. I know it is helpful for screen readers for impaired people that you try to make your markup as semantic-rich as possible.
If you're not concerned with this, then it is virtually no difference for the rendered result whether you use DIVs or Ps. You can style both with CSS to achieve the same look and feel.
Semantic HTML is still not "the absolute good" to be strived for. For many people semantics does not add any value as they wish just that their pages are rendered correctly. That's why the ever-lasting discussion on whether to use tables for markup (and add semantics where it does not belong) or stick to CSS is not going to end any soon.
p means 'paragraph', div means 'division'. That's as complicated as it gets. It's a way of telling search-engines, scrapers, tools, etc that this is a paragraph of text.
div is undesirable when you're actually marking up a 'paragraph' of text.
Both tags have a different purpose.
p indicates a paragraph, usually for
organising content (text and
images,mostly)
div on the other hand is a
rectangular space on the canvas,
usually for layout purposes.
Example: You would put your navigation panel in a div, making it easy to move it from the left to the right of the page, or switching to a 3 column layout. The different sections in your navigation (first the general site navigation, next specific hotlinks to the most recent blog post or whatever) could be seperated by putting them in defferent paragraphs.
(I know, bad example, because the navigation is better represented by unordered lists, but what the hey).
In direct answer to your question, they give you the advantage of differentiating between organising your layout and organising your content, in a way that becomes clear in the HTML source.
If you are tagging content so you can lay it out with CSS, you probably want <div>; <p> should be used to indicate a paragraph of text and that's it.
Beyond just the semantics of it (which are important), you will also want to consider validation problems. According to the HTML4 spec, you are not allowed to nest other block-level elements (<div>, <ul>, other <p>, etc) inside a <p> without invalidating your HTML.
I've seen a number of instances where parsers will choose to prematurely close the <p> to allow the other nested block element to begin.
Are there any benefits I could get
from incorporating the tag into my
pages?
Yes, provided that you use it correctly -- because the use of semantic HTML is always a benefit.
There are a range of reasons why this is so, but the primary one for people who need a quick explanation is SEO. Search engines will understand your page better if you use semantic HTML.
p tags are for paragraphs. p tags often contain additional CSS styling regarding the textual content that goes into them, and this styling can be defined in various places in the css documentation. for example, a p usually has a bit of extra space below it. if you try laying something out with p tags, you'll end up with uneven padding.
It is better to use divs if you want to have more control over the content in your page from a programmatic perspective. sticking to divs for all layout concerns will also allow you to use p tags exclusively for paragraphs.