Tag Archives: validate forms

A third way to write and validate forms – HTML5

After writing an accessible form in XHTML and validating it with a PHP server side script & after that with a Mootools client-side script, I write today about a third way of approaching the subject – using future-to-come HTML5 (by saying that, I really hope to be able to use it waaaay before 2011).

The beauty consists in having all the above mentioned validation inside HTML code:  we’ll have

  • input type=”email” for email addresses
  • type=”url” for urls
  • type=”date” and “datetime” for date fields (usually done with JS calendars until now), or “month”, “week”, “time”
  • type=”number”  for number only inputs
  • accessible sliders, with type=”range”
  • datalists
  • ability to add extra validation conditions after writing the tag, like: required, read-only,disabled, autofocus, a minimum value, a maximum accepted value/length

The code for our simple contact form will be much lighter:

<form action="index.php" method="post" name="contactform" id="contact">
<label for="name">Name <span>(required)</span></label>
<input  tabindex="1" type="text" name="name" id="name" required />
<label for="mail">Email <span>(required)</span></label>
<input  tabindex="2" type="email" name="mail" id="mail" required />
<label for="phone">Telephone</label>
<input tabindex="3" type="text" name="phone" id="phone" />
<label for="message">Message</label>
<textarea tabindex="4" cols="30" rows="10" name="message" id="message"></textarea>
<button tabindex="5" type="submit" name="submit" id="send">Submit</button>

The result will be a much easier way of writing and validating forms in an accessible manner, without adding extra load/code with PHP/JS scripts. All you have to do is place “required” to all the required fields and use the above mentioned minimum value, maximum accepted value, etc to control the user’s input.

The entire list of types and useful tables with the methods that apply to each state can be found on W3C site

The problem right now is the inabilityof the browsers to work with lots of HTML5 features. And the future does not look good either. So far the only browser that supports the new forms is Opera 9.5+.  Internet Explorer 8 and below is not compatible and IE9 probably won’t be either (we’re talking about 2010).  Chrome 2+, Safari 4+ will partially support some features while Mozilla won’t do it even in its 4.0 version (due to launch in 2010).

Now, the same contact form we used to play with, but written in HTML5, will look the same but behave much more nicely (the code is lighter too). It’s saving us a lot of time and headaches and it’s much more user friendly.  Play with the new example – in Opera 9.5+ – and drop us a feedback if you consider that the subject is interesting enough to come back with more code-examples.

Check the Spanish version of this post:
Una tercera manera de escribir y validar formularios – HTML5

Basic copy-paste accessible contact form

A good way to learn about accessibility is through examples and discussions. In this post I will try to translate the WCAG sometimes-hard-to-get rules into a copy-paste real contact form example.  You can check the test link, download the code and/or keep reading a bit more.

As I mentioned before, contact forms are in great need of special markup in order to be accessible. And it seems that there’s always room for improvements – in case you have suggestions or your approach is different,  I’d love to hear from you.

My suggestion is a simple 4 fields contact form with PHP server side validation. After the user submits the required information the page is reloaded and new messages are displayed depending on the user actions.  Of course you all know that the form needs

<label for="name">

tag and some sort of validation – everybody is writing about the need to display in an accesible way which fields are required and also the error messages (usually indicating the missing fields)  – but few actually offer a simple straightforward code to copy-paste in our sites.

The stylesheet is very light – we have to style the form – but the novelty is a class for the fields that are required and not yet filled. This way after we validate we return the error message with links to the missing fields but we also hightlight them for a more usable and intuitive experience. The PHP part is reading the inputs, checks them and sees if the required ones were filled.  A thank you message is displayed in case the user filled all the required fields.

The number of fields can easily be increased but don’t forget to validate them -when someone understands how the form works and which were the accessibility elements that were included then buiding more complex forms becomes just a matter of typing.

Check the Spanish version of this post:
Un básico copia y pega de un formulario de contacto accesible