is CFForm (html) accessible

[miki]

Hey all

I was sure i posted this last week but apparently i never clicked submit (duh)

for aeons we have been writing our own JS validation for form fields because use of CFFORM (html)/CFINPUT for basic input types did not produce HTML that was accessible and therefore we could not meet government contact requirements unless we coded a whole other page with all that JS anyway.  However, i won't even say how many years have passed, and versions come since we determined that, and well, i'd kinda like to revisit it because i HATE validating with JS with a passion. 

So, for those of you who do goverment sites, do any of you use CFFORM(html) and CFINPUT and get accessible HTML out of it?  If so, what level? (we NEED to meet section 508, but would like to use W3C accessible 1 or 2 if we can)

[DLewey]

We use HMTL 4.01 Strict and we would like to use cfform tags to validate our data but from my experience with they cause too much problems passing our page validate requirements. The two things that i have found is that i still have to use JS for valiadate the data or there are some occations where I will submit the data and then validate it on the very next page. There reason i use this process is because i can't us js to validate a form if the person has scripts disabled. Resulting in the need to valiadate the information on form submit anyways.   About all I use JS for in validation is to make sure that there is something in the input box not the format of the data.

I don't know about other document types.

[Guest]

I'd suggest using multiple layers.

- JS validation on the form, to enhance the user experience without requiring a refresh

- Server side validation after the form is submitted, to validate data in the instance the user has JS disabled.

- Redirect back to form and repopulate non-hidden fields (on server side failure, so the non JS user does not have to repopulate all fields.

Always do the server side validation, there will be instances where browsers do strange things and by-pass JS validation or don't act as expected on the client.  Chrome is one I've noticed from time to time with Ajax, it will do strange things with caching user input.

Server side validation is the best way to validate what is getting to your application and being most secure.

Byron Mann

mannb@hostmysite.com

byronosity@gmail.com

Software Architect

hosting.com | hostmysite.com

http://www.hostmysite.com/?utm_source=bb

[miki]

I'm not sure what these posts have to do with form accessibility although it could be argued that they do speak to 'what to do when the users turn off JS' so i did some research.  I was just really surprised nobody could already answer this.

I took an accessible form and printed the source, then i took that form and replced it with cfinputs, cfselects, cfform etc and viewed the source..finally i did a line by line comparison of the two pages.  It was identical.  So if i use cfform/cfinput with type="html" there is no reason why the form itself would not be accessible.

Our system has a requirement for realtime validation.  We expect to use both client and server validation for the exact reasons listed in the followups above.  Therefore, in case anybody is looking specifically to see if cfform type html generates accessible html the answer is "Yes, just remember to validate on the server as well as the client"