Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-80851

Accessibility: Form feedback text should not have tab stop, focus

    XMLWordPrintable

Details

    • Bug
    • Resolution: Not a bug
    • Minor
    • None
    • 4.4
    • None
    • MOODLE_404_STABLE
    • MDL-80851-m402
    • MDL-80851-m403
    • MDL-80851-main
    • Hide

      This can be tested on any form that has required fields with client-side validation - the easiest ones to find are 'required' fields. For simplicity, I suggest testing on the 'create course' page.

      You will need to test using a screen reader. I tested using NVDA (free, open source).

      1. Go to Site adminisration / Courses / Add a new course.
      2. Tab to the 'Course full name' box, which is a required field.
      3. Leaving the box blank, press Tab again.
        • EXPECTED: You should first hear the text '- Missing full name' (NVDA represents this with a 'beep' at the start, other screen readers may differ).
        • EXPECTED: Focus should now be on the help button for the short name field, which the screen reader will probably now read out.
      4. Press Tab again.
        • EXPECTED: Focus should now be on the 'course short name' field, which the screen reader will read out.
      5. Type some text in the short name field
      6. Press Shift-Tab
        • EXPECTED: Focus should now be on the help button again
      7. Press Shift-Tab
        • EXPECTED: Focus should be back on the 'course full name' field.
      8. Still leaving the field blank, press Tab
        • EXPECTED: There is no announcement this time because the message was already given. You get back to the help button.
      9. Go back to the full name field and type some text in it. Press Tab.
        • EXPECTED: The 'Missing full name' message should disappear (this will not be announced to screenreaders). Focus should be on the help button again.

      This test basically checks that there is no tab stop on the 'Missing...' message, and that the message when it does appear is read to screen readers

      Show
      This can be tested on any form that has required fields with client-side validation - the easiest ones to find are 'required' fields. For simplicity, I suggest testing on the 'create course' page. You will need to test using a screen reader. I tested using NVDA (free, open source). Go to Site adminisration / Courses / Add a new course. Tab to the 'Course full name' box, which is a required field. Leaving the box blank, press Tab again. EXPECTED: You should first hear the text '- Missing full name' (NVDA represents this with a 'beep' at the start, other screen readers may differ). EXPECTED: Focus should now be on the help button for the short name field, which the screen reader will probably now read out. Press Tab again. EXPECTED: Focus should now be on the 'course short name' field, which the screen reader will read out. Type some text in the short name field Press Shift-Tab EXPECTED: Focus should now be on the help button again Press Shift-Tab EXPECTED: Focus should be back on the 'course full name' field. Still leaving the field blank, press Tab EXPECTED: There is no announcement this time because the message was already given. You get back to the help button. Go back to the full name field and type some text in it. Press Tab. EXPECTED: The 'Missing full name' message should disappear (this will not be announced to screenreaders). Focus should be on the help button again. This test basically checks that there is no tab stop on the 'Missing...' message, and that the message when it does appear is read to screen readers

    Description

      (Note: This is another bug raised by our accessibility testing team, who did an audit recently.)

      In a form where there is a client-side rule check (usually 'required' or 'regex') which results in feedback text appearing when the user tabs out of the field, this feedback text is given a tab stop and automatically focused.

      For example in a sequence like this:

      Field 1 (required) [     ]
      Field 2            [     ]
      

      If a user tabs through the form (and, ignoring any help icons that might exist) they will get to field 1, then press Tab. Instead of getting to field 2 as might be expected, the system will insert feedback text

      Field 1 (required) [     ]
                         You left it blank, you muppet!
      Field 2            [     ]
      

      The focus will be changed to the text 'You left it blank, you muppet!' which is not actionable so would not normally be focused at all.

      Changing focus unexpectedly is bad for accessibility, and the extra tab stop (which remains in place from that point) is also bad for accessibility.

      I assume this behaviour was done for screen reader users to make it read out the message, because if it didn't break tabbing then the user would not know that the message had appeared because they have already gone to the next field.

      Some other notes about this scenario:

      • The form already correctly links the message to the field using aria-describedby, which means that if the user does go back to the field then a screenreader will read it out (either immediately, or in VoiceOver after offering a 'more description available' prompt or something like that).
      • For server-side errors, none of the 'bad' behaviour applies - the message does not have a tab stop and there is no messing with focus, the aria-describedby works and everything is good.

      I propose the following change to client-side error display, which our accessibility team agreed:

      • Do not add the feedback text to tab order, or focus it.
      • Use aria-live (probably 'assertive') attribute when inserting the feedback text so that the screenreader says it immediately at that point.

      I'll develop and test this in NVDA to check it works.

      Attachments

        Issue Links

          Activity

            People

              quen Sam Marshall
              quen Sam Marshall
              Katie Ransom Katie Ransom
              Jun Pataleta Jun Pataleta
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0 minutes
                  0m
                  Logged:
                  Time Spent - 5 hours
                  5h

                  Clockify

                    Error rendering 'clockify-timesheets-time-tracking-reports:timer-sidebar'. Please contact your Jira administrators.