Indicate that grouping elements have child element errors for UX and a11y

Problem/Motivation

The work here builds heavily on the discussion and work in #2848507: Indicate that grouping elements have child element errors for ux and a11y, so contributors to that issue should get credit in this one if they don't there.

Child elements in grouping elements like details and vertical tabs are invisible to the user when the grouping element is closed or not-active, respectively.

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

The forms sidebar has a similar problem: #3619387: Indicate on forms sidebar toggle button that sidebar has child element errors.

Steps to reproduce

1. In settings.php, set $settings['extension_discovery_scan_tests'] = TRUE.
2. Enable the core form_test module (drush en -y form_test).
3. Install the article test recipe (drush recipe core/tests/fixtures/recipes/article_content_type) or create an Article content type.
4. If necessary, set both the default and admin theme to Default Admin. Should not be necessary with this MR.
   (drush cset -y system.theme default default_admin && drush cset -y system.theme admin default_admin).
5. For "standard" details elements:
   1. Go to /form_test/details-contains-required-fields.
   2. Click the Submit button.
   3. Close one of the details elements for comparison.
6. For "accordion" style details elements on the node edit form:
   1. Go to /node/add/article.
   2. If the form sidebar on the right is closed, click the toggle button to open it.
   3. Enter a value without a beginning slash in the URL alias field.
   4. Click the Save button.
      This should cause a validation error: "The alias path has to start with a slash".
   5. Open the sidebar to see the invalid URL alias field.
7. For vertical tabs:
   1. Widen your viewport to at least 650px.
   2. Go to /admin/config/people/accounts.
   3. Within one or more tabs for the Emails configuration at the bottom of the form, remove the value for the required Subject field.
   4. Click the Save button.
   5. Click a tab which does not have an error to activate it.

For RTL, either:

• manually change the dir attribute on the html tag to rtl in the browser inspector / devtools, OR
• 1. Enable the Locale module (drush en -y locale).
  2. Add Hebrew as a language (/admin/config/regional/language/add).
  3. Repeat the above steps on the Hebrew version of the pages.

Proposed resolution

Based on discussion and work in #2848507: Indicate that grouping elements have child element errors for ux and a11y, and UX review of this MR:

1. Add a thick red solid border on one side of the grouping items that contain child errors.
2. Border width:
   var(--vertical-tabs-menu-link--active-border-size) + 2px, so that it is distinguishable from var(--vertical-tabs-menu-link--active-border-size).
3. Border position:
   Logical inline start of details element or vertical tab "menu item".
4. Border radius:
   Match the radius of the element to which the border is applied.
5. Add the error icon from the page-top error block to grouping elements.
6. Icon position:
   • Vertical: Vertically-centered with the first line of the element's visible label.
   • Horizontal: close to the logical inline end of the element's visible label.
7. Use red text color for the element's visible label.
8. Details elements:
   Surround the entire details element with a 1px solid red border.
9. Use the input error color for the red border / red text (var(--input--error-color)).
10. Vertical tabs:
    Use the input border color for the border of the active tab to so that it's clear when a tab with errors is also active.
11. Append visually-hidden " (child error)" to the element's visible label.
12. Add the attribute data-child-error-count to the details element.
    Because vertical tabs are progressively-enhanced details elements, the attribute will exist on the corresponding details element but not on the vertical tabs menu item (the li element).
    The value of the attribute should be an integer corresponding to the number of invalid children.
13. For the icon in forced-colors mode, use the mask-image property and canvasText background color.
    The UX team members and @mgifford brought up various forced-colors problems with vertical tabs, but they're out of scope. They were approved by the UX team and @mgifford to be followups.
    KentR made a note in #3081500-76: Accessibility bugs with vertical tabs.

Remaining tasks

1. Adapt work from #2848507: Indicate that grouping elements have child element errors for ux and a11y to Default Admin.
2. Create merge request.
3. Usability review.
4. Forced colors mode for icon.
5. Fix details error border position for RTL.
6. Manually test LTR, RTL, forced colors, and presence of hidden text for the following:
   1. Standard style details.
   2. Accordion style details (such as in advanced sidebar on node edit form).
   3. Vertical tabs on wider viewport (>= 650px). On narrow viewports they fall back to accordion style details.
7. Create change record.

User interface changes

• Visually, the grouping elements will indicate that there are errors inside.
• There will be a visually-hidden "(contains error)" appended to the summary or vertical tabs title for screen reader users.

Screenshots

Full color mode

LTR (left-to-right)

Scenario 1: Standard details (/form_test/details-contains-required-fields)

Scenario 2: Accordion style details (node edit form)

Scenario 3: Vertical tabs (/admin/config/people/accounts)

RTL (right-to-left)

Scenario 1: Standard details (/he/form_test/details-contains-required-fields)

Scenario 2: Accordion style details (node edit form)

URL alias without leading slash, Save, close "URL alias" details. Error indicator visible, no false positives on sibling details.

Scenario 3: Vertical tabs (/he/admin/config/people/accounts)

Forced-colors mode

LTR (left-to-right)

Scenario 1: Standard details (/form_test/details-contains-required-fields)

Scenario 2: Accordion style details (node edit form)

Scenario 3: Vertical tabs (/admin/config/people/accounts)

RTL (right-to-left)

Scenario 1: Standard details (/he/form_test/details-contains-required-fields)

Scenario 2: Accordion style details (node edit form)

Scenario 3: Vertical tabs (/admin/config/people/accounts)

Introduced terminology

API changes

Data model changes

Release notes snippet