Accessible Dynamic Forms and Form Validation with jQuery

jQueryForms are some of the most important pieces of most web sites; without them, we would not be able to log in, sign up, purchase, comment, post or do many of the things online we take for granted every day. Given the importance of forms, it is quite shocking that you can go to almost any Fortune 100 company’s web site – including many financial services web sites – and find forms that have the most basic accessibility issues. That is why, when we hosted our recent jQuery Accessibility Summit, I insisted on having a session on forms and form validation and when nobody else stepped up to give it, I decide to give the presentation myself.

This blog posting was initially posted on my personal blog Unobfuscated.

You can view the presentation slides on Slideshare and embedded at the bottom of this posting. I am going to do a series of blog posts here that add the detail that the slides cannot convey. This first post in the series covers…

The WCAG 2.0 Level AA Guidelines that are Commonly Violated in forms

Firsty, let me say that ALL WCAG 2 guidelines are potentially applicable to forms, but there are some that are more common and these are:

  • Perceivable

    • 1.3.1 (A) Associate labels programmatically with their input fields

    • 1.3.1 (A) Associate error messages programmatically with their input fields

    • 1.4.1 (A) Do not use color alone to indicate differences between fields (required, errors etc.)

    • 1.4.3 (AA) Ensure sufficient contrast between foreground and background (labels, instructions, errors etc.)

    • Best Practice: visually associate labels, instructions and errors with their input fields

  • Operable

    • 2.1.1 (A) If you take action to allow mouse users to easily identify error fields, an equivalent must be provided for keyboard only users

    • 2.1.1 (A) Everything must be operable with the keyboard only

    • 2.1.2 (A) No keyboard trap

    • 2.4.3 (A) Error messages that appear and apply to the whole form should be announced automatically

    • 2.4.3 (A) Instructions that change or appear dynamically must be announced automatically

    • 2.4.3 (A) The focus order of the elements in the form must match the visual order

    • 2.4.7 (AA) There must be a visual focus indicator to show keyboard users where the focus is at all times

  • Understandable

    • 3.2.1 (A) On Focus events should not do things to confuse or disorient the user

    • 3.2.2 (A) Changes that occur based on input should not confuse or disorient the user

    • 3.3.3 (AA) Error messages should provide suggestions as to how to correct the errors wherever this is feasible and does not compromise security

    • 3.3.4 (AA) If the form is on a financial or testing site or has legal ramifications, then the user must be given a chance to review their form inputs prior to submission

  • Robust

    • 4.2.1 (A) Role, Value, Name and State of all form elements should be accurate during all dynamic states of the form

You can follow me on Twitter @dylanbarrell

Photo of Dylan Barrell

About Dylan Barrell

Dylan is Deque's CTO and leads product development initiatives. He works to help to build a barrier-free web by making it really easy for developers, quality assurance engineers and content writers to create accessible applications and content. Dylan has an MBA from the University of Michigan and a BS from the University of the Witwatersrand.
update selasa

Leave a Reply

Your email address will not be published. Required fields are marked *