[KULRICE-5842] All lookup, inquiry, help icon and other controls associated with an input field should be contained in <fieldset> tags with their input field, with the legend of the fieldset equal to the input field's label Created: 26/Oct/11 Updated: 03/Apr/13 Resolved: 10/Aug/12
|Project:||Kuali Rice Development|
|Security Level:||Public (Public: Anyone can view)|
|Reporter:||Candace Soderston (Inactive)||Assignee:||Brian Smith (Inactive)|
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
|KAI Review Status:||Not Required|
|KTI Review Status:||Not Required|
Required for WCAG 2.0 level A (Must have):
This is an accessibility fix for the problem that screen readers won't otherwise signal to the user what a lookup, inquiry or other control is for (lookup what? inquire about what? help for what?)
All lookup, inquiry, help or other icon/controls should be contained in <fieldset> tags with their associated input field, with the legend of the fieldset equal to the input field's label. There is a new field group control in Rice 2.2 KRAD (added in milestone 1) that does this for you. (Does this handle associating the date-picker with its input field?)
Having multiple focus items in a cell, without appropriate column scope and column group and row headers or labels, or without other relational-structure cues for each focus element, creates a navigation problem for non-sighted users. Without these it is impossible to tell when the reading moves to the next cell/group versus the reading moving from control to control within a single cell/group (when using up/down arrows or reading entire page).
For example, within KNS maintenance pages, the screen-reader announces the table structure (# rows and columns), and for a single cell reads a label of "travel sub account number" for the entry field (the screen reader will append "edit, type in text"; in addition to the lookup control (will read "search field button for travel sub account number"), and in addition to the constraint text ("must be 10 digits for travel sub account number"), and in KS forms will also read the instructional text. It is difficult for the user to understand that these all relate to each other (within one cell), relate to the same label "travel sub account number" and entry field, before it moves to the next "group" of fields.
In general, it's best to follow the rule that if an object provides a unique form of interaction, it should get its own tab stop. For example, a form field in a table cell might be one tab stop, and a lookup icon next to it might be another. Other information however, such as the required state indicator (asterisk), and the information and constraint text should not be focusable or part of the tab order. Instead, you can associate this information with the elements that are focusable.
For a non-ARIA fix, form controls can be grouped inside a fieldset that describes the cell through its legend. This will ensure that screen reader users will hear the controls announced in the right context. To prevent visual clutter, the fieldset and legend can be hidden visually. Keep in mind that fieldset legends are generally only announced for form controls, not for links. For image links this can be fixed by replacing them with image buttons.
Alternatively, you can wrap the controls in an ARIA role="group" element, and then name that group using a title attribute.
See code snippet example at https://wiki.kuali.org/pages/viewpage.action?pageId=313868065
|Comment by Brian Smith (Inactive) [ 04/May/12 ]|
Moving to m2 because of potential last minute impact on m1