Enhance Calendar Date screen reader experience

[gerardo-rodriguez]

Summary

The Calendar Date is used by the Event Summary component. When reviewing https://github.com/cloudfour/cloudfour.com-wp/pull/644, @Paul-Hebert said:

I also found it a little weird having the talk duration inside of the larger date element. I wonder if it would be better if the date and duration were separate time elements? I'm not sure. Curious what other folks think.

I also agree we can enhance the experience a bit more.

Ideas

I'm not convinced we need two <time> elements, but it's worth exploring to understand what the screen reader experience is like.

I'd also be curious to explore using aria-hidden on the month abbreviation and day number, but keeping it off of the note. In theory, a screen reader like VoiceOver might read something like "3-day event starting on April 12, 2022".

We might also consider looking at the Author component which also uses the <time> element but makes some modifications to enhance the UX.

[tylersticka]

@gerardo-rodriguez @Paul-Hebert I appreciate your diligence looking for ways to improve accessibility. In this case, the current version was informed by discussions we had as a team back in April of 2020, so I'm not sure I agree with its prioritization.

To summarize our findings at that time:

• The original Calendar Date format was not descriptive enough when read aloud (especially when the date spanned across months).
• We originally attempted to add a duration to the datetime attribute, but apparently that attribute can do a date/time or a duration, but not both.
• We then explored adding a separate <time> element for either the end date or the duration, but both resulted in a slightly confusing experience because it wasn't clear that the elements were all joined together as a single date (it felt more like one Calendar Date might represent multiple events).
• To make matters more confusing, some screen readers seemed to read the more naturalistic text better, while some seemed to take the time element into consideration. Examples we found online often seemed to eschew semantic elements altogether, treating the event summary as merely text. Because of this, we opted for a bit more descriptive text than we had previously (though not as much as suggested in this description).

I'm going to keep this issue open for future improvements, but I'm going to remove it from the current project backlog so that we can focus on finishing things that haven't had as much thought put into them already. Let's talk with voices if you think I'm missing something critical. 🙂

[gerardo-rodriguez]

Okay, I've been doing some digging and a small bit of testing with NVDA + Firefox.

In my testing, NVDA + Firefox ignore the datetime attribute. 😞

VoiceOver + Safari will read whatever text is inside the <time> element and also read out the datetime attribute value. Seemed annoying at first, but we may have to leave it as-is otherwise, other screen readers (e.g., NVDA + Firefox) don't provide any helpful date info.

I've been looking for a source that validates my NVDA + Firefox test results but the only thing I can find is this comment from Scott O'Hara from November 2021:

if i recall correctly, the only screen reader that was doing anything here was VoiceOver. Where if someone specifies the datetime attribute, it would read that content and not the displayed text. haven't done recent testing, so no idea what else might be happening here.

This is disappointing, but I'll take a moment to think through what might be the best UX across these different results.

[gerardo-rodriguez]

In the a11y Slack #general channel, I found this comment from Adrian Roselli:

The datetime attribute is not for AT, it is a machine-readable format. It will not be exposed to SRs.

Then, Joe Schunk says:

The <time> element provides a machine readable approach to date/time. But I'm not aware of an accessibility API to map that to something consumed by the screen reader.

Finally, Diane Ko says:

FYI in case anyone's curious, I did just check the behavior of the <time> element across screen readers (https://cdpn.io/pen/debug/VwYGEEZ) and it seems like the only browser that exposes the datetime content is Safari. Possibly meaningful for iOS and macOS, but I do think formatting the time in a meaningful way for all users is the ideal