The document discusses accessible and valid dynamic forms with jQuery. It provides examples of code on GitHub for form accessibility fundamentals like labels, instructions, layout, and dynamism. It also covers common WCAG 2.0 success criteria around perceivable, operable, understandable and robust forms. Specific techniques are presented for labels, instructions, layout, controls, and validation fundamentals.
4. Common Success Criteria
Perceivable
•
All labels must be programmatically associated with the input
field [WCAG 1.3.1 A]
•
Labels must be closely and visually associated with the input
field [Best Practice]
•
Error Messages must be associated with the input field
[WCAG 1.3.1 A]
•
Do not use color alone to indicate differences between fields
[WCAG 1.4.1 A]
–
•
Required/Optional Fields, Error Fields
Color Contrast between controls, labels, instructions, errors
and the background must be sufficient [WCAG 1.4.3 AA]
5. Common Success Criteria
Operable
•
Error messages that apply to the whole form must be
announced automatically [WCAG 2.4.3 A]
•
Instructions that update/change dynamically must be
announced automatically [WCAG 2.4.3 A]
•
If you take action that allows the sighted mouse user to
quickly identify and deal with fields that are in error, then an
equivalent mechanism should be provided for keyboard users
[WCAG 2.1.1 A]
•
No Keyboard trap [WCAG 2.1.2 A]
14. Layout
Locate related items close to one another
•
Labels to input fields
•
Error messages to input fields
•
Instructional text/help icons to input fields
20. Layout
Maintain natural DOM order
•
Do not use tabindex
•
Do not use unnecessary JavaScript focus management in forms
Example
21. Dynamism
On Focus/Blur
•
Often used to show additional instructions
–
•
Use aria-live and related attributes to announce changes
Often used to do form validation
–
–
•
Use blur to recapture focus into field if it fails to validate (do not create a
keyboard trap)
Use aria-live to announce errors
Sometimes used to add fields
–
Use interim “busy” modal to trap and manage focus
22. Dynamism
On Change/Input
•
Do not auto advance multi-part fields (e.g. SSN, Date, Phone
number)*
•
Use the modal focus trapping technique if modifying the form
•
Be aware that updates to labels and aria-describedby fields
do not auto announce
–
Use aria-live
Example – Good and Bad
23. Dynamism
jQuery Animations
•
Error Messages must be in the DOM and visible when the
appropriate field receives focus
•
Form fields must be in the DOM, visible and enabled in order
to receive focus programmatically
•
iOS focus management requires waiting a full second after
show before an element can receive focus
24. Controls
Use native controls where available
•
<button> or <input type=“submit|image” > and not <a>
•
Use standard radio buttons if possible
•
Conditional use of HTML5 new input types (iOS)
–
•
Date, Slider etc.
Avoid use of “retrofit roles”
–
role=“button”
–
role=“checkbox”
–
role=“textbox”
–
role=“radio”
Example
25. Validation Fundamentals
Be consistent
•
Choose either automatic validation or validation on
submission
•
Choose one of:
–
Telling users which fields are required
–
Telling users which fields are optional
•
Consistent layout and visual design
•
Consistent markup!!
26. Error Layout and Navigation
Structure
•
Ensure error messages are visually distinct
•
Ensure error messages are visually associated with the input
field(s)
–
–
•
Cognitive disabilities
Zoom users
Ensure that attention is drawn to the items that are in error
–
–
•
Submission: Either focus on first field or focus on error summary
Auto: revert focus to the field that is in error (do not create a keyboard
trap)
In large forms, make navigation between fields that are inerror easy
–
Keyboard navigation and mouse navigation
29. Error Messages
Structure
•
Ensure that error messages are programmatically associated
with the input field
–
Use techniques previously mentioned
•
Ensure that form-wide error information either receives focus
on validation failure (submission only) or is announced
automatically
•
Ensure that error messages are easy to understand
•
If validation occurs on submission, validate all form fields at
once and provide a summary of all the errors in a summary
Final Example
[Do we want a fed graphic or photo here?][TYLER: If you do want an image, can you let me know if “fed” just means government in this context?]
Although this is the currently preferred method for group labels, it is subject to differing implementations from AT to AT and some ATs have chosen to implement this in an irritating fashion (e.g. JAWS will announce the group label when focus moves to every sub-field, whereas NVDA will only do this on the first field in the group)
Allows for more consistent support by Ats (controllable by you) but is not as widely supported by AT
Be aware – bugs exist in combined use of aria-live and aria-describedby
If you must use animations, then just be aware of the issues they create and work around them
Consistency is one of the most important attributes of a site or application in order to make it easy to use.Remember, visual consistency does not equal consistency from a perspective of accessibility – consistent markup is as important as consistent visual layout. For example, if something looks like a button and is marked up as a button the first time and looks the same but is marked up as an anchor the second time, this can cause users to waste time, repeat commands and/or get confused.
A user who is sighted should be able to immediately identify the fields that are in error as distinct from those that are not. Remember to not use color alone, use icons too or flip the background and foreground (light on dark vs. dark on light)Make sure it is unambiguous as to which field the error belongs to and make sure that this connection is discernable easily when using a screen magnifierTo assist users with cognitive disabilities and blind users, draw focus immediately to the first field that is in error and/or the summary if validation is done on submission. If validation is done automatically, then draw the focus back to the first field in error
Use the techniques described previously to associate the error messages with the input fields. In order of preference, make them part of the label first and if that is not possible due to the markup, add them as a hint through aria-describedby.Making error messages easy to understand involves at least: 1) making sure that the reading level required to understand it is appropriate, and 2) that if the error was due to content format or content rather than the omission of a required field, that additional information be supplied about the reason the format or content was not valid (remember to not compromise security)