-
Bug
-
Resolution: Fixed
-
Major
-
3.8
-
MOODLE_38_STABLE
-
MOODLE_38_STABLE
-
MDL-67663-master-3 -
-
1
-
International 3.9 - Sprint 5, International 3.9 - Sprint 9
- Navigate to the "Grade Users" UI for a forum post
- Input a grade in the "Grade" field
- Navigate back to the "Next" link and click
- A screen reader perceivable message "Grade saved for ..." is presented.
The accessibility and usability issues here can be parsed in a few ways:
- That the "Next" element is marked up as a link doesn't conform to WCAG 2.1 4.1.2 because, when data is present, it functions as a submit button. Users do not typically expect clicking a link to submit data. (There is arguably no 4.1.2 issue if there is no data in the "Grade" field, because it is functioning as a link.)
- You could view the same issue as a WCAG 2.1 1.3.1 nonconformance, since the relationship between the navigation and the form is not clear, and submitting data by not clicking a link is not semantics. (WCAG 1.3.1 generally hopes for valid semantics.)
- Since there are no instructions indicating that the way to submit the data is by clicking the link, the interaction does not really conform with the spirit of WCAG 2.1 3.3.2, which expects helpful instructions for forms.
- While the grade submitted status message is perceivable by screen readers, the is no indication that the student presented has updated (that the link has taken the user to a new student.) The new student's name and the "X out of Y" change in context are not updated. so this does't conform to WCAG 2.1 4.1.3. To demonstrate this, click the "Next" button without data entered into the grade field. No status message is presented to the user even though the student displayed has been updated.
- Though not a strict accessibility nonconformance but a usability concern: when clicking the "Next" or "Previous" button, focus remains on the link, which may suggest to a screen reader user that nothing has changed when clicking it, especially when there is no status message. Moving focus to, say, the users name may help indicate to the user that clicking a link has in fact navigated to a new resource.
- Typically, in forms, submit buttons occur at the end of the form. Since the "Next / Previous" buttons appear at the top of the form, and no explicit submit button is present, and no instructions are present, a user may be confused how to submit the form information. It can also be cumbersome to navigate to the end of the form to submit data, and then navigate back through the form to find the submit button.
I'm not sure whether these would be usability issues without testing with users with disabilities, and if they have said they have no issue with the UI, that's great. But if usability testing hasn't done, the overall interaction might be a candidate for testing and redesign.
In the mean time, adding instructions that clicking the Next button will submit data, if any data is present, and providing status updates that the UI has navigated to a new student, would present immediate accessibility improvements.
- has been marked as being related by
-
MDL-80353 Accessibility issues with Add/remove users selector (i.e. add/remove to groups)
-
- Closed
-
- is duplicated by
-
MDL-67655 Fix Accessible Names for Controls on Forum Grading
-
- Closed
-
- Testing discovered
-
MDL-68355 Fix accessibility issues for the marking guide grading form in the forum grading UI
-
- Closed
-