Datetime and Datelist elements should render as fieldsets

Created on 30 August 2019, over 5 years ago
Updated 18 July 2024, 5 months ago

Problem/Motivation

datetime-wrapper.html.twig element label uses an <h4> tag instead of the <label> tag.

This is problematic for assistive tech, since the "label" is not associated with anything.

For example, any node form in core has an "Authored on" datetime form element. The individual date and time inputs already have <label for>. For assistive tech, these are programmatically labelled as "date" and "time". However there's no programmatically-determinable association between these inputs and the phrase "authored on".

This <h4> also helps breaks #states support for datetime elements, but that's being addressed in 🐛 [PP-1] #states attribute does not work on #type datetime Postponed , not here.

Proposed resolution

Option A: Nested fieldsets:

Option A is now the agreed upon solution, with sign-off from @andrewmacpherson and @lauriii.

The "authored on" group would be improved by treating it as a fieldset with at legend, instead of a <h4>.

In the case of a single datetime field (Field API, datetime module) we already get a fieldset, using the the field name as a legend. The individual date and time inputs have <label for>, so screen reader users skipping through form elements will hear "preferred date, date" (for example). That's great for a single-value datetime field.

In the case of a datetime range field (datetime_range module), the field name is treated as a legend, but the start and end each have a h4 from the datetime-wrapper. This might be better with nested fieldsets (field_name (legend) > start date (legend) > date (label). Nested fieldsets are sometimes confusing for screen reader users though, so we'd want to tread carefully here.

Nested fieldsets would also be ugly and potentially confusing once 🐛 Fix label visibility and add wrapper container for exposed numeric/date filters with multiple form elements Fixed lands, too.

Nice thought, but rejected. See #27 for reference.

Remaining tasks

  1. Option A it is.
  2. Fix implementation to not generate duplicate IDs and other problems with patch #35
  3. Figure out how to properly deprecate the datetime-wrapper template + pipeline: 📌 Provide a mechanism to mark entire twig templates as deprecated Fixed
  4. Update / add tests as needed.
  5. Fix any accessibility concerns with nested fieldsets.
  6. Fix obvious visual stuff we can do to make this prettier by default.
  7. Reviews:
    • General implementation / code review
    • Needs accessibility review
    • Needs usability review
  8. Write change record about the render array changes, deprecation of the datetime-wrapper template, etc
  9. RTBC.
  10. Commit.
  11. Unblock 🐛 [PP-1] #states attribute does not work on #type datetime Postponed (which is thankfully mostly solved by this approach, but will need some follow-up fixes)

User interface changes

Definitely something. Exact changes TBD.

API changes

None.

Data model changes

None.

Release notes snippet

TBD.

Original report by @tormi

datetime-wrapper.html.twig element label uses <h4> tag instead of default <label> tag.

🐛 Bug report
Status

Needs work

Version

11.0 🔥

Component
Theme 

Last updated about 6 hours ago

Created by

🇪🇪Estonia tormi Tallinn

Live updates comments and jobs are added and updated live.
  • Accessibility

    It affects the ability of people with disabilities or special needs (such as blindness or color-blindness) to use Drupal.

  • Needs change record

    A change record needs to be drafted before an issue is committed. Note: Change records used to be called change notifications.

  • Needs accessibility review

    Used to alert the accessibility topic maintainer(s) that an issue significantly affects (or has the potential to affect) the accessibility of Drupal, and their signoff is needed (see the governance policy draft for more information). Useful links: Drupal's accessibility standards, the Drupal Core accessibility gate.

Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Merge request !3221Resolve #3078334 "Datetime datelist d10" → (Open) created by smustgrave
  • heddn Nicaragua

    Can we re-base the MR on 11.x?

  • last update over 1 year ago
    29,447 pass, 2 fail
  • 🇺🇸United States smustgrave

    Don't have time to actually rebase but updated target.

  • First commit to issue fork.
  • last update over 1 year ago
    30,056 pass, 2 fail
  • 🇫🇮Finland lauriii Finland

    I rebased the MR. It was not really possible at first because there were merge commits in the branch. Luckily it was pretty straight forward to get rid of the merged commits because there were no merge commits before the MR commits. I rangit reset --hard a9d6facb4e, where a9d6facb4e was the last commit before the commits that were introduced by the merge commit. After that I could run git rebase 11.x without any difficult conflicts to resolve.

    Thanks for the review @rkoller! I'm wondering if you've tested the experience before this patch? It would be helpful if we could figure out how the experience changes as the result of this issue, so that we know which issues needs to be tackles here, and which issues should be moved into their own bug reports.

    It looks like I mentioned this already in #38, but putting it again here for visibility. Instead of just removing the datetime_wrapper from drupal_common_theme(), we need to deprecate it. Unfortunately we haven't defined the steps for this 📌 Provide a mechanism to mark entire twig templates as deprecated Fixed so this is something we'd need to come up with.

  • Pipeline finished with Failed
    about 1 year ago
    #56324
  • First commit to issue fork.
  • Pipeline finished with Failed
    10 months ago
    Total: 167s
    #100923
  • Pipeline finished with Failed
    10 months ago
    Total: 514s
    #100926
  • 🇺🇸United States gcb

    Here's the current state of the MR as a patch file for stable use in composer builds. This applies for me on 10.2.4.

  • 🇯🇵Japan tyler36 Osaka

    Adding note on "current" behaviour for Drupal 10.2.5 with Claro admin theme.

    I have a custom entity with 2 fields:
    - BaseFieldDefinition::create('timestamp')
    - BaseFieldDefinition::create('timestamp')

    When rendering by Drupal\Core\Entity\ContentEntityForm, they appear as such:

    However, changin the definition to BaseFieldDefinition::create('datetime') and clearing the cache:

    Not sure if current MR/patch updates 'timestamp' too, but I would expect them to both display the same.

  • I've updated the patch for Drupal 10.3.1

Production build 0.71.5 2024