expose HTML time element semantics in acc layer

RESOLVED FIXED in mozilla37

Status

()

Core
Disability Access APIs
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: steve faulkner, Assigned: surkov, Mentored)

Tracking

(Blocks: 1 bug)

Trunk
mozilla37
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
Investigating the mapping of the HTML5 time[1] element's semantics to acc APIs, potential benefit to AT users in identifying dates and times and access to machine readable date/time. idea arose out of current discussion thread on WAI-IG list [2]

strawman
xml-role:time
date-time: "string from datetime attribute"

any mileage in idea?

[1] http://www.w3.org/html/wg/drafts/html/master/text-level-semantics.html#the-time-element
[2] http://lists.w3.org/Archives/Public/w3c-wai-ig/2014OctDec/thread.html#first

Comment 1

3 years ago
...and if I may, details located here: http://lists.w3.org/Archives/Public/w3c-wai-ig/2014OctDec/0083.html
Blocks: 389237
Component: Disability Access → Disability Access APIs
Product: Firefox → Core
Version: unspecified → Trunk
(Assignee)

Comment 2

3 years ago
the easiest way is to follow Steve's suggestion and create an accessible object for time element to expose xml-roles and datetime object attribute. It'd be in spirit of what we did before (like HTML:abbr) but having extra accessibles for inlines is not nice approach in general, for example, we don't have accessible for HTML:b and others exposing those as text attributes. So it might be interesting idea to present HTML:time element as text attributes like "time:23 Jun 2013;"

Steve, do you know what MS wants for UIA?

Comment 3

3 years ago
Alexander & Marco, in addition to exposing this information to the accessibility APIs, there is I will argue a need for some UI changes - perhaps as a user setting. For example, I am Canadian living in the USA, and if I write 10/11/2014 do I mean October 11th or November 10th? This is a question that is not reserved for just users who tap into the AAPIs. I envision something along the lines of a tooltip or other pop-over that would disambiguate the iso 8601 date to a format that the end-user can choose. New bug, or an expansion of this one?
(Assignee)

Comment 4

3 years ago
it's a different issue, it makes sense to have a separate bug on it, at least that'd be a place for discussions

Comment 5

3 years ago
(In reply to steve faulkner from comment #0)
> potential benefit to AT users in identifying dates and times
I can see that being useful; e.g. we might use it as a hint to TTS engines that this piece of text should be handled as a date/time.
> and
> access to machine readable date/time.
While exposing this probably makes sense, my concern is that ATs will then be "expected" to use this data. With regard to a screen reader, it should really be reading the date/time in the form the author intended it to be read. For example, if the on-screen content was "1pm", a screen reader shouldn't go off and read "11 November 2014 1:00pm". Otherwise, the screen reader user could be getting an entirely different experience, which may not always be desirable.

(In reply to John Foliot from comment #3)
> there is I will argue a need for some UI changes -
> perhaps as a user setting. ... I
> envision something along the lines of a tooltip or other pop-over that would
> disambiguate the iso 8601 date to a format that the end-user can choose.
And this could then be made accessible by exposing this format via, say, the accessible description property. To me, this actually makes more sense for a screen reader than parsing the datetime attribute and is a more comparable experience for screen reader and non-screen reader users.
(In reply to John Foliot from comment #3)
> Alexander & Marco, in addition to exposing this information to the
> accessibility APIs, there is I will argue a need for some UI changes -
> perhaps as a user setting. For example, I am Canadian living in the USA, and
> if I write 10/11/2014 do I mean October 11th or November 10th? This is a
> question that is not reserved for just users who tap into the AAPIs. I
> envision something along the lines of a tooltip or other pop-over that would
> disambiguate the iso 8601 date to a format that the end-user can choose. New
> bug, or an expansion of this one?

It's a separate issue, but closely related, as Jamie points out above. I think the default should be that the evaluation is done via the operating system's date format setting. So if your operating system is set to mm/dd/yy, 11/10/14 would become November 10, 2014, if it is set to dd/mm/yy, it would become October 11, 2014. This information would then also be exposed to ATs. I think it would make sense to tie this to the OS date format setting because that would disambiguate automatically, e. g. you'd get the same behavior as if typing a date into Excel or some other software.
(Assignee)

Comment 7

3 years ago
So AT doesn't really need semantics of HTML:time?
(Reporter)

Comment 8

3 years ago
(In reply to alexander :surkov from comment #7)
> So AT doesn't really need semantics of HTML:time?

which semantics, role or datetime?
(Reporter)

Comment 9

3 years ago
(In reply to alexander :surkov from comment #7)
> So AT doesn't really need semantics of HTML:time?

james said:

>> potential benefit to AT users in identifying dates and times
>I can see that being useful; e.g. we might use it as a hint to TTS engines that this piece of text >should be handled as a date/time.
(Assignee)

Comment 10

3 years ago
(In reply to steve faulkner from comment #8)
> (In reply to alexander :surkov from comment #7)
> > So AT doesn't really need semantics of HTML:time?
> 
> which semantics, role or datetime?

I meant no semantics at all, just plain text, AT users has same piece of information as sighted user does. That's how I read Jamie's words.
(Assignee)

Comment 11

3 years ago
(In reply to steve faulkner from comment #9)
> (In reply to alexander :surkov from comment #7)
> > So AT doesn't really need semantics of HTML:time?
> 
> james said:
> 
> >> potential benefit to AT users in identifying dates and times
> >I can see that being useful; e.g. we might use it as a hint to TTS engines that this piece of text >should be handled as a date/time.

ok, I missed that. Would it be enough to expose it via text attributes for example "datetime" with no value

Comment 12

3 years ago
(In reply to Marco Zehe (:MarcoZ) from comment #6)
> 
> It's a separate issue, but closely related, as Jamie points out above. I
> think the default should be that the evaluation is done via the operating
> system's date format setting. So if your operating system is set to
> mm/dd/yy, 11/10/14 would become November 10, 2014, if it is set to dd/mm/yy,
> it would become October 11, 2014. 

But will it? There is some "transformation / translation" going on there, and is it known for certain (I don't know) that the OS will indeed transform 10 into October? Or will it simply render 10 as 10?


> This information would then also be
> exposed to ATs. I think it would make sense to tie this to the OS date
> format setting because that would disambiguate automatically, e. g. you'd
> get the same behavior as if typing a date into Excel or some other software.

We're thinking along the same lines, but is that function a function of the OS, or of the program (i.e. Excel)? I can reference a software program (WordPress) where as part of the admin settings you can choose your date format ({wordpress_site}/wp-admin/options-general.php)

At any rate, upon your advice I have filed a new bog / feature request, and have provided a suggestion on how it might be handled - FWIW. See: https://bugzilla.mozilla.org/show_bug.cgi?id=1096730

Comment 13

3 years ago
(In reply to alexander :surkov from comment #11)
> Would it be enough to expose it via text attributes for
> example "datetime" with no value
That's pretty ugly. :) If we were going to do that, I think I'd prefer "semantic:datetime" or something. Also, the second part of comment 5 (exposing human readable disambiguation via accessible description similar to abbr) requires a separate accessible anyway.

(In reply to alexander :surkov from comment #7)
> So AT doesn't really need semantics of HTML:time?
Well, I was arguing that screen readers should (by default) read the text as provided by the author, but that doesn't mean it couldn't be useful to other ATs or automation tools. Maybe it could even be useful for a screen reader in some cases; e.g. maybe the on-screen presentation is just too verbose, so there's an option to just read times in short form.
(Assignee)

Comment 14

3 years ago
(In reply to James Teh [:Jamie] from comment #13)
> (In reply to alexander :surkov from comment #11)
> > Would it be enough to expose it via text attributes for
> > example "datetime" with no value
> That's pretty ugly. :) If we were going to do that, I think I'd prefer
> "semantic:datetime" or something. Also, the second part of comment 5
> (exposing human readable disambiguation via accessible description similar
> to abbr) requires a separate accessible anyway.

so following Steve's approach (comment #0) is most flexible/reasonable one? What about proposed attribute names?

Comment 15

3 years ago
Aside from the overhead of getting it into APIs, is there any reason not to create a *real* accessible role for this? Using xml-roles here seems like a bit of a hack. The only counter-argument is if "time" is more of a secondary role (as is the case with landmarks); i.e. something could be both a button (which is more important) and a time. I don't think that's currently possible without overriding the role with ARIA, which starts to suggest that the author *intended* it to be overridden and not treated as a time.

As for the attribute name, datetime or date-time is fine with me.
(Assignee)

Comment 16

3 years ago
I think your button example is valid even if markup doesn't allow it yet and thus 'time' is rather attribute/characteristic of the accessible than its role. Having attributes xml-roles="button,time" and date-time="" object attributes on the accessible should be a good approach.

Comment 17

3 years ago
In that case, I'm starting to wonder whether we should bother with xml-roles at all. If it's really a characteristic and not a role, it might make more sense to just check for a date-time attribute to work out whether it's a time.
(Assignee)

Comment 18

3 years ago
(In reply to James Teh [:Jamie] from comment #17)
> In that case, I'm starting to wonder whether we should bother with xml-roles
> at all. If it's really a characteristic and not a role, it might make more
> sense to just check for a date-time attribute to work out whether it's a
> time.

so if the author doesn't provide date-time attribute for time element then what's expected value of date-time attribute should be (time element's content or empty?)

does date-time object attr only approach look flexible and nice?
(Reporter)

Comment 19

3 years ago
(In reply to James Teh [:Jamie] from comment #17)
> In that case, I'm starting to wonder whether we should bother with xml-roles
> at all. If it's really a characteristic and not a role, it might make more
> sense to just check for a date-time attribute to work out whether it's a
> time.

I thought the idea was that the time role could act as a hint to treat the content as a time or date?

Comment 20

3 years ago
(In reply to steve faulkner from comment #19)
> I thought the idea was that the time role could act as a hint to treat the
> content as a time or date?
Right, but the presence of the date-time attribute could do this also.

(In reply to alexander :surkov from comment #18)
> so if the author doesn't provide date-time attribute for time element
Hmm. I didn't think of that possibility. :(
> then
> what's expected value of date-time attribute should be (time element's
> content or empty?)
It's meant to be machine readable, so I would think it shouldn't ever contain an arbitrary value, so I guess empty. That does look a bit strange though.

I think I just dislike xml-roles. It's always seemed like a terrible hack to me, including its use for landmarks (but that's a discussion I've beaten to death already). If the consensus is to go for xml-roles and date-time, I'm not going to argue.
(Assignee)

Comment 21

3 years ago
I'm fine with both date-time only and date-time + xml-roles
(Reporter)

Comment 22

3 years ago

(In reply to James Teh [:Jamie] from comment #20)

> (In reply to alexander :surkov from comment #18)
> > so if the author doesn't provide date-time attribute for time element
> Hmm. I didn't think of that possibility. :(

I grepped a random set of 5000 web pages I collected a few months back and found there to be 4670 instances of <time> in 202 pages. roughly a quarter of the pages that included <time> did not include a datetime attribute.
the datetime attribute is optional in HTML5

"The datetime attribute may be present. If present, its value must be a representation of the element's contents in a machine-readable format."
http://www.w3.org/html/wg/drafts/html/master/text-level-semantics.html#the-time-element

So suggest it is worthwhile having xml-roles:time to identify the time element.
(Reporter)

Comment 23

3 years ago
proposed mapping definition for time http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#el-time

Comment 24

3 years ago
(In reply to steve faulkner from comment #23)
> proposed mapping definition for time
> http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#el-time

Not for ATK. We already have too many cases where ATK_ROLE_TEXT is being used in ways totally unexpected for our platform. Admittedly, the ATK documentation made this easy. As a result, we have recently updated our documentation. [1][2] Those documentation changes should appear in developer.gnome.org's pages Monday or Tuesday. In the meantime, let's not map more things to ATK_ROLE_TEXT.

Related note 1: For all the existing incorrect mappings to ATK_ROLE_TEXT, I'll be fixing them in WebKitGtk and filing bugs for Gecko so that the other HAAM can then be corrected and will have implementations already.

Related note 2: The only reason I saw this incorrect mapping is because I happened to see your email on the PFWG mailing list and CCed myself to this bug. Whenever you are going to propose mappings for my platform, please CC me. Thanks!

[1] https://git.gnome.org/browse/atk/commit/?id=c6e623b3b
[2] https://git.gnome.org/browse/at-spi2-core/commit/?id=9cbcd0aab2
(Reporter)

Comment 25

3 years ago
Hi Joanie, thanks!
Please review http://rawgit.com/w3c/aria/master/html-aam/html-aam.html at your leisure and file bugs where appropriate
https://www.w3.org/Bugs/Public/enter_bug.cgi?product=ARIA&component=HTML%20AAM
(Assignee)

Comment 26

3 years ago
(In reply to steve faulkner from comment #22)

> So suggest it is worthwhile having xml-roles:time to identify the time
> element.

the point was having date-time obj attr is enough to indentify time element
(Reporter)

Comment 27

3 years ago
(In reply to alexander :surkov from comment #26)
> (In reply to steve faulkner from comment #22)
> 
> > So suggest it is worthwhile having xml-roles:time to identify the time
> > element.
> 
> the point was having date-time obj attr is enough to indentify time element.

note that datetime attribute can also be applied to <ins> and <del>, and datetime is not always present on <time>, but please comment on the  spec bug as have ccd other people there https://www.w3.org/Bugs/Public/show_bug.cgi?id=27389
(Assignee)

Comment 28

3 years ago
(In reply to steve faulkner from comment #27)
> (In reply to alexander :surkov from comment #26)
> > (In reply to steve faulkner from comment #22)
> > 
> > > So suggest it is worthwhile having xml-roles:time to identify the time
> > > element.
> > 
> > the point was having date-time obj attr is enough to indentify time element.
> 
> note that datetime attribute can also be applied to <ins> and <del>
>, and
> datetime is not always present on <time>, 

ok, we don't expose it though
(Assignee)

Comment 29

3 years ago
Jamie, is IA2_ROLE_TEXT_FRAME suitable role for HTML time element?

Comment 30

3 years ago
(In reply to alexander :surkov from comment #29)
> Jamie, is IA2_ROLE_TEXT_FRAME suitable role for HTML time element?
Guess that makes sense, since it's a generic inline element with a secondary role.
(Assignee)

Comment 31

3 years ago
Is there a point to name attribute as 'date-time' over no dash version?
(Assignee)

Comment 32

3 years ago
Created attachment 8535174 [details] [diff] [review]
patch
Assignee: nobody → surkov.alexander
Attachment #8535174 - Flags: review?(tbsaunde+mozbugs)
(Reporter)

Comment 33

3 years ago
(In reply to alexander :surkov from comment #31)
> Is there a point to name attribute as 'date-time' over no dash version?

i don't see any reason to
Attachment #8535174 - Flags: review?(tbsaunde+mozbugs) → review+
https://hg.mozilla.org/mozilla-central/rev/360f9c19d50c
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla37
(Assignee)

Comment 35

3 years ago
HTML a11y guide is about to change a mapping from datetime object attribute to accessible description [1]. Are there disadvantages of the approach? Do object attribute benefit over accessible description?

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=27389
(Reporter)

Comment 36

3 years ago
(In reply to alexander :surkov from comment #35)
> HTML a11y guide is about to change a mapping from datetime object attribute
> to accessible description [1]. Are there disadvantages of the approach? Do
> object attribute benefit over accessible description?
> 
> [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=27389

My understanding is that the datetime object is a Machine-readable value and therefore not a good candidate for a default description.
You need to log in before you can comment on or make changes to this bug.