Changes between Version 16 and Version 19 of Ticket #32338
- Timestamp:
- Aug 26, 2021, 11:52:26 PM (3 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #32338
- Property Has patch unset
-
Ticket #32338 – Description
v16 v19 9 9 1. The fields aren’t semantically grouped, only visually, so the grouping isn’t apparent to assistive technlogies. It’s important that related fields are grouped, and that the group has a label attached to it. If I was auditing this professionally I would classify this as a fail for [https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships.html SC 1.3.1 - Info and Relationships] of WCAG 2.1, as the grouping and label are somewhat there, just not done with the appropriate semantics. 10 10 2. (**fixed in b9e872b59329393f615c440c54f632a49ab05b78**) Speaking of label – currently the group of fields is labeled by preceding it with `<label for="id_radio_choice_required_0">Radio choice required:</label>`. This overrides the label of the first field within the group (and only labels the first field, not the whole group). This is a fail for [https://www.w3.org/WAI/WCAG21/Understanding/labels-or-instructions.html 3.3.2: Labels or Instructions] and/or SC 1.3.1. 11 3. Wrapping the fields each in their own list item makes the navigation more tedious, as screen readers will first announce list items numbering, and only then their content.11 3. (**fixed in 5942ab5eb165ee2e759174e297148a40dd855920**) Wrapping the fields each in their own list item makes the navigation more tedious, as screen readers will first announce list items numbering, and only then their content. 12 12 13 13 Here is a screenshot demonstrating the label issue with macOS VoiceOver’s rotor. Note how the first field has the wrong label due to the markup. … … 21 21 - Lack of a fieldset means no semantic grouping. 22 22 - The label isn’t associated with anything for this widget, so is less problematic but no more correct. 23 - Wrapping the fields in list items also makes the form more verbose than it should be (and the semantics issues are the same).23 - (**fixed in 5942ab5eb165ee2e759174e297148a40dd855920**) Wrapping the fields in list items also makes the form more verbose than it should be (and the semantics issues are the same). 24 24 25 25 == Documentation issues (fixed in d8c17aa10c7f41e692fb6f5d0bf2fab7a90b9374) … … 36 36 1. Wrap the group of fields in a `fieldset`, including the group’s label, the inputs, the help text, and any errors. 37 37 2. Use a `legend` as the first item in the `fieldset` for the group’s label, rather than a `label`. 38 3. Replace the list markup with un-semantic div, or remove altogether. If the list markup is needed for backwards compatibility, it could also use `role="presentation"` so assistive technologies ignore the list & listitem semantics, but I would only recommend that as a temporary workaround.38 3. (**fixed in 5942ab5eb165ee2e759174e297148a40dd855920**) Replace the list markup with un-semantic div, or remove altogether. If the list markup is needed for backwards compatibility, it could also use `role="presentation"` so assistive technologies ignore the list & listitem semantics, but I would only recommend that as a temporary workaround. 39 39 40 40 Here is sample markup to implement the above. The `div` aren’t needed, I’ve only added them to preserve the vertical layout of the current implementation: