Problem/Motivation

Spin off from #3604037: Indicate that grouping elements have child element errors for UX and a11y.

Child elements in the forms sidebar are invisible to the user when the sidebar is closed. It's the same fundamental problem as with the related grouping element issues.

To improve the user experience and accessibility we should indicate when there are errors 'inside' the closed sidebar. Currently it is hard for the user to find the actual problematic field when the (child) field itself is invisible.

I'm assuming this is Major for the same reasons that the issues for standard grouping elements are.

Steps to reproduce

  1. Standard installation
  2. Log in as admin
  3. Set Default Admin as the admin theme.
  4. Install the article test recipe (drush recipe core/tests/fixtures/recipes/article_content_type),
    or create an Article content type & install the Path module (aka path_alias).
  5. Go to /node/add/article.
  6. Reduce viewport width until the sidebar on the right containing the "advanced" fields collapses.
  7. Enter a value in the Title field to limit errors.
  8. Click the toggle button to expand the right sidebar.
  9. Enter a value without a beginning slash in the URL alias field.
  10. Close the sidebar.
  11. Clear / reset caches (drush cr). This is a temporary measure.
    (Tested on the MR tugboat preview as of 2026-09-07, and clearing the cache was not necessary. Also, the UX team experienced no issues with it in their second review.)
  12. Click the Save button.
    This should cause a validation error: "The alias path has to start with a slash".
Expected

The closed sidebar indicates that there is an invalid field within it, for the same reasons that details and vertical tabs elements indicate that there are child errors for #3604037: Indicate that grouping elements have child element errors for UX and a11y.

See the Proposed resolution for details on the new indicators.

Actual

There's no indication that the closed sidebar contains an invalid field.

Proposed resolution

Add visual and visually-hidden indicators to the toggle button as so:

  1. Place the prohibition icon from the top error block at the logical inline start of the toggle button, previous to the sidebar icon.
    This means on the left for LTR and on the right for RTL.
  2. In the toggle control's default state the prohibition and sidebar icons are red. (see screenshot in the User interface changes section.)
  3. In the hover and focus states, the prohibition icon is red and the sidebar icon is the same as it is now. (see screenshot in the User interface changes section.)
  4. Use the input error color from invalid fields for the sidebar icon and the prohibition icon (var(--input--error-color)).
  5. Append visually hidden " (sidebar contains error)" to the text content of the toggle control. This is mostly consistent with the hidden text in #3604037: Indicate that grouping elements have child element errors for UX and a11y and #2848507: Indicate that grouping elements have child element errors for ux and a11y.
  6. Append " (sidebar contains error)" to the title attribute so that it appears in the tooltip text when hovering over the button.
  7. Include both icons in the clickable area of the button.

Remaining tasks

  1. Add a visual indicator to the toggle control.
  2. Create merge request.
  3. Add test.
  4. Refactor code to bust the render cache for the toggle button when there are validation errors in the advanced sidebar.
  5. Update test.
  6. Usability / UX review.
  7. Make the element uncacheable, possibly with a lazy builder as @berdir suggested in Slack (?)
  8. Take screenshots for the User interface changes section of the issue summary, performing any manual testing that's not covered by the UX review.
  9. Create change record (?)

User interface changes

Toggle control in normal, error, error plus hover, and error plus focus states.

New toggle button tooltip when hovered:

New markup (formatted for readability):

<a 
  class="meta-sidebar__trigger trigger has-error" 
  href="#toggle-sidebar" 
  role="button"
  title="Show sidebar panel (sidebar contains error)" 
  aria-controls="default_admin_sidebar"
  data-drupal-selector="edit-default-admin-sidebar-toggle" 
  data-once="adminSidebarToggle" 
  aria-expanded="false">
  <span
    class="visually-hidden" 
    data-drupal-selector="edit-text">
      Show sidebar panel (sidebar contains error)
    </span>
</a>

Introduced terminology

API changes

Data model changes

Release notes snippet

Issue fork drupal-3619387

Command icon Show commands

Start 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:

Comments

kentr created an issue. See original summary.

kentr’s picture

Issue summary: View changes
kentr’s picture

Issue summary: View changes
kentr’s picture

Title: [PP-1] Indicate that forms sidebar has child element errors for UX and a11y » Indicate that forms sidebar has child element errors for UX and a11y
Issue summary: View changes
StatusFileSize
new75.15 KB

It's actually not postponed on #2848507: Indicate that grouping elements have child element errors for ux and a11y.

Here's a screenshot of the toggle control from the issue fork. IMO it needs a non-color visual cue also.

kentr’s picture

Issue summary: View changes
kentr’s picture

Assigned: Unassigned » kentr
Issue summary: View changes
Status: Active » Needs work
Issue tags: +Needs tests, +Needs merge request
StatusFileSize
new22.79 KB

Added the error icon to the toggle control and screenshot of the control in different states.

Needs a test.

kentr’s picture

Assigned: kentr » Unassigned
kentr’s picture

Issue summary: View changes
kentr’s picture

Issue summary: View changes
Issue tags: +Needs usability review
kentr’s picture

Issue summary: View changes
mgifford’s picture

I started this and got interrupted too many times.

I think it is close to working now though. I think that the name of the show/hide button needs to stay the same (and indicate open or closed). I'm too tired to think about that now.

From AI...

Bundle is ready: /Users/mgifford/drupal-core/issue-3619387-review.zip (61 KB, 30 files).
What's inside:

  • 3619387-sidebar-errors-full.patch — standalone, uploadable full patch (vs branch base HEAD). Also copied as sidebar-errors-full.patch.
  • sidebar-errors-interdiff.patch — interdiff vs patches/core-a11y-aggregate-2026-07-20.patch. Helper.php is intentionally omitted because its has-error work is already in that aggregate; the interdiff is the delta beyond it (CSS, sidebar.js modal logic, FormHooks/PreprocessHooks changes, test).
  • sidebar-errors-comment.md — proposed issue-queue comment (with the required LLM disclosure line).
  • guidepup/ — sidebar-modal.voiceover.mjs (VoiceOver harness), README.md (install/run + diff before/after), ANALYSIS.md (expected before/after SR behavior).
  • src/ — copies of all 7 changed files for direct review without patching.
  • README.md — bundle index + local verify commands.

One caveat carried over from before: the live Guidepup/VoiceOver run can't execute inside this Linux container — the harness + expected analysis are ready, and you run node guidepup/sidebar-modal.voiceover.mjs on your macOS host (with VoiceOver automation enabled), twice (before/after), then diff the logs.

The working tree is unchanged (the temp baseline branch I used for the interdiff was deleted). Nothing is committed.

kentr’s picture

The UX team looked at this in the last meeting: #3618410: Drupal Usability Meeting 2026-08-28. Looks like the recording and transcript aren't up yet, but I listened in.

What I remember as far as their suggestions:

  1. Put the error icon at the "beginning" (logical inline start) of the toggle instead of at the end, so that the primary toggle icon doesn't move.
  2. Do add hidden text.
    IIRC they didn't have a specific suggestion for the text content, but they said it's a little weird with the changing verb in the accessible name.
    Removing the verb is currently part of #3619154: Accessibility fixes for Admin theme's sidebar toggle control.
    IMO, the error text should be somewhat consistent with the text added by #2848507: Indicate that grouping elements have child element errors for ux and a11y.

I'm working on implementing those suggestions.

Edit: Link to the recording.

kentr’s picture

Picking this back up.

kentr’s picture

Issue summary: View changes

kentr’s picture

Issue summary: View changes
Issue tags: -Needs merge request
kentr’s picture

Issue summary: View changes
StatusFileSize
new23.16 KB
kentr’s picture

Issue summary: View changes
kentr’s picture

Issue summary: View changes
kentr’s picture

Issue summary: View changes
kentr’s picture

Issue summary: View changes
kentr’s picture

Issue summary: View changes
kentr’s picture

Issue summary: View changes
kentr’s picture

kentr’s picture

Issue summary: View changes
kentr’s picture

