An area of web development that I previously had little exposure to was WCAG validation. This is the industry standard for Accessibility coding for web platforms. For version two (V2) of the WCAG there are three standards, A, AA and triple A (AAA). Each represents different levels of Accessible compatibility.

What this also does is validate against the W3C doctype standards. This is where my problems arose. The main aim of the doctype standard is to clearly define a separation layer between content and behaviour. In practical terms this equates to best practices such as having an external .CSS files rather than inline styling, and declaring the language types for scripting, such as JavaScript etc.

Using a free online tool, http://www.totalvalidator.com/ you can check if your site is W3C and WCAG complaint. It will base the validation on the doctype declared in your html. There are three types of DTD declaration for html 4.01.

You can read more about Doctypes here: http://www.w3schools.com/tags/tag_DOCTYPE.asp

The main difference between these is that the frameset DTD will accept frameset as valid html, whereas the others will not. Also the Strict DTD imposes a very tight restriction of what is accepted as valid in comparison to the Transitional DTD. One is a Strict adherance to the standard, whereas the other shows that you are Transitioning from old code into the new.

The site http://24ways.org/2005/transitional-vs-strict-markup goes into more detail about what the exact differences are, what I am going to discuss is the option of creating functional hacks, merely to pass validation.

One of the deprecated attributes in Strict validation is the target attribute.

We are all familiar with this attribute, but when you examine it you find that it is actually a declaration of behaviour. We are forcing the user into a specific action. IE open a new window. As a best practice guideline whenever we have a link on a site that exits that site, we open a new window. The only work around for this is creating a specific JavaScript function to open a new window, as this will not be marked as invalid. This seems overkill, just to pass validation.

So I am left with the dilemma that if I want my sites to pass Strict DTD validation I must create a JavaScript hack, or compromise the functionality. I'd like to pass the validation, but I view the functionality as key to a site, so it's an easy decision for me.

One of the ideas that we have been throwing around the office is creating a platform that will create the form-validation-database cycle automatically. Something akin to ORM, but not. ORM looks good, but we want more control over what is happening.

In this article I am exploring the idea of automatically creating JQuery validation from a simple Coldfusion input. In this case a list of required fields. I'll say up front Ray Camden's blog entry on Jquery Validation (http://www.coldfusionjedi.com/index.cfm/2009/2/10/An-Introduction-to-jQuery-and-Form-Validation-2) has been an invaluable help.

The principle behind this is that you can create a generic validation object routine, and simple provide it with a set data object (list or struct, haven't decided yet) and have it match against a form and validate it. So with that in mind we will create a simple form.

As you can see from above, this is a simple form. Next we will include references to the Google code repository for the AJAX library, and out JQuery validation plugin. Next we have the JQuery script to validate our fields. Firstly we create a list of the fields that are required. By doing this it is incredibly easy to add another required field to the model. The next phase of this will probably accept a structure rather than a list, in that way I can combine field lengths and any other custom criteria, rather than merely the fact that it is required. The JQuery validation starts off in exactly the same way as usual, we create a function to catch the validation request, and use the id of the form as the reference. We declare the error container style of "#error". Next we loop over our list inside the "rules:" element. This creates the required rules for each field. I've also added a basic check for the value 'email'. This will create an email validation rule. Next we create custom messages in the "message:" element. Again this catches the email value and adds an appropriate message. Lastly we can create a style for the #error container we declared above.

This creates a totally dynamic validation routine - all fed from a list. I think it forms a good basis to build a more dynamic rules driven model, where you can set field lengths as well.

There is an example of the complete code here, along with a variation on the inline or external placing of the validation messages.

Follow this link for a demo of the JQuery validation model.

There are several sites available detailing how to embed SWF Object's into your sites. By far the most reliable, and cross browser compatible without writing any form of Internet Explorer / Firefox hack is the SWF Object javascript plugin.

Adobe have a Developer Connection article detailing how the SWF Object javascript plugin works, http://www.adobe.com/devnet/flashplayer/articles/swfobject.html but it is six pages long, and seems to avoid any direct example of the most straight forward method of implementation. I am sure that it is all encompassing, but I was looking for a quick bullet point style guide.

So here it is:

1. Include the call to the Swobject Javascript library, don't host this yourself, just link directly to Google's code base.

2. Setup the flash variable scopes, this ensures that they exist, and it is a handly place to set global variables for your flash. I normally include this in the header of my frameworks.

3. Setup a div for your flashcontent. This is what will be displayed if you are not flash enabled. Ensure that your "No Flash content" either closely represents the actual flash content, or signifies a link to getting Adobe flash in some way.

At thsi point the "No Flash" content will be displayed on screen.

4. Lastly include the script to switch out the "No Flash content" with the actual flash.

This Javascript will over right the div (by id) and insert the flash object into it. Supply the path, the div ID to replace the content for, followed by the height and width values. Next is the Flash player version (set it to a higher number than the Flash player version for Non flash content testing). Next you include the variables scopes you created in stage 2, passing in any other values your flash content is expecting.

If everything is running correctly you can now see your flash content. Simply change the flashplayer value, 9 above, to something higher, for example 20 to see the non flash content.