AT support for datetime attribute?

[brennanyoung]

I was surprised (dismayed) to discover very little push for correct interpretation of the datetime attribute. Unlike (e.g.) aria-ssml, this attribute is widely supported by user agents, but has very little support (AFAICT) from AT vendors.

• How do we want datetime to relate to the HTML5 <time> element or the ARIA timer role?
• Should it override or support the text node inside the element?
• Is it reasonable (in these days of dawning AI) to expect AT vendors to inspect the text context around the time value and pronounce "00:00" as something other than "midnight"?
• datetime has a viable mechanism to distinguish between duration values and clock time, and between HH:MM and MM:SS. AT vendors do not do this (yet). Why is this not already normative? How do we make it so?

Full disclosure: I work in the medical simulation field. Given 200mg of morphine over "5:00"

200mg of morphine over 5 minutes is significantly different to 200mg of morphine over 5 hours.

[brennanyoung]

Looking through the draft spec, I notice date and time as suggested values for the data-ssml-say-as and interpret-as attributes.

How might we distinguish a duration value from a clock time? Will the "PT" prefix (from HTML5's datetime) be honoured? Does it deserve a mention in this spec? Has this been discussed?

Why/how is 'date' distinct from 'time'?

Spec for format and data-ssml-say-as-format says

Value: time/date format as defined in W3C

w3c has several documents which touch this, but AFAICT it makes no formal definition, except by referencing ISO

WHATWG's HTML5 spec is another one (non w3c), which specifies datetime format, including the duration prefix.

I am anxious that the pronunciation task force does not overlook this matter when specifying how date and time values are announced.

[AutoSponge]

@brennanyoung Great question.

SSML say-as date/time provides a mechanism to correctly parse the contents of the SSML tag into an aural presentation that more closely resembles how people talk about dates and times. It provides clarity to the reader of the date/time formats used when authoring to disambiguate the content. It takes into account the author's locale instead of the reader's. It also turns machine formats (e.g., 2011-11-18T14:54:39.929Z) into something more natural.

The <time> element provides a mechanism for machine readable dates and times to be attached to the element's content. This is the only way to convey meaning to relative dates. The correct pronunciation and what should be conveyed through AT would be the relative date (e.g., "yesterday").

I think both would still get used for their intended purpose but it may take better examples to clarify.

[AutoSponge]

[DRAFT RESPONSE]

Option 1:

Dates and times that fit the available formats of say-as can also be given machine-readable meaning via time.

<time datetime="2018-11-07" data-ssml='{"say-as":{"interpret-as":"date", "format"="dm"}}'>7-11</time>

Option 2:

say-as doesn't cover durations or time ranges. In this case, and cases where the content doesn't fit the prescribed format, we can use sub to provide additional info for a screen reader user or read aloud tool user without changing the experience in a Braille display.

<abbr data-ssml='{"sub":{"alias": "starting February 7, 2022 and ending February 11, 2022"}}' 
  title="Feb 7-Feb 11, 2022">
  Next week
</abbr>

pending counter example that may not work because the content wouldn't parse

[brennanyoung]

Thank you! I agree that some duration examples would be extremely helpful. It would keep the 'duration' use case on the radar of the AT vendors, and provide essential guidance for content authors.