[Django] #35189: Accessibility issues with collapsed fieldsets in admin forms
Django
-------------------------------------+-------------------------------------
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.
Django
-------------------------------------+-------------------------------------
Type: Bug | Status: new
Component: contrib.admin | Version: 5.0
Severity: Normal | Resolution:
Keywords: accessibility, | Triage Stage:
whcm, forced colors, screen | Unreviewed
reader, forms, admin |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 1
-------------------------------------+-------------------------------------
* Attachment "collapsed-fieldset-django.gif" added.
Screen recording of the "Advanced options" collapsible fieldset in
flatpages change forms
Django
-------------------------------------+-------------------------------------
Reporter: Thibaud Colas | Owner: nobody
Type: Bug | Status: new
Component: contrib.admin | Version: 5.0
Severity: Normal | Resolution:
Keywords: accessibility, | Triage Stage:
whcm, forced colors, screen | Unreviewed
reader, forms, admin |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 1
-------------------------------------+-------------------------------------
Old description:
New description:
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:
[[Image(https://code.djangoproject.com/raw-attachment/ticket/35189
/collapsed-fieldset-django.gif)]]
=== Accessibility bugs
=== Styling issues
=== Solution
--
--
Ticket URL: <https://code.djangoproject.com/ticket/35189#comment:1>
Django
-------------------------------------+-------------------------------------
Reporter: Thibaud Colas | Owner: nobody
Type: Bug | Status: new
Component: contrib.admin | Version: 5.0
Severity: Normal | Resolution:
Keywords: accessibility, | Triage Stage:
whcm, forced colors, screen | Unreviewed
reader, forms, admin |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 1
-------------------------------------+-------------------------------------
I'd like to pick this one up!
--
Ticket URL: <https://code.djangoproject.com/ticket/35189#comment:2>
Django
-------------------------------------+-------------------------------------
Reporter: Thibaud Colas | Owner: nobody
Cleanup/optimization |
Component: contrib.admin | Version: dev
Severity: Normal | Resolution:
Keywords: accessibility, | Triage Stage: Accepted
whcm, forced colors, screen |
reader, forms, admin |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 1
-------------------------------------+-------------------------------------
* version: 5.0 => dev
* type: Bug => Cleanup/optimization
* stage: Unreviewed => Accepted
Comment:
Hello Thibaud, thanks for this report and its detailed content.
Accepting following the provided rationale. A few notes:
* Regarding the (loosing of the) rounded corners, I think we need to
consider consistency with the "regular" fieldsets headings which are non
rounded. Up to verification, I think we should remove the rounding
altogether for this fieldset title. It seems the rounding comes from
reusing the style of the action row, and then when active, the style comes
from the usual fieldset legend.
* It's likely that we can get rid of the Javascript performing the toggle
by using newest CSS selectors.
--
Ticket URL: <https://code.djangoproject.com/ticket/35189#comment:3>
Django
-------------------------------------+-------------------------------------
Type: | Luttekes
Cleanup/optimization | Status: assigned
Component: contrib.admin | Version: dev
Severity: Normal | Resolution:
Keywords: accessibility, | Triage Stage: Accepted
whcm, forced colors, screen |
reader, forms, admin |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 1
-------------------------------------+-------------------------------------
* owner: nobody => Marijke Luttekes
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/35189#comment:4>
Django
-------------------------------------+-------------------------------------
Reporter: Thibaud Colas | Owner: Marijke
Type: | Luttekes
Cleanup/optimization | Status: assigned
Component: contrib.admin | Version: dev
Severity: Normal | Resolution:
Keywords: accessibility, | Triage Stage: Accepted
whcm, forced colors, screen |
reader, forms, admin |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 1
-------------------------------------+-------------------------------------
Regarding the (loosing of the) rounded corners, I think we need to
consider consistency with the "regular" fieldsets headings which are non
rounded. Up to verification, I think we should remove the rounding
altogether for this fieldset title. It seems the rounding comes from
reusing the style of the action row, and then when active, the style comes
from the usual fieldset legend.
Agreed. When toggling the fieldset, the element also seems to move a
pixel, which is visually unpleasing
I will switch to straight edges for these items.
It's likely that we can get rid of the Javascript performing the toggle
by using newest CSS selectors.
My original idea for a fix does use a little JavaScript (no jQuery).
I will check with the accessibility team if they know of a better method,
e.g., using a checkbox in HTML and the `:checked` CSS pseudo-class
selector.
--
Ticket URL: <https://code.djangoproject.com/ticket/35189#comment:5>
Django
-------------------------------------+-------------------------------------
Reporter: Thibaud Colas | Owner: Marijke
Type: | Luttekes
Cleanup/optimization | Status: assigned
Component: contrib.admin | Version: dev
Severity: Normal | Resolution:
Keywords: accessibility, | Triage Stage: Accepted
whcm, forced colors, screen |
reader, forms, admin |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 1
-------------------------------------+-------------------------------------
Comment (by Marijke Luttekes):
https://github.com/django/django/pull/17910
I'm curious what you all think of this solution. It's based on one of my
proofs of concept, which is mentioned in the first message of the PR.
--
Ticket URL: <https://code.djangoproject.com/ticket/35189#comment:6>
Django
-------------------------------------+-------------------------------------
Reporter: Thibaud Colas | Owner: Marijke
Type: | Luttekes
Cleanup/optimization | Status: assigned
Component: contrib.admin | Version: dev
Severity: Normal | Resolution:
Keywords: accessibility, | Triage Stage: Accepted
whcm, forced colors, screen |
reader, forms, admin |
Easy pickings: 0 | UI/UX: 1
-------------------------------------+-------------------------------------
* has_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/35189#comment:7>
Django
-------------------------------------+-------------------------------------
Reporter: Thibaud Colas | Owner: Marijke
Type: | Luttekes
Cleanup/optimization | Status: assigned
Component: contrib.admin | Version: dev
Severity: Normal | Resolution:
Keywords: accessibility, | Triage Stage: Accepted
whcm, forced colors, screen |
reader, forms, admin |
Has patch: 1 | Needs documentation: 0
-------------------------------------+-------------------------------------
* needs_better_patch: 0 => 1
Comment:
I can see the accessibility team also has this in their review queue:
https://github.com/orgs/django/projects/7, so hopefully you will receive
another review soon.
--
Ticket URL: <https://code.djangoproject.com/ticket/35189#comment:8>
Django
-------------------------------------+-------------------------------------
Reporter: Thibaud Colas | Owner: Marijke
Type: | Luttekes
Cleanup/optimization | Status: assigned
Component: contrib.admin | Version: dev
Severity: Normal | Resolution:
Keywords: accessibility, | Triage Stage: Accepted
whcm, forced colors, screen |
reader, forms, admin |
Has patch: 1 | Needs documentation: 0
-------------------------------------+-------------------------------------
Changes (by Sarah Boyce):
--
Ticket URL: <https://code.djangoproject.com/ticket/35189#comment:9>
Django
-------------------------------------+-------------------------------------
Reporter: Thibaud Colas | Owner: Marijke
Type: | Luttekes
Cleanup/optimization | Status: assigned
Component: contrib.admin | Version: dev
Severity: Normal | Resolution:
Keywords: accessibility, | Triage Stage: Accepted
whcm, forced colors, screen |
reader, forms, admin |
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 1
-------------------------------------+-------------------------------------
* cc: Tom Carrick, Sarah Abderemane (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/35189#comment:10>