Closed Bug 1095927 Opened 10 years ago Closed 10 years ago

expose HTML time element semantics in acc layer

Categories

(Core :: Disability Access APIs, defect)

Product:
Core
Component:
Disability Access APIs
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla37

People

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

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

patch
3.08 KB, patch
tbsaunde
: review+
Details | Diff | Splinter Review
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
Blocks: html5a11y
Component: Disability Access → Disability Access APIs
Product: Firefox → Core
Version: unspecified → Trunk
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?
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 different issue, it makes sense to have a separate bug on it, at least that'd be a place for discussions
(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.
So AT doesn't really need semantics of HTML:time?
(In reply to alexander :surkov from comment #7) > So AT doesn't really need semantics of HTML:time? which semantics, role or datetime?
(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.
(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.
(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
(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
(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.
(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?
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.
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.
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.
(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?
(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?
(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.
I'm fine with both date-time only and date-time + xml-roles
(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.
proposed mapping definition for time http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#el-time
(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
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
(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
(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
(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
Jamie, is IA2_ROLE_TEXT_FRAME suitable role for HTML time element?
(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.
Is there a point to name attribute as 'date-time' over no dash version?
Attached patch patch — — Splinter Review
Assignee: nobody → surkov.alexander
Attachment #8535174 - Flags: review?(tbsaunde+mozbugs)
(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
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla37
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
(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.

Attachment

General

Creator:
Created:
Updated:
Size: