see here http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#el-time

Please change the mapping from ATK_ROLE_TEXT to ATK_ROLE_STATIC. The latter role is new -- I'm discussing with the maintainer if we can backport it. Regardless, the new role should start showing up on [1] next week. (Apparently those docs regenerate whenever there is a new release. And the 2.15.2 tarballs are due Monday.) Proof in the meantime that the new role was added and that ATK_ROLE_TEXT is not the correct mapping can be found in this commit [2].

[1] https://developer.gnome.org/atk/unstable/AtkObject.html#AtkRole
[2] https://git.gnome.org/browse/atk/commit/?id=c6e623b3b

(In reply to Joanmarie Diggs from comment #2)
> Please change the mapping from ATK_ROLE_TEXT to ATK_ROLE_STATIC. The latter
> role is new -- I'm discussing with the maintainer if we can backport it.
> Regardless, the new role should start showing up on [1] next week.
> (Apparently those docs regenerate whenever there is a new release. And the
> 2.15.2 tarballs are due Monday.) Proof in the meantime that the new role was
> added and that ATK_ROLE_TEXT is not the correct mapping can be found in this
> commit [2].
> 
> [1] https://developer.gnome.org/atk/unstable/AtkObject.html#AtkRole
> [2] https://git.gnome.org/browse/atk/commit/?id=c6e623b3b

done: https://github.com/w3c/aria/commit/461394269403f6d377ae5f389f42a2003e8452db

Thanks!!! :) And we just mid-air collisioned. Sorry. The collision was:

=============
Oh, one more thing: The value should be exposed as the accessible name of the ATK_ROLE_STATIC accessible object.

Object attributes should be seen as a last resort rather than the preferred means to expose things. And if object attributes seem like the best means, that may suggest new API in ATK is called for. Because we're on a six-month release cycle (and really don't much care for the proliferation of object attributes), we will likely be able to accommodate requests for new API. All you have to do is ask. :)

(In reply to Joanmarie Diggs from comment #4)
> Thanks!!! :) And we just mid-air collisioned. Sorry. The collision was:
> 
> =============
> Oh, one more thing: The value should be exposed as the accessible name of
> the ATK_ROLE_STATIC accessible object.

can you provide spec text for how this should be defined?

