Datetime and Datelist elements should render as fieldsets

Created on 30 August 2019, almost 6 years ago
Updated 20 January 2023, over 2 years 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

10.1 โœจ

Component
Themeย  โ†’

Last updated 1 day 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.

Production build 0.71.5 2024