Accessible dynamic forms


Published on

Published in: Technology, Business
1 Comment
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • [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

    1. 1. Accessible Dynamic Forms and Form Validation with jQuery Dylan Barrell (@dylanbarrell) Vice President of Product Development October, 2013
    2. 2. Examples and Code • GitHub Repository with Examples – • Uses a11yfy code –
    3. 3. 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
    4. 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. 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]
    6. 6. 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]
    7. 7. 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]
    8. 8. Common Success Criteria Robust • Name, Role, Value and State [WCAG 4.1.2 A]
    9. 9. 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
    10. 10. 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
    11. 11. 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
    12. 12. 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
    13. 13. 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
    14. 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
    15. 15. Layout
    16. 16. Layout
    17. 17. Layout
    18. 18. Layout
    19. 19. Layout
    20. 20. Layout Maintain natural DOM order • Do not use tabindex • Do not use unnecessary JavaScript focus management in forms Example
    21. 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. 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. 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. 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. 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. 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
    27. 27. Layout
    28. 28. Layout
    29. 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
    30. 30. Questions @dylanbarrell @unobfuscator