(In reply to steve faulkner from comment #5)
> (In reply to Joanmarie Diggs from comment #4)
> > Thanks!!! :) And we just mid-air collisioned. Sorry. The collision was:
> > 
> > =============
> > Oh, one more thing: The value should be exposed as the accessible name of
> > the ATK_ROLE_STATIC accessible object.
> 
> can you provide spec text for how this should be defined?

You know, in this particular case, the description makes more sense. Because in the case of the time element, the time is clearly not a name. My bad on where it belongs. (Still doesn't make it an object attribute. :P :P) As for your question....

You currently have:

> "datetime" attribute on the containing time, text content used as a value

What about....

If the "datetime" attribute is present, the text content used as the value of the attribute should be exposed as the accessible description.

?

just in case, it seems like IA2 mapping is supposed to be (per Mozilla bug, see comment #0):

role: IA2_ROLE_TEXT_FRAME
object attributes: xml-roles: time, date-time: uservalue

Just noting that IA2 mapping for <time> in Firefox is IA2_ROLE_TEXT_FRAME
with the following object attributes:

xml-roles: time 
datetime: value of the <time> element's datetime attribute

Will ATK do the same, or will the <time> element's datetime attribute value be exposed as the accessible description?

Is it generally a good idea for mappings in different APIs to be consistent where possible? Is it reasonable in this case to do so?

Given that the datetime attribute's value can easily be something like "2006-09-24T05:00-07:00", does it make sense to expose this as the accessible description?

If so, shouldn't we do the same across the other applicable APIs?

(In reply to Jason Kiss from comment #8)
> Just noting that IA2 mapping for <time> in Firefox is IA2_ROLE_TEXT_FRAME
> with the following object attributes:
> 
> xml-roles: time 
> datetime: value of the <time> element's datetime attribute
> 
> Will ATK do the same, or will the <time> element's datetime attribute value
> be exposed as the accessible description?

That remains to be seen. ;)

> Is it generally a good idea for mappings in different APIs to be consistent
> where possible? Is it reasonable in this case to do so?

I suggested description for the following reasons:

1. Screen readers on all platforms already support presentation of descriptions.

2. Accessibility APIs on all platforms already support presentation of descriptions.

3. The likelihood that authors will manually put an ARIA description on the time element seems to me relatively small. Though maybe I'm wrong.

Taking the above into account, if value of datetime is exposed as the accessible description, presentation of the value will hopefully JustWork(tm) when the user performs whatever command or interaction that causes his/her screen reader to present descriptions.

On the flip side, exposing the datetime value as a very specific object attribute means that screen readers have to add custom logic to whatever code handles presentation of generic/static accessible objects just in case the generic/static object happens to be a time element (odds are, it isn't, but you can never be sure) that happens to have a datetime value.
 
> Given that the datetime attribute's value can easily be something like
> "2006-09-24T05:00-07:00", does it make sense to expose this as the
> accessible description?

That's a fair question. In the case of Orca, for non-focusable elements, the user has to perform the "where am I" command to get detailed information like the description. So Orca's not going to spew the above out without the user deliberately asking.

> If so, shouldn't we do the same across the other applicable APIs?

That remains to be seen. ;)

Mapping @datetime of time element into accessible description looks reasonable with me. We probably get some semantics loss though.

In Firefox both in IAccessible2 and ATK we expose @datetime as object attribute for a while. Here's some discussion and rationales of it [1].

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1095927

Thanks for that account, Joanmarie.

Makes sense to me. Seeing as Alexander also thinks it's reasonable, I propose
the following additional text for the various APIs:

MSAA + UIA Express: If the "datetime" attribute is present, expose its
value in the accDescription property.

MSAA + IAccessible2: If the "datetime" attribute is present, expose
its value in the accDescription property.

UIA: TBD (pending description mapping for UIA in AccName-AAM)

ATK/AT-SPI: If the "datetime" attribute is present, expose its value
in the description property of the accessible object.

AXAPI: If the "datetime" attribute is present, expose as string AXHelp.

Any concerns from anyone?

I think we should grab opinion from those who commented on original Mozilla bug, it'd be good to hear from Jamie and Steve.

Comment from Steve at Mozilla bug:
"My understanding is that the datetime object is a Machine-readable value and therefore not a good candidate for a default description."

(In reply to alexander surkov from comment #13)
> Comment from Steve at Mozilla bug:
> "My understanding is that the datetime object is a Machine-readable value
> and therefore not a good candidate for a default description."

If that is indeed the case, I'd question whether it should be exposed to ATs at all and withdraw my suggestion.

If end users should not be provided the value and there is some desire to expose it to ATs anyway (?), then go ahead and put it in an object attribute and Orca will ignore it.

As I understand it the time element contains human readable date value in text, @datetime is supposed to provide that value in parsable format. I guess that value can be still read to the user to get rid of any uncertainties about value given in text. Not sure it has to be read every time the user steps into the element.

(In reply to alexander surkov from comment #15)
> As I understand it the time element contains human readable date value in
> text, @datetime is supposed to provide that value in parsable format. I
> guess that value can be still read to the user to get rid of any
> uncertainties about value given in text. Not sure it has to be read every
> time the user steps into the element.

Which is why I suggested the description. Orca only automatically presents descriptions for non-focusable elements if the user asks for that description.

As for my previous comment:

Another possibility -- **if** ATs are expected to present the value after parsing it (??) -- might be to have the user agent do the parsing instead to turn it into a human-consumable value and expose that value to ATs to pass along to users.

And in that case (ATs are expected to present it, user agents are expected to expose human-consumable values to ATs), then having to go fetch that value from an object attribute strikes me as far less than ideal for the reasons I stated in comment 9.

Do we have any data how people use time element?

(In reply to alexander surkov from comment #17)
> Do we have any data how people use time element?

grep from recent collection of top 10,000 or so web site home pages

https://dl.dropboxusercontent.com/u/377471/time.html

I don't think the datetime attribute should be exposed as the description, as it's a machine-readable value (comment 13) and AT users shouldn't be consuming machine-readable values if other users don't. Also, AT users should generally be seeing the same text that any other user would see.

That said, there are a few (currently theoretical) use cases for exposing the datetie attribute in some other way:
1. It could be used as a hint to screen readers/TTS engines that the enclosed text is a date/time so it can be spoken correctly. However, this is more about the presence of the datetime attribute, not it sactual value. Also, given the number of date/time formats out there, this might not actually be that useful.
2. It could be used to disambiguate or abbreviate dates when the text isn't sufficient; e.g. there's some other visual presentation that somehow indicates part of the time. However, I'd argue this could also be useful for non-AT users and the browser should therefore format the time and display it as a tooltip, in which case the tooltip could be exposed as the description.

Long story short: I'm personally against datetime being exposed as description. I'm okay with it being exposed as an object attribute--it might be useful to someone some day--but I don't really care that much if it isn't.

Thanks, Jamie.

The idea of a browser-parsed human readable version of the datetime attribute available to all users (tooltip? what about sighted keyboard users?) and exposed as the description sounds kind of nice. 

What are folks' thoughts on this? If the idea is palatable, what's the next step? Since it's adding some additional work for browsers, I suspect we should be first gauging their appetite for implementing something like this?

If the idea's not so exciting, are we back to simply exposing the datetime value in an object attribute?

HTML AAM is no longer an ARIA Deliverable. If you wish to pursue this issue please file at https://github.com/w3c/html-aam/issues