In-field labels are extremely popular now. They save space and look cool. There are many, many ways to accomplish them. It is now very easy to do using the HTML5 placeholder parameter for form inputs. You can even then create backwards compatibility with a bit of jquery if you want to.
But, is it semantically correct to use placeholder="Name" instead of <label>Name</label> or should a label element always be included and placeholder reserved to guide the user like this:
<label for="name">Name</label><input id="name" type="text" placeholder="Jane Doe">
If it's generally considered ok to use placeholder as either a label or an example, then that's definitely the easiest way to accomplish this effect. No javascript needed for modern browsers, no chance of submitting the label as the input value, etc. What are the semantic and practical drawbacks of doing this, if any?
The HTML5 specification explicitly calls this out. It says:
The placeholder attribute should not be used as a replacement for a
label. For a longer hint or other advisory text, place the text next
to the control.
Use of the placeholder attribute as a replacement for a label can
reduce the accessibility and usability of the control for a range of
users including older users and users with cognitive, mobility, fine
motor skill or vision impairments. While the hint given by the
control's label is shown at all times, the short hint given in the
placeholder attribute is only shown before the user enters a value.
Furthermore, placeholder text may be mistaken for a pre-filled value,
and as commonly implemented the default color of the placeholder text
provides insufficient contrast and the lack of a separate visible
label reduces the size of the hit region available for setting focus
on the control.
HTML5 spec notwithstanding, It's becoming popular to use the "Float Label Pattern". The label starts as a placeholder, but then moves up above the field once text has been entered.
There's a handy tutorial for it here....
http://webdesign.tutsplus.com/tutorials/ux-tutorials/implementing-the-float-label-form-pattern/
Related
please , I need to know difference between area-placeholder and placeholder ? when area-placeholder will appear in input field
<input type="search" placeholder="Search" aria-placeholder="Search2" />
edit (added a deeper explanation)
ARIA labels are used to express semantics that HTML can't express on its own, i.e bridging areas with accessibility issues that can't be managed with native HTML. It works by allowing you to specify attributes that modify the way an element is translated into the accessibility tree.
for example, let's use a list item as a custom checkbox (the CSS class 'checkbox' gives the element the required visual characteristics.
<li tabindex="0" class="checkbox" checked>
Receive promotional offers
</li>
for sighted users, this will work fine, but a screen reader won't give an indication that this element is a checkbox, so users with low vision might miss this element.
using ARIA will give the element the missing information for the screen reader to properly interpret it.
there are many ARIA attributes, and if you plan on using them (you should!) i recommended reading more here
Aria-label allows us to specify a string to be used as the accessible label. This overrides any other native labeling mechanism, such as a label element — for example, if a button has both text content and an aria-label, only the aria-label value will be used.
A placeholder is a text that appears in the form control when it has no value set. The HTML placeholder attribute enables providing a sample value or a brief description of the expected format for several HTML types and .
If you are creating a textbox using any other element, the placeholder is not supported. That is where aria-placeholder comes into play. The aria-placeholder attribute can be used to define a short hint to help the user understand what type of data is expected when a non-semantic form control has no value.
<p id="date-of-birth">Birthday</span>
<div contenteditable role="textbox" aria-labelledby="date-of-birth"
aria-placeholder="MM-DD-YYYY">MM-DD-YYYY</div>
The placeholder hint should be shown to the user whenever the control's value is empty, including when a value is deleted.
The aria-placeholder is used , in addition, to, not instead of, a label. They have different purposes and different functionality. A label explains what kind of information is expected. Placeholder text provides a hint about the expected value.
ARIA is only modifying the accessibility tree for an element and therefore how assistive technology presents the content to your users. ARIA doesn't change anything about the function or behavior of an element. When not using semantic HTML elements for their intended purpose and default functionality, you must use JavaScript to manage behavior.
for a more detailed explanation, you can visit the aria-label page on Mozilla
I came across a problem working with a screen reader (NVDA) reading placeholder information when it was not supposed to.
I have input with a title and placeholder. The screen reads placeholder first and then reads the title:
<div>
<input type='text' placeholder='DD.MM.RRRR' title='Insert date correctely in the format DD.MM.RRRR' />
</div>
Based on the information provided by the web, the NVDA shouldn't read placeholder at first place, it should only be available for visual purposes. I've already tried some workarounds using aria-describedby and aria-placeholder.
The basic question is how to make placeholder invisible for screen readers?
JSFiddle
Adding on to what #GrahamRitchie said, keep in mind that all interactive elements have an "accessible name" and an "accessible description". Both are typically announced by a screen reader although you can change your screen reader settings to turn off the description (sometimes referred to as a "hint" in the screen reader settings).
How the accessible name and description are computed can be very handy in understanding this situation. There is a precedence list of attributes that are inspected to compute the name and description. Once an attribute is found, the remaining items in the precedence list are ignored. It's basically this:
aria-labelledby
aria-label
placeholder attribute or <label> element
other stuff
title attribute
So if you have both an aria-labelledby attribute and a <label> element, only the aria-labelledby attribute will be used because it has higher precedence. The label will be ignored.
That being said, since your original code had an <input> that didn't have a label, the accessible name used the placeholder attribute. If you change your code to have a <label>, then the label will have higher precedence than the placeholder and the placeholder will be ignored for the accessible name. However, the placeholder might be considered for the accessible description.
You can see this in the accessibility inspector in Chrome. In the panel where CSS is usually displayed, there is an "Accessibility" tab (usually hidden in the ">>" menu).
Displaying the accessibility properties helps understand what is being announced by the screen reader.
Notice the "Name" (which is the accessible name) is "DD.MM.RRRR" and it says it comes from the placeholder attribute. It also says the "Description" (which is the accessible description) is "Insert date correctly...", which comes from the title attribute (but the tool doesn't tell you which attribute contributed to the accessible description).
If you were to have a <label> for your <input>
<label for="foo">date</label>
<input id="foo" type='text' placeholder='DD.MM.RRRR' title='Insert date correctely in the format DD.MM.RRRR' />
Notice how the accessible name changes. The placeholder is no longer used. The description stayed the same.
Now, all that being said, there are still two confusing points. The accessible name calculation, in step D, says if there's an attribute or an element that provides alternative text, then use it. But the example they give of an attribute is title. But down in step I (eye), it says if there's a tooltip attribute, then use it. Well, the title attribute IS the tooltip attribute so why is it used as an example in step D if it's going to be used in step I? I don't know, sorry. It's an ambiguity in the spec.
And just to add to the confusion, even though Chrome shows the accessible description is the title attribute, the placeholder is STILL read after the description, as if it were part of the description, even though it's not shown as part of the description in the inspector. I would consider that a bug. Whether it's a Chrome bug or NVDA bug remains to be determined.
Screen readers will read the placeholder attribute when the field is empty.
This is expected behaviour in screen readers that support placeholders.
I think the confusion comes where it is advised not to use a placeholder instead of a label.
The reason is that once the field is filled in a lot of screen readers will not read the placeholder (as it is no longer shown) and so a completed field no longer has a name that can be read out by the screen reader. (plus visible labels help people with cognitive disabilities etc.)
So assuming that in production you have a <label> that is visible and is properly associated with your <input> then there is nothing you need to do here.
I have the following input on a site I'm currently reviewing:
<input type="submit" name="executeSearch" value="" alt="Execute search" title="Execute search" class="iconButton searchBtn">
Through the class attribut the input button is replaced by an search icon.
According to accessibility is this the right way? Or should the value attribute be used? The screenreader I tested this element with (NVDA) was able to read the text ("Execute search button").
An empty value and an icon added via CSS to convey the only important information is a failure according to WCAG 2.0: F3 - Failure (…) due to using CSS to include images that convey important information
Simplest solution: use an input[type="image"], keep that alt="Execute search" ("Search" would be more concise IMHO), add an src="/path/to/img" of course and remove both title and value attributes. Image can be an SVG and can be encoded in base64 (ideal when it's light for performance reasons: that's 1 resource not to be downloaded).
That [type="image"] seems outdated because it was widely used circa IE6, way before RWD but it isn't (proof of concept with an 8x16 viewBox and width*height SVG: it scales®)
Otherwise you can use a button element with type="submit". This element can contain SVG, HTML images, text hidden to screen readers (better known as .visually-hidden, .sr-only or .element-invisible in Bootstrap, WordPress, Drupal, etc). That's what I use when a "submit" has both text and image or icon because no :pseudo with input and text-only through #value
Some notes on your current markup:
#alt should only be used with input[type="image"]
#value shouldn't be used with type image and otherwise should never be empty
#title should only be there (on links and "buttons") if it adds something to the existing information (like Subscribe ⇒ Subscribe to the newsletter or Edit ⇒ Edit something in particular)
According to accessibility is this the right way? Or should the value attribute be used?
An input[type='submit'] button does not accept an alt attribute
Some screenreaders may use the title attribute, but it's still useful for non screenreader users
Using the value attribute is the recommended approach for screenreader users
So I decided I'd better make my little survey form generator accessibility compliant. Doing this for single multiple-choice questions presented no problem, whether they used radio buttons or checkboxes, since each multiple choice was itself the label. But what about when an array or panel of questions all have the same multiple choices?
For example:
I have this code:
<tr><td></td><td>Small</td><td>Medium</td><td>Large</td></tr>
<tr><td>3. What size Coke do you prefer?</td>
<td><label for="Q3.1"></label><input id="Q3.1" type="radio" name="responses[0]" value="1"></td>
<td><label for="Q3.2"></label><input id="Q3.2" type="radio" name="responses[0]" value="2"></td>
<td><label for="Q3.3"></label><input id="Q3.3" type="radio" name="responses[0]" value="3"></td></tr>
<tr><td>4. What size popcorn do you prefer?</td>
<td><label for="Q4.1"></label><input id="Q4.1" type="radio" name="responses[1]" value="1"></td>
<td><label for="Q4.2"></label><input id="Q4.2" type="radio" name="responses[1]" value="2"></td>
<td><label for="Q4.3"></label><input id="Q4.3" type="radio" name="responses[1]" value="3"></td></tr>
My questions:
1.- The W3.org validator passes the code as valid, but is it really "accessible?" Will a competent web page reader interpret this correctly to a visually impaired user?
2.- If not, is there a way to have some kind of hidden label that the reader reads but that is not visible to the eye?
3.- If not, is it design decision time, where you either have this type of question, or you have good accessibility, but not both?
No, it is not accessible. A label element with empty content is useless or worse. It is worse than useless when the user, when focused on a control, asks for the label of the control and the user agent supports the label element as intended. It will then announce an empty string as the label, adding to the user’s confusion. (Accessibility checkers perform very limited testing. Most of accessibility issues cannot be checked programmatically.)
There are several ways to provide a “hidden label”, but this would cover only some of the purposes of a real label. A user who has no problem with eyesight may need to know what a radio button means, e.g. due to a cognitive disability. A different approach is to use the aria-labelledby attribute. In this case, you would need to specify id attributes for the elements containing the texts “Small”, “Medium”, and “Large” and use each id attribute value in aria-labelledby attributes for the radio buttons. But support to this is rather limited; this attribute would help a small fraction of users only.
It’s a design decision where you primarily need to decide on the type of controls and overall setup. The problem vanishes if you use a select element instead of each set of radio buttons. This might be unacceptable to people who think that on-screen forms need to imitate paper forms, or for other reasons. The problem changes its type if you instead use a text input field, expecting the user to type S, M, or L. This would have the potential accessibility problem that the user might not remember what the alternatives are, even when they were explained at the start of the form.
Without retracting the answer I accepted, I'm adding an answer because I've since discovered additional information that more completely answers my question. The issue was what to do in the context of accessibility in the case where radio buttons did not each have their own label. How to add labels that a reader for the visually impaired will see but that the unaided human eye won't see? Reasonably enough, the answer was to use CSS to hide the label from the latter but not the former.
It turns out that w3.org has a section on its website called WCAG (Web Content Accessibility Guidelines), and there I found technique H65, "Using the title attribute to identify form controls when the label element cannot be used." It specifically mentions a survey form, and it recommends using the title attribute.
Example 4: A data table of form controls
A data table of form controls needs to associate each control with the column and row
headers for that cell. Without a title (or off-screen LABEL) it is difficult for non-
visual users to pause and interrogate for corresponding row/column header values using
their assistive technology while tabbing through the form.
For example, a survey form has four column headers in first row: Question, Agree,
Undecided, Disagree. Each following row contains a question and a radio button in each
cell corresponding to answer choice in the three columns. The title attribute for every
radio button is a concatenation of the answer choice (column header) and the text of the
question (row header) with a hyphen or colon as a separator.
http://www.w3.org/TR/WCAG20-TECHS/H65.html
Ok, I hope this helps somebody. I've had so many questions answered on StackOverflow not because I posted them but because some else had the same question!
Your labels have no content, so non-sighted users won't know what the inputs represent. I'd put the small, medium, large text in the relevant labels and then visually hide the labels. Use the offscreen or clip technique, so screenreader software will pick it up but sighted users won't have to see it repeated for every question.
What you have done is fine.
You can make an input that has a value of hidden. Though I don't know what you meant by not seen by the eye.
<input type="hidden" value="whatever">
This can be seen by the server though not the user.
I read from this site [Site]: http://msdn.microsoft.com/en-us/library/windows/apps/hh968006.aspx
that aria-multiline is to provide the multi line attribute.
But when i applied to textbox, it doesn't seem to work. Can anyone please tell why. I have one more question, can anyone please tell me the difference between these two elements
<textarea rows="4" cols="50" id="text"></textarea>
<textarea rows="4" cols="50" aria-labelledby="aria-text-label" id="aria-text" role="textbox" aria-multiline="true"></textarea>
Thanks
ARIA attributes are declarative (informative). They inform browsers and especially assistive software what functional properties elements have, mainly due to JavaScript code that processes them, instead of making elements have functional properties. For example, if you used JavaScript to make a div element a multi-line input area, it would be appropriate to set aria-multiline="true" on that element. See the W3C WAI Primer.
Thus, the attribute is redundant for textarea (browsers can be expected to know what that element is). For input type="text" it could be used, but only if you have somehow managed to turn it to a multiline control.
The differences between the two elements presented in the question are:
They assign different id attribute values.
The latter declares a role attribute, which matches the default semantics and is not recommended in Using WAI-ARIA in HTML. (It is allowed, but it may confuse people who read the HTML source and mislead them into thinking that it has some effect.)
It also redundantly declares the element as multiline.
It additionally specifies that the element has a label, which is an element with id="aria-text-label". This is not redundant, but it is normally better, more accessible, to have the label declared in normal HTML markup, using the label element.
Have you read Remarks part of your link? Since textarea is multiline by default, so setting aria-multiline="true" will have no efect. This attribute sets what ENTER key do. In textarea and when aria-multiline="true" it will continue input to second row. But if you set aria-multiline="false" for textarea, it will act as <input type="text"/> - it will submit form on Enter key press and will not jump to second row.