datetime_wrapper improperly applied to DateTimeWidgetBase

Major because this is blocking #2161337: Add a Date Range field type with support for end date. Test demonstrating the issue to follow sometime tonight. To see it in action

- turn on twig debug
- add a datetime field to a node
- goto node/add/page
- view source, and you should see nested datetime_wrapper debug statements

Rather contrived test that shouldn't be in final version, but demonstrates the point. Best applied and run locally to see what is going on.

Didn't adjust the tests, or add a new assertion to prevent a regression, but here is a simple fix that works when I test manually.

Feedback appreciated.

Added usability tag to see if we actually regress the usability here (not trying to improve it, just not make things worse). Screenshot show nothing really changes:

And this is what 2161337-293 looks like with this patch applied:

I'll post before/after markup when I am back on my main dev machine tonight. Essentially, the after is that the field items get the `datetime_wrapper` markup, while the widget itself just gets the standard `form_element` markup. This avoids the situation where `datetime_wrapper` markup is nested inside iteself, and each of which gets preprocessed.

OK, with Twig debug on you can see the problem easily:

In this picture note that datetime_wrapper is being rendered twice, and nested, on the node/edit page for a single datetime field. The outer one is wrapping the whole widget, the inner one is wrapping the field inputs.

This shows the standard form element wrapping the widget, and a single datetime_wrapper wrapping the field inputs.

The before markup. Note the h4 masquerading as a label.

The after markup. Not the happy label for everything.

Posting the mess that you get with daterange next.

Note that this issue isn't trying to tackle the fieldset issue; that is over at #1918994: Improve Datetime and Daterange Widget accessibility. However, the work there is really messy because of the nested templates.

Here is a daterange field.

Blerg. A datetime_wrapper for the widget itself, which has two datetime_wrappers inside it, for the start and end dates.

The datetime_wrappers for start and end are inside the form_element.

Note the two H4 next to each other: one is the widget title and the other is the start label. This is what is causing the misalignment.

Happier.

So, in short, the latest patch may not be the proper or ideal fix, but the nest datetime wrappers are definitely causing problems.

In case anyone was holding off on reviewing this because it was NW, these should be passing tests.

Let's try assigning instead of the tag to try to break the logjam here.

@andrewmacpherson, we are looking for a quick accessibility review of this. Personally, I think we just want to make sure we are not regressing accessibility. Improvements can be handled in the related issue, #1918994: Improve Datetime and Daterange Widget accessibility.

Thanks.

Here is a stab at the comment. This applies cleanly to 8.3.x and 8.4.x.

@mgifford, are you suggesting we close this and do it all in #1918994: Improve Datetime and Daterange Widget accessibility instead?

Thanks @mgifford. I'll think about how we should handle this. The two main issues are the h4 is fine with datetime, but causes usability problems with daterange. The other, is that this and the other issue are critical path for daterange staying in core.

Since we have looped to accessibility issues, I think it is counterproductive to work on this and then work on them again #1918994: Improve Datetime and Daterange Widget accessibility, so I am closing this.