Uploaded image for project: 'Kuali Rice Development'
  1. Kuali Rice Development
  2. 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

    Details

    • Type: New Feature
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.2
    • Component/s: Accessibility
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Rice Module:
      KRAD
    • Application Requirement:
      KS
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required

      Description

      Required for WCAG 2.0 level A (Must have):

      • Adaptable Content criteria 1.3.1: Info & relationships: info, structure & relationships can be programmatically determined or are available in text. (This applies for read-only information as well as for editable forms that require user input.)

      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.
      For example:

      • required state can be indicated using aria-required, or by adding a hidden span element with the text "required" to the form control's label
      • Constraint information can be associated with the control using aria-describedby
      • Error information can be associated with the control using aria-invalid and aria-describedby.

      See code snippet example at https://wiki.kuali.org/pages/viewpage.action?pageId=313868065

        Attachments

          Issue Links

            Activity

            csoders Candace Soderston (Inactive) created issue -
            csoders Candace Soderston (Inactive) made changes -
            Field Original Value New Value
            Fix Version/s 2.1 [ 15812 ]
            csoders Candace Soderston (Inactive) made changes -
            Start Date
            Fix Date [ set to sprint end date ]
            jcoltrin Jessica Coltrin (Inactive) made changes -
            Fix Version/s 2.2 [ 16411 ]
            Fix Version/s 2.1 [ 15812 ]
            jcoltrin Jessica Coltrin (Inactive) made changes -
            Start Date
            Fix Date [ set to sprint end date ]
            csoders Candace Soderston (Inactive) made changes -
            Description This is an accessibility fix for the problem that screen readers won't otherwise signal to the user what a lookup, inquiry or help control is for (lookup what? inquire about what? help for what?)

            All lookup, inquiry, and help 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
            Required for WCAG 2.0 level A (Must have):
            - Adaptable Content criteria 1.3.1: Info & relationships: info, structure & relationships can be programmatically determined or are available in text. (This applies for read-only information as well as for editable forms that require user input.)

            This is an accessibility fix for the problem that screen readers won't otherwise signal to the user what a lookup, inquiry or help control is for (lookup what? inquire about what? help for what?)

            All lookup, inquiry, and help 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.

            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.
            For example:
            - required state can be indicated using aria-required, or by adding a hidden span element with the text "required" to the form control's label
            - Constraint information can be associated with the control using aria-describedby
            - Error information can be associated with the control using aria-invalid and aria-describedby.

            See code snippet example at https://wiki.kuali.org/pages/viewpage.action?pageId=313868065
            jkneal Jerry Neal (Inactive) made changes -
            Rice Lead jkneal
            jcoltrin Jessica Coltrin (Inactive) made changes -
            Fix Version/s 2.2-backlog [ 16475 ]
            jcoltrin Jessica Coltrin (Inactive) made changes -
            Start Date
            Fix Date [ set to sprint end date ]
            csoders Candace Soderston (Inactive) made changes -
            Summary All lookup, inquiry, and help icon/controls should be contained in <fieldset> tags with their input field, with the legend of the fieldset equal to the input field's label 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
            Fix Version/s 2.2.0-m1 [ 16462 ]
            Fix Version/s 2.2-backlog [ 16475 ]
            Description Required for WCAG 2.0 level A (Must have):
            - Adaptable Content criteria 1.3.1: Info & relationships: info, structure & relationships can be programmatically determined or are available in text. (This applies for read-only information as well as for editable forms that require user input.)

            This is an accessibility fix for the problem that screen readers won't otherwise signal to the user what a lookup, inquiry or help control is for (lookup what? inquire about what? help for what?)

            All lookup, inquiry, and help 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.

            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.
            For example:
            - required state can be indicated using aria-required, or by adding a hidden span element with the text "required" to the form control's label
            - Constraint information can be associated with the control using aria-describedby
            - Error information can be associated with the control using aria-invalid and aria-describedby.

            See code snippet example at https://wiki.kuali.org/pages/viewpage.action?pageId=313868065
            Required for WCAG 2.0 level A (Must have):
            - Adaptable Content criteria 1.3.1: Info & relationships: info, structure & relationships can be programmatically determined or are available in text. (This applies for read-only information as well as for editable forms that require user input.)

            This is an accessibility fix for the problem that screen readers won't otherwise signal to the user what a lookup, inquiry or help 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.

            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.
            For example:
            - required state can be indicated using aria-required, or by adding a hidden span element with the text "required" to the form control's label
            - Constraint information can be associated with the control using aria-describedby
            - Error information can be associated with the control using aria-invalid and aria-describedby.

            See code snippet example at https://wiki.kuali.org/pages/viewpage.action?pageId=313868065
            Assignee Brian Smith [ bsmith ]
            csoders Candace Soderston (Inactive) made changes -
            Start Date
            Fix Date 2012-03-26 [ set to sprint end date ]
            csoders Candace Soderston (Inactive) made changes -
            Parent KULRICE-5422 [ 81371 ]
            Issue Type Sub Task [ 43 ] New Feature [ 2 ]
            csoders Candace Soderston (Inactive) made changes -
            Description Required for WCAG 2.0 level A (Must have):
            - Adaptable Content criteria 1.3.1: Info & relationships: info, structure & relationships can be programmatically determined or are available in text. (This applies for read-only information as well as for editable forms that require user input.)

            This is an accessibility fix for the problem that screen readers won't otherwise signal to the user what a lookup, inquiry or help 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.

            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.
            For example:
            - required state can be indicated using aria-required, or by adding a hidden span element with the text "required" to the form control's label
            - Constraint information can be associated with the control using aria-describedby
            - Error information can be associated with the control using aria-invalid and aria-describedby.

            See code snippet example at https://wiki.kuali.org/pages/viewpage.action?pageId=313868065
            Required for WCAG 2.0 level A (Must have):
            - Adaptable Content criteria 1.3.1: Info & relationships: info, structure & relationships can be programmatically determined or are available in text. (This applies for read-only information as well as for editable forms that require user input.)

            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.
            For example:
            - required state can be indicated using aria-required, or by adding a hidden span element with the text "required" to the form control's label
            - Constraint information can be associated with the control using aria-describedby
            - Error information can be associated with the control using aria-invalid and aria-describedby.

            See code snippet example at https://wiki.kuali.org/pages/viewpage.action?pageId=313868065
            bsmith Brian Smith (Inactive) made changes -
            Fix Version/s 2.2.0-m2 [ 16463 ]
            Fix Version/s 2.2.0-m1 [ 16462 ]
            bsmith Brian Smith (Inactive) made changes -
            Start Date
            Fix Date 2012-03-26 2012-05-25 [ set to sprint end date ]
            jkneal Jerry Neal (Inactive) made changes -
            Link This issue fixes KULRICE-7079 [ KULRICE-7079 ]
            jkneal Jerry Neal (Inactive) made changes -
            Fix Version/s 2.2-backlog [ 16475 ]
            Fix Version/s 2.2.0-m2 [ 16463 ]
            jkneal Jerry Neal (Inactive) made changes -
            Start Date
            Fix Date 2012-05-25 [ set to sprint end date ]
            bsmith Brian Smith (Inactive) made changes -
            Status Open [ 1 ] Resolved [ 5 ]
            Resolution Fixed [ 1 ]
            jcoltrin Jessica Coltrin (Inactive) made changes -
            Fix Version/s 2.2-backlog [ 16475 ]
            jcoltrin Jessica Coltrin (Inactive) made changes -
            Status Resolved [ 5 ] Closed [ 6 ]
            spatterson Shem Patterson (Inactive) made changes -
            Workflow custom [ 104354 ] Copy of custom for rice [ 213258 ]
            spatterson Shem Patterson (Inactive) made changes -
            Workflow Copy of custom for rice [ 213258 ] custom [ 223006 ]
            spatterson Shem Patterson (Inactive) made changes -
            Workflow custom [ 223006 ] Rice Workflow [ 232754 ]

              People

              • Assignee:
                bsmith Brian Smith (Inactive)
                Reporter:
                csoders Candace Soderston (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: