hello
i have form with input field
i dont have in my design Enough place to put labels
does placeholder html5 is sufficient for screenreader or is placeholder is problem
and if i poot placeholder and title as attributs the screen reader will read the both the value so it will confuse
the listener
another questions about forms
if i have long form is the best place for list of errors is in the top of the form?
thanks for detailed answer
Hi,
It depends on the screen reader, some will read out a placeholder when you’re focussed on the input, some won’t, but screen readers are easy to fix: you can always have a linked label (with a for attribute matching the input’s id) simply pulled off-screen with css (like a negative margin). Screen readers aren’t your worry here (and when I have placeholders, I always have a label, even if it’s hidden. Sucks to have the placeholder repeat the label but in my case, I’m adding a label where someone else decided to incorrectly use the placeholder as a label).
and if i poot placeholder and title as attributs the screen reader will read the both the value so it will confuse
the listener
Maybe, depends on the reader. Titles are often not read out, though for some of the more popular older readers like JAWS, title was/is read out specifically on form inputs. If the browser and reader both support placeholder, then yeah they might hear the stuff twice. I only like title as a real last resort in my form inputs, since I can almost always have off-screen labels somewhere.
Some readers (like my copies of JAWS) would repeat the legend of the fieldset before each radio/checkbox input and label, which was also kinda annoying. Sometimes it’s a reader bug, sometimes it’s a browser bug, sometimes your HTML sucks. I hope my info below helps you avoid the latter. There’s not a whole lot you can do about the other two.
Beyond screen readers, there’s a boatload of [url=http://www.webaxe.org/placeholder-attribute-is-not-a-label/]usability/accessibility [url=http://www.uxmatters.com/mt/archives/2010/03/dont-put-hints-inside-text-boxes-in-web-forms.php]studies showing problems with replacing labels with placeholders (also, even the [url=http://www.w3.org/html/wg/drafts/html/master/forms.html#the-placeholder-attribute] HTML specs spell out that placeholders are for hints to users, like formats they should use, and are not replacements for labels).
They’re more of a usability issue, where people are shown repeatedly empying fields (especially after getting a form back with errors) to see what the label requests. There are pretty much only two places you can honestly probably get away with no real labels: username/email + password login forms, and search inputs (especially if the button text for the form confirms with stuff like “Search” or “Log in”).
if i have long form is the best place for list of errors is in the top of the form?
I dunno if it’s the best place, but I’ve put them there, and so have others. It’s a logical place, if a form error results in a new page or a page refresh: these bring users and browsers back to the top of the page, and anyone surfing a page linearly (maybe with a screen reader, text browser, whatever) should get a
-title <title> of the page stating the form wasn’t successful
-h1 or main heading <h#> saying the same thing: form didn’t succeed
-statement of what specifically is the problem (this could be a good place for list of errors, and you can make this a real list of anchors skipping to problem inputs for quicker keyboarding too!)
Try this page: http://www.scooterverzekeren.com/direct-afsluiten/formulier and just scroll down and hit the submit button. The error messages aren’t good, but it’s an example of linked error messages for easier keyboarding.
If the errors are being generated front-end, like by Javascript, then it’s probably better to show the errors the moment the user makes them. I don’t mind being told I f*cked up an input while filling a form out, so long as that message only comes after I’ve tabbed away (when I onblur, then I’m probably done with my answer). Some forms move the focus back to the problem input right away-- I wouldn’t do that. Sometimes it makes a keyboard trap: you can’t get away from the input so long as some Javascript thinks the answer is wrong. But you can highlight it with CSS, or place a generated error message next to or after the input.
If you’re generating messages around inputs with Javascript and are wondering about screen readers: those screen readers who don’t use a virtual buffer, like Linux’ Orca or Apple’s VoiceOver should be able to access the messages, at least if they are after the input (inserting something before it, I can imagine getting missed by users). However buffered readers like JAWS, Window-Eyes and NVDA make a copy (buffer) which the user interacts with when filling out forms or reading stuff. For this and other reasons, I do like good error messages after someone hits Submit. But in the meantime, for newer browsers and newer screen readers (yeah, the browser matters too) you can link your error messages using ARIA-*.
Example:
<label for=“city”>City: </label>
<input type=“text” name=“tehCity” id=“city” value=“”>
(let’s say your JS is matching city names with postal codes. Something stupid I made up for an example)
Post-error (you can insert these with Javascript):
<label for=“city”>City: </label>
<input type=“text” name=“tehCity” id=“city” value=“LOLWUT” aria-labelledby=“cityError”>
<p id=“cityError”>This city doesn’t match the postcode you listed</p>
(Another usability hint: try to not tell people they’re wrong and they suck; just say factually that something doesn’t match, or “whoops, sorry, x went wrong, try y” type messages. After all, they’re filling out these forms for YOU, so they’re doing YOU the favour. Plus even rocket surgeons turn stupid behind computers. We should be nice.)
Here is some more definitive stuff on placeholders:
Placeholder labeling and browsers
http://www.w3.org/html/wg/drafts/html/master/forms.html#the-placeholder-attribute <– I linked to this earlier, but someone’s added a Note there in a coloured box.
There was a recent thread that had a useful idea about placing labels when space was tight and I quite liked this approach.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Untitled Document</title>
<style type="text/css">
input, select, textarea {
border: 1px solid #DD6D00;
color: #4A138A;
font-family: Tahoma, Geneva, sans-serif;
font-weight: bold;
padding: 10px 5px;
width:150px;
-moz-box-sizing:border-box;
-webkit-box-sizing:border-box;
box-sizing:border-box;
display:block;
margin:0;
clear:both;
}
.form1 div {
display:inline-block;
*display:inline;
zoom:1.0;
margin:0 10px 10px 0;
}
.form1 label {
float:left;
background:#fff;
padding:0 5px;
font-size:80%;
margin:0 0 -.5em .5em;
line-height:1.0;
position:relative;
}
</style>
</head>
<body>
<form>
<fieldset class="form1">
<legend>Label test </legend>
<div>
<label for="first_name">First name *</label>
<input type="text" class="required input" value="" id="first_name" name="first_name">
</div>
<div>
<label for="last_name">Last name *</label>
<input type="text" class="required input" value="" id="last_name" name="last_name">
</div>
<div>
<label for="addr1">Address *</label>
<input type="text" class="required input" value="" id="addr1" name="addr1">
</div>
</fieldset>
</form>
</body>
</html>
It does of course depend on the design in hand but can be useful where space is tight.
As Stomme said above the placeholder should never be used a substitute for the label and indeed users in IE8 and under will have no clue what to enter if you have no labels (and no value attribute) so adding and hiding labels may help screen readers but won’t help normal users on those browsers.