Accessible Client-side Form Validation with HTML5 & WAI-ARIA

Share on FacebookShare on LinkedInShare on Twitter

W3C WAI-ARIA badge & screenshot of form with the text (required) colored red and placed in the labels of the required fields.Happy face rage guy with tears of joy accessibility blog


WAI-ARIA is WAY COOL! In part two of the three-part series on accessible form validation and usability enhancements we're going to use WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) to communicate information to screen reader users only.

Demo Form with HTML5 & WAI-ARIA Validation

Limitations of ARIA

ARIA only works on some of the latest screen readers and browsers. It does not work with all AT (Assistive Technologies). There is no support for speech recognition software such as Dragon NaturallySpeaking. Window-Eyes and ZoomText have limited support.

Derek Featherstone (@feather) has an excellent blog post on A List Apart titled ARIA and Progressive Enhancement where he documents ARIA support on Window Eyes & ZoomText. There are also good ARIA coding techniques and live form examples.

Enhancing Forms with ARIA

Screenshot of a form that only indicates required fields by coloring their labels red. A big red circle with a line through it is placed over the screenshot.Are you kidding me meme face accessibility blog

Sometimes developers use color alone to alert users that required fields are not filled. DON'T DO THIS! What you should do to indicate a required field is to place text in the label that says so. Many times you see a red * or the text (required) placed in the label. This is the recommended approach. Other recommendations involve creating a star graphic and placing it in the label with alt="Required". This works as well but it is buggy in OS X Lion where the alt attribute is not announced in a label.

NVDA Symbol Pronunciation settings showing changing the * symbol who's replacement text is star to the level of some.By default NVDA will not speak an asterisk * as "star". VoiceOver & JAWS both say "star". NVDA users can adjust their Symbol Pronunciation settings to force * to be spoken by setting the Level to "some" but not all users are aware of this feature and will usually be running on default settings. By placing the aria-required="true" attribute on all required fields NVDA will now announce they are required at the default settings. VoiceOver and JAWS will speak the star and the required attribute.


The easiest enhancement is to add the aria-required="true" attribute to all required fields in your form.


Below is a screenshot of the VoiceOver Caption Panel on OS X Lion which provides an excellent way to visualize ARIA/screen reader output if you're deaf or hard of hearing or don't want to annoy others in the room with your computer speaking everything out loud. I think it would be cool if iOS could do this as well!

Label reads: First Name *, VO output speaks: First Name * required edit text

Don't worry about having the HTML5 required attribute and the aria-required="true" attribute and causing repetition. All the screen readers I've tested only speak required once. Here aria-required is your fallback for browsers who do not support HTML5 like Internet Explorer. This way screen readers which support ARIA will speak the ARIA attribute when used with IE and ignore the HTML5 attribute.

ARIA Techniques for WCAG 2.0

ARIA2: Identifying required fields with the aria-required property

WAI-ARIA 1.0 Authoring Practices

Use aria-invalid and aria-required To Improve Access to Forms

Other ARIAs for Consideration

aria-invalid="true" role="alert"

Marco Zehe (@MarcoInEnglish) from Mozilla wrote a post called Easy ARIA tip #3: aria-invalid and role "alert" which recommends setting aria-invalid="true" on fields with errors and creating a div with a role="alert" to hold the error messages. Since this involves JavaScript to inject the ARIA attributes I'll save this experiment for the next post.


rage guy accessibility blogHow do assistive technology users navigate forms? Do they tab through the inputs like I do to quickly fill the fields out with the keyboard? Do they use their arrow keys to go down through the fields and the text between the fields? Or do they use other screen reader shortcuts like the F key for form fields?

In most of my experience testing forms and receiving feedback from others in the industry, tabbing through forms is the most popular interaction method. This is why I recommend placing all instructions and errors in the labels. As the user tabs through they would hear all instructions spoken by a screen reader.

What if the instructions to complete a form field are just really long and you'd rather not include them all in the field's label? Well if the user's AT & Browser have support for ARIA you could instead include those long instructions above or below the field and then point to them with the aria-describedby attribute causing the supported screen reader to speak those instructions after the label.

ARIA Techniques for WCAG 2.0

ARIA1: Using the aria-describedby property to provide a descriptive label for input controls


If you are using explicit labels and aria-describedby then there should not be many reasons to need to use aria-labelledby on form fields. Marco Zehe has a good example of where aria-labelledby could be useful on forms. Easy ARIA tip #2: aria-labelledby and aria-describedby. The example illustrates a problem where a text input field might be placed in the middle of a sentence but it needs to be labelled by the first part of the sentence, the input's value itself, and the final part of the sentence.

