Accessible dynamic forms
Upcoming SlideShare
Loading in...5

Accessible dynamic forms






Total Views
Views on SlideShare
Embed Views



44 Embeds 4,852 1707 692 413 282 243 158 128 108 107 91 79 74 73 62 52 51 41 40 40 32 32 28 28 26 25 25 24 23 21 19 19 19 18 16 15 13 10 6 4 3 2 1 1 1


Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • [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)

Accessible dynamic forms Accessible dynamic forms Presentation Transcript

  • Accessible Dynamic Forms and Form Validation with jQuery Dylan Barrell (@dylanbarrell) Vice President of Product Development October, 2013
  • Examples and Code • GitHub Repository with Examples – • Uses a11yfy code –
  • Overview • Commonly Violated WCAG 2.0 (A, AA) SC • Form Accessibility Fundamentals – – Instructions – Layout – Dynamism – • Labels Controls Validation Fundamentals – Fundamentals – Layout and navigation – Error messages and summaries
  • 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]
  • 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]
  • Common Success Criteria Operable • Focus order [WCAG 2.4.3 A] • Focus Visible [WCAG 2.4.7 AA] • Everything must be operable with the keyboard [WCAG 2.1.1 A]
  • Common Success Criteria Understandable • On focus [WCAG 3.2.1 A] • On input [WCAG 3.2.2 A] • Error Suggestion [WCAG 3.3.3 AA] • Error prevention (Legal, Financial, Test data) [WCAG 3.3.4 AA]
  • Common Success Criteria Robust • Name, Role, Value and State [WCAG 4.1.2 A]
  • Labels Simple Labels • Use for-id association <label for=“myinputid”>Label Text</label> <input id=“myinputid” type=“text” /> • Use aria-labelledby <label id=“mylabelid”>Label Text</label> <input aria-labelledby=“mylabelid” type=“text” /> • Use label wrapping <label for=“myinputid”>Label Text <input id=“myinputid” type=“text” /> </label> • Example
  • Labels Simple Labels • Use aria-label and/or title (beware) <input id=“search” type=“text” arialabel=“Search”placeholder=“Search”/><button>Search</button> – • or <input id=“search” type=“text” title=“Search”placeholder=“Search”/><button>Search</button> Example
  • Labels Multiple Labels • Groups - fieldset <fieldset> <legend>Social Security Number</legend> <input type="text" name="ssn1" id="ssn1” title="first three digits"/> <input type="text" name="ssn2" id="ssn2” title="middle two digits"/> <input type="text" name="ssn3" id="ssn3” title="last four digits"/> </fieldset> • Example
  • Labels Multiple Labels • Groups – aria-labelledby <span id=“gender-group”>Gender</span> <input aria-labelledby=“gender-group male-gender” name=“gender” value=“male” type=“radio” /> <label id=“male-gender”>Male</label> <input aria-labelledby=“gender-group female-gender” name=“gender” value=“female” type=“radio” /> <label id=“female-gender”>Female</label> • Example
  • Instructions Advisory Text, Additional Text… • aria-describedby <p> <label for=“mybirthdateid”>Date of Birth</label> <input id=“mybirthdateid” type=“text” aria-describedby=“datefmt”/> <span id=“datefmt”>format: dd/mm/yyyy</span> </p> • Example
  • Layout Locate related items close to one another • Labels to input fields • Error messages to input fields • Instructional text/help icons to input fields
  • Layout
  • Layout
  • Layout
  • Layout
  • Layout
  • Layout Maintain natural DOM order • Do not use tabindex • Do not use unnecessary JavaScript focus management in forms Example
  • 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
  • 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
  • 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
  • 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
  • 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!!
  • 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
  • Layout
  • Layout
  • 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
  • Questions @dylanbarrell @unobfuscator