Use a WCAG-compliant fieldset (fieldgroup) for #type radios/checkboxes

Well, WAVE likes it:

This applies nicely. Still has that weird formatting issue:

Thanks @sun!

Great to see the CSS issue in Core.

This seems to work just fine. Just noticed that the CSS changes such that the Legend is in all caps. Rerolled adding text-transform: none;

.form-composite > legend,
h4.label {
  font-size: inherit;
  font-weight: bold;
  margin: 0;
  padding: 0;
  text-transform: none;
}

This looks great! I'm marking this RTBC. It does what needs to be done from an accessibility/semantic point of view.

Bumping priority. This is a critical issue if we want to comply with WCAG 2.0...

Critical for WCAG 2.0 AA, but not for the Drupal definition of Critical.

Committed/pushed to 8.x, thanks!

Ok, time for a little dance of joy! Thanks @catch. This has been a very long time coming!

@sun - really appreciate your efforts on both patches!

+++ b/core/includes/form.inc
@@ -1259,7 +1278,10 @@ function form_pre_render_conditional_form_element($element) {
-    $element['#theme_wrappers'][] = 'form_element';
...
+    $element['#theme_wrappers'][] = 'fieldset';

This means that if you are using template_preprocess_form_element or form-element.html.twig, you can affect all form elements, except checkboxes and radios.

I think this is a regression.

See #1493324: Inline form errors for accessibility and UX

Ok, so for now I'm bringing this back to Needs work. If this needs to be addressed in a new issue, fine.

I think this should be reverted until #2152209: Convert theme_fieldset() to Twig is resolved.

@tim.plunkett i've re-rolled theme_fieldset. Hope that help.

Please revert. Converting theme_fieldset needs to happen before this issue, so that radios and checkboxes are not turned into second class citizens.

Wanted to reference this issue that I was working on here to remove the theme_form_required_marker() and replace it with CSS.
#2152217: Remove theme_form_required_marker() from the theme system - use CSS instead

This has caused an important regression: #2236789: Styling of inline radios broken: inappropriate trailing colons (breaks EditorImageDialog).

Would #2275373: Add function for shared logic between fieldset and form element help for the problem mentioned in #15?

Or is what we need a different issue (title?) like "make template_preprocess_form_element or form-element.html.twig, affect all form elements, including checkboxes and radios" by ... I dont know what to write in the "by" part.

This issue and it's related spinoffs seems to be stalled. I'm not sure how to get us @YesCT I'm not sure how to move us beyond this.

Think we need direction from @sun & @tim.plunkett at this point.

Can we revert this, maybe there is a way we can get the form_element's tag to swap out or some other less invasive surgical array manipulations, but this seems to have hindered the inline error messages issue by quite a bit.

#1493324: Inline form errors for accessibility and UX

If I could only have one in 8.0.0. I'd choose good inline form errors over fieldsets for radios & checkboxes.

A considerable amount of work has gone into both, but better error messages will benefit everyone.

What is the technical reason why form errors can't be made to work with this patch?

See #15 for the problematic change. Instead of being treated like a form element, it is added to a fieldgroup. Form errors are for form elements. Making checkboxes and radios form elements would mean undoing the fieldgroup changes.

I see what you mean by form errors are for form elements.

Is there a nice way to still have the form_element theme wrapper and still end them up wrapped in a fieldset, or is that going to end up too hacky? (sorry for being lazy and not actually investigating for myself, but I figure someone has possibly already investigated it.)

I feel both these issues are important.

I believe last time we tried that, it ended up with two labels and descriptions, see #1493324-225: Inline form errors for accessibility and UX

Any chance that this problem changed now that #1493324: Inline form errors for accessibility and UX is in Core? There were over 300 comments between that post & the commit so hoping perhaps we won't still have two labels and descriptions with this approach to radios & checkboxes. A lot has changed since #9 though.

Looks it was commited

@andypost #36and #37 are automated messages, due to the branch/release automated changes and the commit in #13 http://cgit.drupalcode.org/drupal/commit/?id=2c7b99d from 2014-02-20

I'm not sure why it was set to needs review by @mgifford in #34

Maybe (the "new") https://www.drupal.org/governance/core can identify people who can clarify how this should be closed, and what issue is for the current work is (or a new issue for revert. It has probably too late to be a "revert" and would have to be new work (and an issue) to change it).

@YesCT - Probably Needs Work would be better. The code in #9 is way old.

This issue should never have been committed.
But after it was decided to not be reverted, it should have closed.

This issue has caused a massive amount of ripple effect through other issues, but they all adapted eventually. Let's just close this one out for good.