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
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.
<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)
<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.)