VoiceOver output of Marco's aria-labelledby example. VO reads: 10 contents selected Shutdown computer after 10 minutes Allows you to specify the number of minutes of inactivity after which your computer should shut down. edit text


aria-label is meant to be used in cases where a text label is not visible on the screen and a visual tooltip is not desired like when using the title attribute.

In the second version of the ARIA demo form I've used the aria-describedby attribute as a replacement for placing input formatting instructions in the label and positioning it below the form field with CSS. Instead of using visually hidden labels with CSS I used the aria-label attribute to label inputs that do not need a visual label like when a phone number is split into three fields.

Final Thoughts on These Other ARIAs

In these other ARIAs for consideration I've only been talking about their usage on forms, however, they are many times meant to be used to label and describe "desktop-like" HTML widgets that have been built using non-form tags such as divs and list tags. For more information read: Using the aria-labelledby attribute & Using the aria-describedby attribute from the Mozilla Developer Network.

Demo Form with HTML5 & WAI-ARIA Validation

Demo Form 2 with HTML5 & WAI-ARIA Validation

Last Steps - Add jQuery Validation

In the last blog post we'll add the final layer of client-side form validation using the jQuery Validation Plugin and tweaking its settings to maximize the accessibility and usability of our form for all users on all devices. It will even work for IE 6!

Links to all three posts in this series:

  1. Accessible Client-side Form Validation with HTML5
  2. Accessible Client-side Form Validation with HTML5 & WAI-ARIA
  3. Accessible Client-side Form Validation with HTML5, WAI-ARIA, & the jQuery Validation Plugin

Comments? Questions?

accessibility blog computer guy

So what do you think about these WAI-ARIA form enhancements? Would you take the approach a different way?

Do you think all instructions, cues, input formatting requirements should be placed in the label? Or would that make the labels too big so longer instructions should be in adjacent text and pointed to with aria-describedby?

Would you rather just add tabindex="0" to the instructions to put them in the default tab order and keep the labels as small as possible? Are you a big fan of the title attribute and would rather put everything in there instead of using ARIA?

A lot of forms accessibility practices are up for interpretation and debate so I'd love to hear your thoughts and feedback in the comments!

Let me know if you have any suggestions for improvement or find any mistakes. Leave a comment below or send me a message on Twitter @pauljadam.


Development Newsletter Sign-up Button


Paul J. Adam is a former Accessibility Evangelist for Deque Systems. His focus is on Mobile Accessibility and Modern Web Accessibility, with expertise in Mobile Web, Native iOS & Android, Hybrid Apps, Responsive Web Design, HTML5, JavaScript, WAI-ARIA, WCAG 2.0, and Modern Web development techniques. Paul’s been a registered Apple Developer since 2011, and spends his free time creating iOS apps and learning modern JavaScript development.


  • imanu Permalink

    I notice the use of required & aria-required attrs on input type submit button, at the end of form.

    Is that a copy/paste error or is there any good reason to do it ?

  • Notes On Client-Rendered Accessibility | Kyle W Krenik Permalink

    […] For more information on accessible client-side validation, read Marco Zehe’s “Easy ARIA Tip #3: aria-invalid and Role alert31” or Deque’s post on accessible forms32. […]

  • Notes On Client-Rendered Accessibility | The Web Geek Permalink

    […] For more information on accessible client-side validation, read Marco Zehe’s “Easy ARIA Tip #3: aria-invalid and Role alert31” or Deque’s post on accessible forms32. […]

  • Notes On Client-Rendered Accessibility | endlessness Permalink

    […] For more information on accessible client-side validation, read Marco Zehe’s “Easy ARIA Tip #3: aria-invalid and Role alert31” or Deque’s post on accessible forms32. […]

  • Notes On Client-Rendered Accessibility - InfoLogs Permalink

    […] For more information on accessible client-side validation, read Marco Zehe’s “Easy ARIA Tip #3: aria-invalid and Role alert31” or Deque’s post on accessible forms32. […]

  • Barrierefreiheit mit WAI-ARIA – Teil 2/3 | console.log() Permalink

    […] ARIA werden von Marco Zehe (From WAI-ARIA to HTML5 and back .. or maybe not?) und Paul J. Adam (Accessible Client-side Form Validation with HTML5 & WAI-ARIA) diskutiert. Eine Best-Practice für dynamische Formular Labels mit WAI-ARIA erläutert Ted Drake […]

Leave a Reply

You can use these HTML tags:

<a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>