[Meta] Improve the accessibility of the Smart Date module

Created on 22 January 2025, 8 days ago

Problem/Motivation

The Drupal accessibility team have been considering the imminent release of Drupal CMS and we have agreed that it would be a good idea to assess the contrib modules that are going to get into Drupal CMS for accessibility issues #3475279: [Meta] Audit each module to be included into Drupal CMS for accessibility issues .

The testing was done with Drupal CMS 1.0 using the events recipe unsing Chrome on OSX 15.2 + VoiceOver. Testing did not cover all Smart Date features. Testing was done for the event default date field, a date field allowing multiple date ranges with date only and a single date range field with time and date.

It should be noted that on default date input on Chrome + VoiceOver reads the default values dd.mm.yyyy incorrectly as percentages. This will not be fixed in Drupal but in the browser https://issues.chromium.org/issues/361250561

Remaining tasks

  • Create detailed issues on the findings
  • Error messages are not announced, on error focus is set on an empty. Error message can appear visually 3 times in a field (wcag 3.3.1)
  • Error message is not shown in context and is vague (wcag 3.3.3)
  • Keyboard navigation does not follow visual order of items (wcag 2.4.3)
  • Input values may add on hide input elements (wcag 3.2.2)
  • Focus indicator is partially blocked by next input element. This is not a wcag violation, but fixing this is easy and recommended by the accessibility team.
  • Typing in a 5+ figure year to an empty date field results in inconsistent behaviour (maybe wcag 3.2.2)
🐛 Bug report
Status

Active

Version

4.2

Component

User interface

Created by

🇫🇮Finland simohell

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @simohell
  • 🇨🇦Canada mandclu

    @simohell thank you for the feedback. The Smart Date widget has been tested for accessibility before, but of course the field is always evolving.

    For each of the identified issues, would it be possible to have additional detail (ideally with a screen grab or highlighted code) on where the issue is exactly. A proposed fix would be ideal as well, or even a link to some documentation that discusses possible remediation approaches.

  • 🇫🇮Finland simohell

    Added the first child issue. I thing I could discuss the input-field order at Core UX weekly, since it's a little bit complex. Hiding and showing fields dynamically is sometimes a bit hard to do well. We don't want to move things too much but also to add new items in the correct place.

    If there is some background information on how the current implementation was decided on, it would be helpful.

Production build 0.71.5 2024