#35189: Accessibility issues with collapsed fieldsets in admin forms
-------------------------------------+-------------------------------------
Reporter: Thibaud | Owner: nobody
Colas |
Type: Bug | Status: new
Component: | Version: 5.0
contrib.admin | Keywords: accessibility,
Severity: Normal | whcm, forced colors, screen reader,
Triage Stage: | forms, admin
Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 1 |
-------------------------------------+-------------------------------------
There are a number of issues with the "collapsible fieldset" in admin
forms. This can be most easily tested on flatpages, with the "Advanced
options" fields. Here’s a [https://django-admin-
tests.netlify.app/django_admin_tests/v5.1/english/admin/flatpages/flatpage/1/change/
Change flat page demo page]. And a screen recording of the widget:
I think there are enough problems that it makes sense to fix it all in one
go, though the issues are technically separate.
=== Accessibility bugs
1. The toggle should be a `<button>`, not a link, so screen reader and
WHCM users understand what the element is for more easily.
2. The toggle needs an `aria-expanded` attribute set to true or false
based on its current state, so screen reader users know what the state of
the element is. See the
[https://www.w3.org/WAI/ARIA/apg/patterns/disclosure/ APG disclosure
pattern] for further information.
3. The `<fieldset>` element should have a `<legend>`, so the fields are
understood to be grouped for screen reader users.
4. The toggle must have a minimum size of 24x24, so it’s easier for users
with low-precision pointing devices or low mobility to hit it.
5. The toggle shouldn’t change size based on the length of text within (in
English show/hide is very close, in other languages not necessarily).
6. The toggle’s appearance must be distinguished from other heading text
via other means than color, so colorblind users can spot it.
7. In the active state, it’s impossible to tell the toggle apart from the
other header text.
8. The collapsible heading is a `<h2>`, even though the whole form itself
is titled with an `<h2>`. It should be an `<h3>` instead so screen reader
users have a more accurate representation of the page’s hierarchy.
9. In forced colors mode, it’s much harder to spot the location of the
collapsible section header/heading, as background colors aren’t shown.
=== Styling issues
While we’re at it there are also styling issues which I think could be
fixed at the same time:
1. The collapsible section heading’s left edge isn’t aligned with the left
edge of other form fields’ labels (8px left padding vs. 10px elsewhere)
2. The collapsible section heading should have a font size at least as
large as the field labels within, so the visual hierarchy is clearer.
3. In the active state, the collapsible section header’s styles change too
drastically. It doesn’t need to call for attention so much, when the
user’s focus should be on what was revealed. Ideally the toggle’s styles
would be different, as that’s the key UI element that’s in a different
state.
4. It seems odd the collapsible section header looses its rounded corners
when in the active state.
5. In forced colors mode, it’s distracting that the position of the
heading / toggle shifts due to the collapsible header area border
disappearing.
=== Solution
I think this is a good candidate for a full rebuild, which could keep some
of the visual cues of the existing component but there are enough
accessibility issues to address that it could also be more different. The
new version should:
1. Either use a `<details>` and `<summary>` element for the collapsing, or
implement the [https://www.w3.org/WAI/ARIA/apg/patterns/disclosure/ APG
disclosure pattern] to spec.
2. Preserve any bespoke logic of the current component to show/hide based
on form state (don’t collapse if there are form errors within?)
3. Use a `<h3>` for the heading and `<legend>` for the heading (probably
`summary > h3 > legend` or `button > h3 > legend` but TBC)
4. Use a fixed-size toggle – possibly with a visual device such as a caret
to convey the state without use of color. Ideally the whole section header
area would be clickable.
5. Look and work great for all of the admin’s
[https://docs.djangoproject.com/en/5.0/faq/admin/#what-assistive-
technologies-are-supported-for-using-the-admin supported assistive
technologies].
There could be some value in using `<details>` so this all works without
JS, though we’d need to make sure to still support any JS-dependent
behavior of the collapsible section.
--
Ticket URL: <https://code.djangoproject.com/ticket/35189>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/0107018da1e3a7d8-f4b03651-2725-4829-981c-35832044d278-000000%40eu-central-1.amazonses.com.
