Rice 2.2 – KRAD Validation Framework Requirements Review – “Feedback Friday” session 3/9/2012 KRAD Team (C Soderston, facilitating - Kuali Rice 2.2 – KRAD BA & UX)

User submits complex form (after field-level client-side validation, if any, is done). Application finds validation problems in multiple fields on the page, across sections of the page. At top of page there is a page-level summary of validation messages - focus is placed here when the application returns after a submit with validation problems – the summary includes the # & type of errors & other messages in each section, not the full message text. User can jump directly to any of the sections that have messages, because each section in the summary is marked up as a link: If there are section-level summaries, the focus(link) moves to the section’s summary, and from there the user can jump to any of the fields. (this is recommended) If there are no section-level summaries, the focus(link) moves to the header of the chosen section. (Application can implement w/o section summaries but this is not recommended) The page level and section level headings are appended with the # of errors & other messages. The user can get back to the page-level summary using standard shortcuts for moving to top of page ( or we could create a custom global shortcut). 2 Validation Messaging – Rice 2.2 KRAD Strategy

Example page-level summary, with heading text-variable filled in: 17 errors in form submission Example group and field-level error messaging: Error state indication is placed with the field – see icon and field visual treatment. (Helps low-vision & all users!) Error text is placed in section-level summary above the section’s fields AND placed in an error tooltip. The tooltip appears contiguous with the field when the user hovers over and when the field is selected. Try out the behavior in a sample code implementation here! 3 Validation Messaging – Scenario Review

Additional visual indication on the field when user hovers over the error text. Additional visual indication on the field when the user selects it and can enter data. Tooltip remains visible with the field while entering the data. Try out the behavior in a sample code implementation here! 4 Validation Messaging – Scenario Review, cont.

This strategy solves the formatting problems we otherwise create when we place error message text within each field (whether immediately below or to the right), requiring other space to be pushed aside or down: We don’t know how wide or deep the other aspects associated with the fields and groups will be, how adding the error text will affect the relationship/layout with other field groups on the page. Placing content inside a form field’s label means that all this content will be announced by a screen reader as the field’s accessible name, rather than as the field’s accessible description or state information. This is too verbose. This strategy addresses the need to place the error indication and text as close to the field as possible -- helpful for all users and also needed particularly for low-vision users. Try out the behavior in a sample code implementation here! 5 Validation Messaging – Scenario Review, cont.

Summary – “Feedback Friday” Discussion & Feedback More information is available here on the wiki.here on the wiki Interested in your input to Scenarios: Scenarios where your application returns all 3 levels of server-side validation messages -- multiple error, warning, and informational messages, associated with a single field or control? Scenarios where your application returns messages that are not affiliated with a particular field or control (“global” – at the page or section level)? Assessment across the applications – longer-term impact to you and your users? Other comments / critiques? 6

Q & A 7