SitePoint.com

Avebury · Jul 17, 2003, 06:24

Hi

I have built a site in Dreamweaver MX and have a members login page. Under Priority 3 Accessibility, if I insert a place-holding character in the text area, it passes, and if I remove these place-holders, it fails. However, my password text area displays ****** before the user inserts there password, but when they tab to this box, the ****** does not highlight and delete, it just adds to the users password, obviously failing on login.

How can this be accessible when the user would have to physically delete the ****** before being able to login. Am I do something wrong or is there a way around this?

http://www.learningcurve.org.uk/login.php

Regards

vgarcia · Jul 17, 2003, 07:51

I wouldn't think that a default value in a password field would be more helpful, usable, or accessible (other than maybe letting you know that it is a password field, since the contents will be masked).

Paul_C · Jul 17, 2003, 08:46

The whole idea of putting place-holding characters in form fields was because some bass-ackwards screen readers wouldn't know the field was there if it was empty. These are the NS4 of screenreaders.

In reality using placeholder text makes your forms less accessible because screenreaders will tell you a form is there and immediately start reading the text in it (leaving you wondering what happened to the form you just had) and deleting all the placeholder text can be a real pain in the *** for mobility impaired people.

I'd sacrifice catering to broken software for people who step up to the plate with real tools any day. Some people will disagree, but that's my take on it.

Avebury · Jul 17, 2003, 12:11

Thanks

I think I will leave them blank until I hear back from Bobby/Watchfire.

Webnauts · Jul 17, 2003, 23:40

Some problems I found on your page:

GENERAL

1. In XHTML documents, style and script content should not be in a comment because it technically means that the browser will see it as a comment and not as actual style or script content (though browsers are currently forgiving about this). However, not using comments makes your document less compatible with pre HTML 3.2 browsers (but most browsers in use now are HTML 3.2+ compatible). For maximum compatibility, I recommend putting the script (especially longer scripts) in an external file and using the "src" attribute to specify the external file. The next best option for XHTML documents would be to not put the script content in a comment and to disregard pre HTML 3.2 browsers.

2. "onFocus" contains uppercase characters. All open tags, end tags, and tag attributes must be in lowercase because this is an XHTML document.

3. The "input" tag must be closed by adding a slash to the end of the tag (<input ... />) or by a separate end tag (</input>).

ACCESSIBILITY

Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user [P2, 10.1]. Avoid specifying target="_blank" because spawning a new window can be confusing and disorienting to the user. If a new window must be spawned, it is recommended that it be indicated in the link description, such as by adding "(new window)" to the link description.

Here is a great freeware for building accessible forms: http://www.hisoftware.com/access/valueadd9.html

redux · Jul 18, 2003, 05:51

Quote:

Originally Posted by Avebury

Hi

I have built a site in Dreamweaver MX and have a members login page. Under Priority 3 Accessibility, if I insert a place-holding character in the text area, it passes, and if I remove these place-holders, it fails. However, my password text area displays ****** before the user inserts there password, but when they tab to this box, the ****** does not highlight and delete, it just adds to the users password, obviously failing on login.

How can this be accessible when the user would have to physically delete the ****** before being able to login. Am I do something wrong or is there a way around this?

http://www.learningcurve.org.uk/login.php

Regards

ok, this has been discussed before, and answers have already been partially given in this thread. nevertheless, let's see...

the requirement to provide placeholder text is a technical one, to cater for old browsers which can completely ignore a form input if there is no default content in it. it does not, however, benefit users, as they have to delete the text first. sure, js methods are out there to wipe the inputs onfocus, but there obviously don't work when js is not present or disabled (e.g. under lynx, it's a pain).

a method i've used that fulfills the technical requirement AND does not get too much in the way of the user: use a single space character as placeholder text (and, if necessary, strip any leading spaces from form inputs when you receive the form data)...job done.

xhtmlcoder · Jul 22, 2003, 08:22

Well, at least we won't have "Until user Agents…" statement within Web Content Accessibility Guidelines 2.0 when it hits the road

.

Jul 17, 2003, 06:24	#1
Avebury SitePoint Member Join Date: Apr 2003 Location: Wiltshire England Posts: 9	Accessible Forms Hi I have built a site in Dreamweaver MX and have a members login page. Under Priority 3 Accessibility, if I insert a place-holding character in the text area, it passes, and if I remove these place-holders, it fails. However, my password text area displays **** before the user inserts there password, but when they tab to this box, the ** does not highlight and delete, it just adds to the users password, obviously failing on login. How can this be accessible when the user would have to physically delete the **** before being able to login. Am I do something wrong or is there a way around this? http://www.learningcurve.org.uk/login.php Regards

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Jul 17, 2003, 07:51	#2
vgarcia ☆★☆★ Join Date: Jan 2002 Location: in transition Posts: 21,481	I wouldn't think that a default value in a password field would be more helpful, usable, or accessible (other than maybe letting you know that it is a password field, since the contents will be masked).

Jul 17, 2003, 08:46	#3
Paul_C Rabble Rouser Join Date: Jan 2003 Location: Mountain View, CA Posts: 431	The whole idea of putting place-holding characters in form fields was because some bass-ackwards screen readers wouldn't know the field was there if it was empty. These are the NS4 of screenreaders. In reality using placeholder text makes your forms less accessible because screenreaders will tell you a form is there and immediately start reading the text in it (leaving you wondering what happened to the form you just had) and deleting all the placeholder text can be a real pain in the *** for mobility impaired people. I'd sacrifice catering to broken software for people who step up to the plate with real tools any day. Some people will disagree, but that's my take on it.

Jul 17, 2003, 12:11	#4
Avebury SitePoint Member Join Date: Apr 2003 Location: Wiltshire England Posts: 9	Thanks I think I will leave them blank until I hear back from Bobby/Watchfire.

Jul 17, 2003, 23:40	#5
Webnauts Organic SEO Expert Join Date: Jun 2003 Location: European Union Posts: 1,577	Some problems I found on your page: GENERAL 1. In XHTML documents, style and script content should not be in a comment because it technically means that the browser will see it as a comment and not as actual style or script content (though browsers are currently forgiving about this). However, not using comments makes your document less compatible with pre HTML 3.2 browsers (but most browsers in use now are HTML 3.2+ compatible). For maximum compatibility, I recommend putting the script (especially longer scripts) in an external file and using the "src" attribute to specify the external file. The next best option for XHTML documents would be to not put the script content in a comment and to disregard pre HTML 3.2 browsers. 2. "onFocus" contains uppercase characters. All open tags, end tags, and tag attributes must be in lowercase because this is an XHTML document. 3. The "input" tag must be closed by adding a slash to the end of the tag (<input ... />) or by a separate end tag (</input>). ACCESSIBILITY Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user [P2, 10.1]. Avoid specifying target="_blank" because spawning a new window can be confusing and disorienting to the user. If a new window must be spawned, it is recommended that it be indicated in the link description, such as by adding "(new window)" to the link description. Here is a great freeware for building accessible forms: http://www.hisoftware.com/access/valueadd9.html

Jul 22, 2003, 08:22	#7
xhtmlcoder Robert Wellock Join Date: Apr 2002 Location: A Maze of Twisty Little Passages Posts: 1,862	Well, at least we won't have "Until user Agents…" statement within Web Content Accessibility Guidelines 2.0 when it hits the road .