Title: Indicate that forms sidebar has child element errors for UX and a11y » Indicate on forms sidebar toggle button that sidebar has child element errors
Issue summary: View changes
Issue tags: -Needs usability review +Needs screenshots, +Needs rebase
Related issues: +#3624663: Indicate in form error messages when error is sidebar

Usability review

The usability team discussed this issue in #3622319: Drupal Usability Meeting 2026-09-18. Link to the recording: https://youtu.be/oskSZahOIJs

@benjifisher asked me in the meeting to write a summary. I'm assuming that gives me the authority to remove the Needs usability review tag.

The attendees at the usability meeting were:

  • @benjifisher
  • @rkoller
  • @the_g_bomb
  • @simohell
  • @kentr

There were no concerns regarding the error indicators on the toggle button in this MR.

The usability team further recommends adding indicators to validation error messages in the top status message when the invalid field is in the advanced sidebar.

The reason is that the toggle button can be far away from the error message, so it may not be noticed by users who are focused on the error / status message. Without Inline Form Errors installed, the context is missing and the person has to search for where the error happened.

@benjifisher and @rkoller preferred that to be included in this issue, but also said it's acceptable for it to be a separate issue.

So that this issue and #2915899: [PP-1] Enable the Inline Form Errors module in the Standard profile and recipe can move faster, I opened #3624663: Indicate in form error messages when error is sidebar. The details are in the recording and will be in that issue.

Needs rebase and new screenshot(s) with the new focus outline from #3618140: Improve the accessibility of focus outlines.

kentr’s picture

Issue tags: -Needs rebase

Rebased. Working on the screenshots.

kentr’s picture

Issue summary: View changes
Issue tags: -Needs screenshots
StatusFileSize
new25.13 KB

I put a new screenshot in the issue summary.

kentr’s picture

Issue summary: View changes
kentr’s picture

Issue summary: View changes
kentr’s picture

Issue summary: View changes
Issue tags: +Usability
StatusFileSize
new18.38 KB
kentr’s picture

Status: Needs work » Needs review
kentr’s picture

Issue tags: +no-ai

No AI was used in the MR.

kentr’s picture

Issue tags: -no-ai +ai-ni

Not intentionally, anyway.

gwenweb’s picture

I tested on Drupal 11.4.8, PHP 8.4, macOS, Chrome (the changes appear to already be included in core 11.4.8).

What I tested:

  1. Opened /node/add/article with the default_admin theme active
  2. Closed the sidebar using the toggle button
  3. Filled in the Title field
  4. Opened the sidebar, entered an invalid URL alias (bad-alias, no leading slash)
  5. Closed the sidebar again
  6. Clicked Save

Result: The red error icon appeared correctly on the toggle button, and the title/accessible text updated to include "(sidebar contains error)". The feature works as described.

'max-age' => 0 still needs a decision before RTBC, I think.

error into sidebar

gwenweb’s picture

StatusFileSize
new360.53 KB
kentr’s picture

Thanks @gwenweb.

The feature works as described.

'max-age' => 0 still needs a decision before RTBC, I think.

I think you can still RTBC based on "The feature works as described.", if you are willing. That moves it forward for a committer to make a decision on it.

This is from Drupal's Life cycle of an issue page:

6. Once a fix has been proposed and passed automated testing, the next step is for a community member or maintainer to review and/or test the fix. The reviewer may approve of the fix and change the issue status to Reviewed and tested by the community, or (politely) request changes and change the issue status to Needs work. If the issue status is changed to Needs work, a community member needs to propose a new fix, so this sequence of steps is typically repeated multiple times except for the simplest issues.

7. The next step is a maintainer review of the fix. If the maintainer approves a software fix, they will commit the fix to the software repository and change the issue status to Fixed, or schedule the commit for a later time. The maintainer may also decide that the fix needs more work, and change the issue status to Needs work (in which case, a community member will need to propose a new fix, starting the fix/review cycle again).

gwenweb’s picture

Status: Needs review » Reviewed & tested by the community

Fine by me =)