#35189: Accessibility issues with collapsed fieldsets in admin forms -------------------------------------+------------------------------------- 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 -------------------------------------+------------------------------------- Description changed by Thibaud Colas:
Old 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: > > 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. 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)]] 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#comment:1> 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/0107018da1e44b55-cf449e11-3d9c-4c3a-8688-8406f7032eb7-000000%40eu-central-1.amazonses.com.