You have a form — a contact form, for example — that you want to put some accessible error checking into. Examples of common problems include e-mail addresses which are not valid, or a name field which does not contain at least a first name or a surname.
First, please read about the
aria-required technique if you have not done so, as this technique expands upon that.
Here is a simple form:
<form method="post" action="post.php"> <fieldset> <legend>Please enter your contact details</legend> <label for="name">Your name (required):</label> <input name="name" id="name" aria-required="true"/> <br /> <label for="email">E-Mail address (required):</label> <input name="email" id="email" aria-required="true"/> <br /> <label for="website">Website (optional):</label> <input name="website" id="website"/> </fieldset> <label for="message">Please enter your message (required):</label> <br /> <textarea name="message" id="message" rows="5" cols="80" aria-required="true"></textarea> <br /> <input type="submit" name="submit" value="Send message"/> <input type="reset" name="reset" value="Reset form"/> </form>
Form validations consists of several steps:
- Checking if the e-mail address or entered name are valid. Each field has a set of criteria which must be met in order to pass validation. In order to simplify this example, we’ll check whether the e-mail address contains the “@” symbol, and if the name entry contains at least 1 character.
- If the above criteria is not met, the field’s
aria-invalidattribute will be given a value of “
alert’ function, we’ll use a simple WAI-ARIA widget for notification. This notifies the user of the error, but allows for them continue modifying the form without losing focus (caused by the “
checkValidity function. This method takes three parameters: The ID of the
input that is to be validated, the term to search for to ensure validity, and the error message to be inserted into the alert.
To see if it is valid, the function checks whether the
input’s value is anything greater than
-1. A value of
-1 or less is returned if the index of the search term could not be found within the value.
If invalid, the function does two things:
- It sets the element’s
aria-invalidattribute to “
true”, which will indicate to screen readers that there is invalid content in here.
- It will call the
addAlertfunction to add the alert with the provided error message.
If the search term is found, the
aria-invalid attribute is reset to “
false”. In addition, any leftover alerts are removed.
This function first removes any old alerts. The function is simple: It looks for an element with id “
alert”, and if found, removes that from the document object model.
Next, the function creates a
div element to hold the alert text. It gets an ID of “
alert”. And it gets a role set of “alert”. This is actually ARIA-inspired, even though it doesn’t say “aria” in the attribute name. This is because that role is based on the XHTML Role Attribute Module that was ported to HTML for simplicity.
The text is added to the
div element, and the
div element is added to the document.
The moment this happens, Firefox will fire an “alert” event to assistive technologies when this
div appears. Most screen readers will pick this one up automatically and speak it. This is similar to the Notification Bar in Firefox that prompts you whether you want to save a password. The alert we just created does not have any buttons to press, it just tells us what’s wrong.
All that’s left now is add the event handler. We need to change the two inputs for e-mail and name for this:
<input name="name" id="name" aria-required="true" onblur="checkValidity('name', ' ', 'Invalid name entered!');"/> <br /> <input name="email" id="email" aria-required="true" onblur="checkValidity('email', '@', 'Invalid e-mail address');"/>
Testing the example
If you use Firefox 3 and a currently-supported screen reader, try the following:
- Enter only your first name as the name. When tabbing, you’ll hear an alert that tells you you’ve entered an invalid name. You can then shift-tab back and correct the error.
- Enter an e-mail address without the “@” symbol. When tabbing out of this field, you should hear a warning that says you didn’t enter a valid e-mail address.
In both cases, when returning focus to the field in question, your screen reader should tell you that this field is invalid. JAWS 9 supports this, but JAWS 8 does not, so this may not work in all versions of the screen readers supported.
- Q. Why did you put both “
(required)” in the label text and the
aria-requiredattribute on some of the inputs?
- A. If this were a real live form, and the site was being visited by a browser that does not yet support ARIA, we’d still want to give an indication that this is a required field.
- Q. Why don’t you set focus back to the invalid field automatically?
- A. Because this is not allowed by the Windows API specs, and possibly others. Also, letting the focus jump around without real user interaction too often is not a nice thing to do in general.