We're adding aria-expanded to <details> elements in core, but the <details> element already has built-in accessibility semantics. Browsers automatically expose the expanded/collapsed state to screen readers, so the ARIA attribute is redundant and can actually cause confusion when screen readers announce conflicting state information.
Per WCAG 4.1.2 and the First Rule of ARIA, native HTML elements should be
used when available. The element automatically provides sufficient
accessibility semantics without additional ARIA attributes.
summary element and notice the added aria-expanded attribute.
Currently, here are all mentions of core/drupal.collapse
./core/tests/Drupal/KernelTests/Core/Asset/LibraryDiscoveryIntegrationTest.php: $this->assertEquals($this->libraryDiscovery->getLibraryByName('core', 'drupal.collapse'), $this->libraryDiscovery->getLibraryByName('test_theme', 'collapse'), 'Entire library correctly overridden.');
./core/core.libraries.yml:drupal.collapse:
./core/lib/Drupal/Core/Render/Element/Details.php: $element['#attached']['library'][] = 'core/drupal.collapse';
./core/modules/system/tests/themes/test_theme/test_theme.info.yml: core/drupal.collapse: test_theme/collapse
./core/modules/system/templates/status-report-grouped.html.twig:{{ attach_library('core/drupal.collapse') }}
./core/themes/stable9/templates/admin/status-report-grouped.html.twig:{{ attach_library('core/drupal.collapse') }}
./core/themes/claro/claro.info.yml: core/drupal.collapse:
./core/themes/claro/templates/status-report-grouped.html.twig:{{ attach_library('core/drupal.collapse') }}
./core/themes/olivero/olivero.info.yml: core/drupal.collapse:
Remove all aria-expanded attributes from <details> elements, including in FormPreprocess::preprocessDetails().
misc/details-aria.js from core/drupal.collapse in core/core.libraries.ymlNone. This is a markup cleanup.
N/A
N/A
N/A
Removed redundant aria-expanded attributes from <details> elements. The native HTML element provides sufficient accessibility semantics.
| Comment | File | Size | Author |
|---|---|---|---|
| #17 | safari.mp4 | 624.66 KB | rkoller |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
chrisgross commentedComment #4
chrisgross commentedComment #5
quietone commentedHi, Issues for Drupal core should be targeted to the 'main' branch, our primary development branch. Changes are made on the main branch first, and are then back ported as needed according to the Core change policies. The version the problem was discovered on should be stated in the issue summary Problem/Motivation section. Thanks.
Changing tags per Issue tags field and Issue tags -- special tags
Comment #6
kentr commentedTagging for SC 4.1.2 and ATAG.
I believe that for forms
aria-expandedgets added in all cases. In some cases it may not change when the element is expanded; I'm uncertain where the behavior is getting attached for forms.It does have dynamic behavior out of the box on node edit forms with the metadata fields (right column in Claro), but it looks like it toggles once and gets stuck.
For these cases, this issue could be Major because it results in an incorrect
aria-expandedvalue.Comment #7
kentr commentedNeeds more detail in STR.
Comment #8
chrisgross commented@kentr, you are right that just the node edit form represents this well. I was adding
<details>elements in CKEditor to see how Drupal was modifying existing markup via JavaScript, which is what my merge request changes, but it was not happening there and had not had time to explore further. I will update the issue description accordingly.My merge request does appear not solve this on the node form, so I assume that property is being added via PHP somewhere, perhaps with form API. I will have to investigate this further. The odd behavior of the attribute being changed only the first time an element is expanded was not something I originally noticed, so that is a problem in and of itself.
Comment #9
kentr commented@chrisgross
Strong suspicion that's in
FormPreprocess::preprocessDetails().Comment #12
chrisgross commentedComment #13
chrisgross commented@kentr that's exactly where I found it. Also present in the
system-modules-details.html.twigtemplates in all core themes. I've removed all of it in the MR.Comment #14
chrisgross commentedComment #15
smustgrave commentedthis will need accessibility sign off, not sure we can fully remove.
Know we can't just delete the file it'll have to be deprecated
Comment #16
dcam commentedCross-posted with @smustgrave.
There are at least two failing tests that explicitly check for the
aria-expandedattribute. These tests must be updated as a result of this change.Additionally, a test should be added to ensure that no one tries to re-add the attribute in the future.
I was able to reproduce the issue with the given steps in the issue summary, so I'm removing that tag.
Comment #17
rkollerI've manually tested by applying the patch with composer-patches (usually i use a different approach but with the current incompatibility of drush with the main branch i tried again the composer patches way - unsure if everything was applied correctly but some spotchecks looked correct). per se it is a good idea to avoid the usage of aria attributes. the only problem with the approach is with manual testing. I've tested on macOS 26.4 with the latest versions of safari, safari tech preview, firefox developer edition, and edge with voiceover. for firefox and edge the state change between expanded and collapsed was announced correctly. only problem for safari and the safari technology preview the state is not announced at all (check out safari.mp4 - illustrates the aural interface in safari 26.4 in the advanced sidebar in the node edit form)
Comment #18
rkollerand i guess this issue could also use more testers in other operating systems in combination with different browsers and screenreaders
Comment #19
kentr commentedComment #20
kentr commentedI think this is a (pseudo) duplicate of #3571628: The aria-expanded attribute doesn't change once it became true on a node edit forms detail summary element.
In that ticket, the decision is to keep and fix
aria-expandedin case of browser bugs / inconsistencies.To me, that looks like a sensible approach for now based on these:
That issue is older and has progress on fixing
aria-expanded, so I'm closing this one as a duplicate. Feel free to reopen if I got this wrong.