Microformats Wiki - User contributions [en]

accessibility-issues

2008-05-21T20:36:08Z

CharlesBelov: /* Issues */ changed span to abbr to reflect specific use of abbr tag in spec

<h1>accessibility issues</h1>

These are externally raised issues about [[accessibility]] with broadly varying degrees of merit. Thus some issues may be REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec.



Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — [http://tantek.com/ Tantek]

Please add new issues to the '''top''' of the list. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

__TOC__

== Issues ==
===hCalendar===
hCalendar specific accessibility issues. These are separated from the [[hcalendar-issues|hCalendar issues]] in general so that they are not lost among other non-accessibility related issues.

* {{OpenIssue}} 2007-01-20 raised by [[User:AndyMabbett|Andy Mabbett]]
*# ''Where <code>DTEND</code> is a date, and not a date-time, it is required to be the day after the end of the event, thus: <code><nowiki>
<abbr class="dtend" title="2007-04-30">29 April 2007</abbr></nowiki></code>. However, "29 April 2007" is '''''not''''' an abbreviation of 2007-04-30; it is an abbreviation of 2007-04-29. The markup as shown is semantically incorrect and likely to cause problems for users and user-agents which read the title attribute, and not the text value, of the <code>abbr</code> element.''

*{{OpenIssue}} 2006-12-11 raised by Andy Mabbett
*# ''The image in [[hcalendar-brainstorming#Photos and other attachments]] has inappropriate alt text, being just the file mname. [[User:AndyMabbett|Andy Mabbett]] 15:23, 6 Mar 2007 (PST)''

*{{OpenIssue}} 2008-05-21 raised by Charles Belov
*# ISO dates are not conceptually friendly to non-technical persons creating a web page manually.
*# An alternate encoding which I believe would be accessible would be as follows:
<pre>Monday, May 16, 2008, 2:31pm<abbr class="dtstart"
style="display:none" title="2008-05-16T14:31:00-0700"></abbr></pre>
[[User:CharlesBelov|Charles Belov]] 13:35, 21 May 2008 (PDT)

=== abbr-design-pattern ===
*{{OpenIssue}} 2007-04-27 raised by JamesCraig, BruceLawson.
*# ''Web Standards Project ATF article and discussion about why some instances of the [http://www.webstandards.org/2007/04/27/haccessibility/ abbr-design-pattern are bad for accessibility].'

*{{OpenIssue}} [http://www.accessifyforum.com/viewtopic.php?t=6167&postdays=0&postorder=asc&start=0 2006-09-20 raised by Andy Mabbett in accessifyforum]
*# ''Use of 'abbr' in microformats''

=== include-design-pattern ===
*{{OpenIssue}} 2007-04-28 raised by [[User:PatrickLauke|PatrickLauke]]
*# although nominally empty, [http://microformats.org/wiki/include-pattern-feedback#Hyperlink_Include_-_issues_for_keyboard_users_.28including_Screen_Reader_users.29 hyperlink includes still present in tab cycle of major browsers], proving to be a problem for keyboard users (including users of screen readers)
*# [http://microformats.org/wiki/include-pattern-feedback#Test_Results:_JAWS_7.0_with_Firefox_1.5.2FWin JAWS 7.0] testing not conclusive to ascertain compatibility in other major screen readers.

===Accessibility of this wiki===

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2006-11-26</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span>
<div class="description">
*# Large blocks of italic text are inaccessible to many readers, including people with types of visual impairment, dyslexia, etc. [http://www.intranet.man.ac.uk/accessibility/Disabilities/dyslexia.html], [https://tritonlink.ucsd.edu/portal/site/tritonlink-preview/menuitem.b4448692267a11256ec5e210514b01ca?storyID=20896]. [http://accessites.org/], [http://tlt.psu.edu/suggestions/accessibility/font.html], [http://www.wd4a.co.uk/Guidelines.htm]
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2006-12-11</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span>
<div class="description">
*# [http://microformats.org/wiki?title=page-summary-formats&diff=11222&oldid=11214 Duplicating link text] breaches [http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-meaningful-links WAI-WCAG 1 guideline 13.1 Clearly identify the target of each link] and is unhelpful to users of assistive technologies and other agents, which provide links in a stand-alone, out-of-context list.
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-01-14</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span>
<div class="description">
*# Inappropriate alt text, using file name as default, on images conveying information (e.g. [http://microformats.org/wiki?title=hcard-supporting-user-profiles&diff=next&oldid=24589]). Can editors specify alt text?</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-02-07</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span>
<div class="description">
*# The [http://microformats.org/wiki?title=hcard&diff=0&oldid=25600 use of "font-size:smaller" on superscript notes] is an accessibility barrier. Superscript is already smaller than the user's default preferred text size, and such links present a too-small target for people with visual disabilities and/ or motor-coordination problems to hit, even if they can read them. The Joe Clarke article cited in support of this change is not applicable; it refers to default font size for a page, and does not excuse making text smaller than that default. Even at default text size, single-character links are often too small for such users to "hit".
</div>
</div>

== Template ==
{{issues-format}}

== Resolved Issues ==
Issues that are resolved but may have outstanding [[to-do]] items.
* ...

== Closed Issues ==
Resolved issues that have no further actions to take.

*[http://lists.w3.org/Archives/Public/w3c-wai-ig/2006OctDec/0022.html 2006-10-06 raised by John Foliot in w3c-wai-ig]
*# ''<blockquote><p>What we don't need (IMHO) is a web where everything is simply a <div> with some extraneous Microformats style association added to it. </p></blockquote>''
** I'm not sure what the issue is here? the use of div elements is NOT an accessibility issue in itself, and microformats always advocate to use the most semantic element in the first place. The following email in that thread [http://lists.w3.org/Archives/Public/w3c-wai-ig/2006OctDec/0033.html 2006-10-06 Frances Berriman] answers the issue. [[User:Brian|brian]] 14:02, 13 Aug 2007 (UTC)

*2006-11-26 raised by Andy Mabbett
*# ''Using emboldening and italics to differentiate types on, e.g. the cheatsheet pages [[hcard-cheatsheet]], is unhelpful to users of assistive technologies, text-only devices, etc. A number, letter or symbol should additionally be used. [[User:AndyMabbett|Andy Mabbett]] 14:33, 26 Nov 2006 (PST)''
*#*I think the emboldening is fine as it marks up the required properties. The italics are a bit of a problem but keep it simple at the moment. Additional characters can’t be used as they would break the class="property" template. Colours would be a way but are inaccessible to some users, so there is no real solution to that problem for now. [[User:JulianStahnke|Julian Stahnke]] 22:55, 26 Nov 2006 (GMT)
*#**"I think the emboldening is fine" - how would you understand emboldening in a text-only browser like Lynx, or in an aural browser? [[User:AndyMabbett|Andy Mabbett]] 15:17, 26 Nov 2006 (PST)
*#***Ups, I just assumed that it would use strong and em tags. Yeah, well, let’s think about it. [[User:JulianStahnke|Julian Stahnke]] 23:22, 26 Nov 2006 (GMT)
*#*Of course, one could add that stuff ''after'' the class="property" thing. That might look a little cluttered though. I’ll consider that for the next revision/next cheat sheet I do. [[User:JulianStahnke|Julian Stahnke]] 22:57, 26 Nov 2006 (GMT)
*#**All that's needed is:
::::<nowiki>* class="vcard" (1)</nowiki>
::instead of:
::::<nowiki>* class="vcard"</nowiki>
:::[[User:AndyMabbett|Andy Mabbett]] 15:24, 26 Nov 2006 (PST)
*#*'''Now resolved'''. Thanks to all who helped. [[User:AndyMabbett|Andy Mabbett]] 10:30, 11 Dec 2006 (PST)

== See Also ==
* [[accessibility]]
* [[assistive-technology]]
* [[microformats-issues]]

accessibility-issues

2008-05-21T19:40:08Z

CharlesBelov: /* Issues */ Added ISO date entry accessibility issue

<h1>accessibility issues</h1>

These are externally raised issues about [[accessibility]] with broadly varying degrees of merit. Thus some issues may be REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec.



Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — [http://tantek.com/ Tantek]

Please add new issues to the '''top''' of the list. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

__TOC__

== Issues ==
===hCalendar===
hCalendar specific accessibility issues. These are separated from the [[hcalendar-issues|hCalendar issues]] in general so that they are not lost among other non-accessibility related issues.

* {{OpenIssue}} 2007-01-20 raised by [[User:AndyMabbett|Andy Mabbett]]
*# ''Where <code>DTEND</code> is a date, and not a date-time, it is required to be the day after the end of the event, thus: <code><nowiki>
<abbr class="dtend" title="2007-04-30">29 April 2007</abbr></nowiki></code>. However, "29 April 2007" is '''''not''''' an abbreviation of 2007-04-30; it is an abbreviation of 2007-04-29. The markup as shown is semantically incorrect and likely to cause problems for users and user-agents which read the title attribute, and not the text value, of the <code>abbr</code> element.''

*{{OpenIssue}} 2006-12-11 raised by Andy Mabbett
*# ''The image in [[hcalendar-brainstorming#Photos and other attachments]] has inappropriate alt text, being just the file mname. [[User:AndyMabbett|Andy Mabbett]] 15:23, 6 Mar 2007 (PST)''

*{{OpenIssue}} 2008-05-21 raised by Charles Belov
*# ISO dates are not conceptually friendly to non-technical persons creating a web page manually.
*# An alternate encoding which I believe would be accessible would be as follows:
<pre>Monday, May 16, 2008, 2:31pm<span class="dtstart"
style="display:none" title="2008-05-16T14:31:00-0700"></span></pre>
[[User:CharlesBelov|Charles Belov]] 12:36, 21 May 2008 (PDT)

=== abbr-design-pattern ===
*{{OpenIssue}} 2007-04-27 raised by JamesCraig, BruceLawson.
*# ''Web Standards Project ATF article and discussion about why some instances of the [http://www.webstandards.org/2007/04/27/haccessibility/ abbr-design-pattern are bad for accessibility].'

*{{OpenIssue}} [http://www.accessifyforum.com/viewtopic.php?t=6167&postdays=0&postorder=asc&start=0 2006-09-20 raised by Andy Mabbett in accessifyforum]
*# ''Use of 'abbr' in microformats''

=== include-design-pattern ===
*{{OpenIssue}} 2007-04-28 raised by [[User:PatrickLauke|PatrickLauke]]
*# although nominally empty, [http://microformats.org/wiki/include-pattern-feedback#Hyperlink_Include_-_issues_for_keyboard_users_.28including_Screen_Reader_users.29 hyperlink includes still present in tab cycle of major browsers], proving to be a problem for keyboard users (including users of screen readers)
*# [http://microformats.org/wiki/include-pattern-feedback#Test_Results:_JAWS_7.0_with_Firefox_1.5.2FWin JAWS 7.0] testing not conclusive to ascertain compatibility in other major screen readers.

===Accessibility of this wiki===

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2006-11-26</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span>
<div class="description">
*# Large blocks of italic text are inaccessible to many readers, including people with types of visual impairment, dyslexia, etc. [http://www.intranet.man.ac.uk/accessibility/Disabilities/dyslexia.html], [https://tritonlink.ucsd.edu/portal/site/tritonlink-preview/menuitem.b4448692267a11256ec5e210514b01ca?storyID=20896]. [http://accessites.org/], [http://tlt.psu.edu/suggestions/accessibility/font.html], [http://www.wd4a.co.uk/Guidelines.htm]
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2006-12-11</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span>
<div class="description">
*# [http://microformats.org/wiki?title=page-summary-formats&diff=11222&oldid=11214 Duplicating link text] breaches [http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-meaningful-links WAI-WCAG 1 guideline 13.1 Clearly identify the target of each link] and is unhelpful to users of assistive technologies and other agents, which provide links in a stand-alone, out-of-context list.
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-01-14</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span>
<div class="description">
*# Inappropriate alt text, using file name as default, on images conveying information (e.g. [http://microformats.org/wiki?title=hcard-supporting-user-profiles&diff=next&oldid=24589]). Can editors specify alt text?</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-02-07</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span>
<div class="description">
*# The [http://microformats.org/wiki?title=hcard&diff=0&oldid=25600 use of "font-size:smaller" on superscript notes] is an accessibility barrier. Superscript is already smaller than the user's default preferred text size, and such links present a too-small target for people with visual disabilities and/ or motor-coordination problems to hit, even if they can read them. The Joe Clarke article cited in support of this change is not applicable; it refers to default font size for a page, and does not excuse making text smaller than that default. Even at default text size, single-character links are often too small for such users to "hit".
</div>
</div>

== Template ==
{{issues-format}}

== Resolved Issues ==
Issues that are resolved but may have outstanding [[to-do]] items.
* ...

== Closed Issues ==
Resolved issues that have no further actions to take.

*[http://lists.w3.org/Archives/Public/w3c-wai-ig/2006OctDec/0022.html 2006-10-06 raised by John Foliot in w3c-wai-ig]
*# ''<blockquote><p>What we don't need (IMHO) is a web where everything is simply a <div> with some extraneous Microformats style association added to it. </p></blockquote>''
** I'm not sure what the issue is here? the use of div elements is NOT an accessibility issue in itself, and microformats always advocate to use the most semantic element in the first place. The following email in that thread [http://lists.w3.org/Archives/Public/w3c-wai-ig/2006OctDec/0033.html 2006-10-06 Frances Berriman] answers the issue. [[User:Brian|brian]] 14:02, 13 Aug 2007 (UTC)

*2006-11-26 raised by Andy Mabbett
*# ''Using emboldening and italics to differentiate types on, e.g. the cheatsheet pages [[hcard-cheatsheet]], is unhelpful to users of assistive technologies, text-only devices, etc. A number, letter or symbol should additionally be used. [[User:AndyMabbett|Andy Mabbett]] 14:33, 26 Nov 2006 (PST)''
*#*I think the emboldening is fine as it marks up the required properties. The italics are a bit of a problem but keep it simple at the moment. Additional characters can’t be used as they would break the class="property" template. Colours would be a way but are inaccessible to some users, so there is no real solution to that problem for now. [[User:JulianStahnke|Julian Stahnke]] 22:55, 26 Nov 2006 (GMT)
*#**"I think the emboldening is fine" - how would you understand emboldening in a text-only browser like Lynx, or in an aural browser? [[User:AndyMabbett|Andy Mabbett]] 15:17, 26 Nov 2006 (PST)
*#***Ups, I just assumed that it would use strong and em tags. Yeah, well, let’s think about it. [[User:JulianStahnke|Julian Stahnke]] 23:22, 26 Nov 2006 (GMT)
*#*Of course, one could add that stuff ''after'' the class="property" thing. That might look a little cluttered though. I’ll consider that for the next revision/next cheat sheet I do. [[User:JulianStahnke|Julian Stahnke]] 22:57, 26 Nov 2006 (GMT)
*#**All that's needed is:
::::<nowiki>* class="vcard" (1)</nowiki>
::instead of:
::::<nowiki>* class="vcard"</nowiki>
:::[[User:AndyMabbett|Andy Mabbett]] 15:24, 26 Nov 2006 (PST)
*#*'''Now resolved'''. Thanks to all who helped. [[User:AndyMabbett|Andy Mabbett]] 10:30, 11 Dec 2006 (PST)

== See Also ==
* [[accessibility]]
* [[assistive-technology]]
* [[microformats-issues]]

accessibility-issues

2008-05-21T19:35:15Z

CharlesBelov: /* Issues */ syntax correction

<h1>accessibility issues</h1>

These are externally raised issues about [[accessibility]] with broadly varying degrees of merit. Thus some issues may be REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec.



Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — [http://tantek.com/ Tantek]

Please add new issues to the '''top''' of the list. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

__TOC__

== Issues ==
===hCalendar===
hCalendar specific accessibility issues. These are separated from the [[hcalendar-issues|hCalendar issues]] in general so that they are not lost among other non-accessibility related issues.

* {{OpenIssue}} 2007-01-20 raised by [[User:AndyMabbett|Andy Mabbett]]
*# ''Where <code>DTEND</code> is a date, and not a date-time, it is required to be the day after the end of the event, thus: <code><nowiki>
<abbr class="dtend" title="2007-04-30">29 April 2007</abbr></nowiki></code>. However, "29 April 2007" is '''''not''''' an abbreviation of 2007-04-30; it is an abbreviation of 2007-04-29. The markup as shown is semantically incorrect and likely to cause problems for users and user-agents which read the title attribute, and not the text value, of the <code>abbr</code> element.''

*{{OpenIssue}} 2006-12-11 raised by Andy Mabbett
*# ''The image in [[hcalendar-brainstorming#Photos and other attachments]] has inappropriate alt text, being just the file mname. [[User:AndyMabbett|Andy Mabbett]] 15:23, 6 Mar 2007 (PST)''

*{{OpenIssue}} 2008-05-21 raised by Charles Belov
*# ''An alternate encoding which I believe would be accessible would be as follows:
<pre>Monday, May 16, 2008, 2:31pm<span class="dtstart"
style="display:none" title="2008-05-16T14:31:00-0700"></span></pre>
[[User:CharlesBelov|Charles Belov]] 12:27, 21 May 2008 (PDT)''

=== abbr-design-pattern ===
*{{OpenIssue}} 2007-04-27 raised by JamesCraig, BruceLawson.
*# ''Web Standards Project ATF article and discussion about why some instances of the [http://www.webstandards.org/2007/04/27/haccessibility/ abbr-design-pattern are bad for accessibility].'

*{{OpenIssue}} [http://www.accessifyforum.com/viewtopic.php?t=6167&postdays=0&postorder=asc&start=0 2006-09-20 raised by Andy Mabbett in accessifyforum]
*# ''Use of 'abbr' in microformats''

=== include-design-pattern ===
*{{OpenIssue}} 2007-04-28 raised by [[User:PatrickLauke|PatrickLauke]]
*# although nominally empty, [http://microformats.org/wiki/include-pattern-feedback#Hyperlink_Include_-_issues_for_keyboard_users_.28including_Screen_Reader_users.29 hyperlink includes still present in tab cycle of major browsers], proving to be a problem for keyboard users (including users of screen readers)
*# [http://microformats.org/wiki/include-pattern-feedback#Test_Results:_JAWS_7.0_with_Firefox_1.5.2FWin JAWS 7.0] testing not conclusive to ascertain compatibility in other major screen readers.

===Accessibility of this wiki===

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2006-11-26</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span>
<div class="description">
*# Large blocks of italic text are inaccessible to many readers, including people with types of visual impairment, dyslexia, etc. [http://www.intranet.man.ac.uk/accessibility/Disabilities/dyslexia.html], [https://tritonlink.ucsd.edu/portal/site/tritonlink-preview/menuitem.b4448692267a11256ec5e210514b01ca?storyID=20896]. [http://accessites.org/], [http://tlt.psu.edu/suggestions/accessibility/font.html], [http://www.wd4a.co.uk/Guidelines.htm]
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2006-12-11</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span>
<div class="description">
*# [http://microformats.org/wiki?title=page-summary-formats&diff=11222&oldid=11214 Duplicating link text] breaches [http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-meaningful-links WAI-WCAG 1 guideline 13.1 Clearly identify the target of each link] and is unhelpful to users of assistive technologies and other agents, which provide links in a stand-alone, out-of-context list.
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-01-14</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span>
<div class="description">
*# Inappropriate alt text, using file name as default, on images conveying information (e.g. [http://microformats.org/wiki?title=hcard-supporting-user-profiles&diff=next&oldid=24589]). Can editors specify alt text?</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-02-07</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span>
<div class="description">
*# The [http://microformats.org/wiki?title=hcard&diff=0&oldid=25600 use of "font-size:smaller" on superscript notes] is an accessibility barrier. Superscript is already smaller than the user's default preferred text size, and such links present a too-small target for people with visual disabilities and/ or motor-coordination problems to hit, even if they can read them. The Joe Clarke article cited in support of this change is not applicable; it refers to default font size for a page, and does not excuse making text smaller than that default. Even at default text size, single-character links are often too small for such users to "hit".
</div>
</div>

== Template ==
{{issues-format}}

== Resolved Issues ==
Issues that are resolved but may have outstanding [[to-do]] items.
* ...

== Closed Issues ==
Resolved issues that have no further actions to take.

*[http://lists.w3.org/Archives/Public/w3c-wai-ig/2006OctDec/0022.html 2006-10-06 raised by John Foliot in w3c-wai-ig]
*# ''<blockquote><p>What we don't need (IMHO) is a web where everything is simply a <div> with some extraneous Microformats style association added to it. </p></blockquote>''
** I'm not sure what the issue is here? the use of div elements is NOT an accessibility issue in itself, and microformats always advocate to use the most semantic element in the first place. The following email in that thread [http://lists.w3.org/Archives/Public/w3c-wai-ig/2006OctDec/0033.html 2006-10-06 Frances Berriman] answers the issue. [[User:Brian|brian]] 14:02, 13 Aug 2007 (UTC)

*2006-11-26 raised by Andy Mabbett
*# ''Using emboldening and italics to differentiate types on, e.g. the cheatsheet pages [[hcard-cheatsheet]], is unhelpful to users of assistive technologies, text-only devices, etc. A number, letter or symbol should additionally be used. [[User:AndyMabbett|Andy Mabbett]] 14:33, 26 Nov 2006 (PST)''
*#*I think the emboldening is fine as it marks up the required properties. The italics are a bit of a problem but keep it simple at the moment. Additional characters can’t be used as they would break the class="property" template. Colours would be a way but are inaccessible to some users, so there is no real solution to that problem for now. [[User:JulianStahnke|Julian Stahnke]] 22:55, 26 Nov 2006 (GMT)
*#**"I think the emboldening is fine" - how would you understand emboldening in a text-only browser like Lynx, or in an aural browser? [[User:AndyMabbett|Andy Mabbett]] 15:17, 26 Nov 2006 (PST)
*#***Ups, I just assumed that it would use strong and em tags. Yeah, well, let’s think about it. [[User:JulianStahnke|Julian Stahnke]] 23:22, 26 Nov 2006 (GMT)
*#*Of course, one could add that stuff ''after'' the class="property" thing. That might look a little cluttered though. I’ll consider that for the next revision/next cheat sheet I do. [[User:JulianStahnke|Julian Stahnke]] 22:57, 26 Nov 2006 (GMT)
*#**All that's needed is:
::::<nowiki>* class="vcard" (1)</nowiki>
::instead of:
::::<nowiki>* class="vcard"</nowiki>
:::[[User:AndyMabbett|Andy Mabbett]] 15:24, 26 Nov 2006 (PST)
*#*'''Now resolved'''. Thanks to all who helped. [[User:AndyMabbett|Andy Mabbett]] 10:30, 11 Dec 2006 (PST)

== See Also ==
* [[accessibility]]
* [[assistive-technology]]
* [[microformats-issues]]

accessibility-issues

2008-05-21T19:33:47Z

CharlesBelov: /* hCalendar */ Added possible accessibility solution

<h1>accessibility issues</h1>

These are externally raised issues about [[accessibility]] with broadly varying degrees of merit. Thus some issues may be REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec.



Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — [http://tantek.com/ Tantek]

Please add new issues to the '''top''' of the list. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

__TOC__

== Issues ==
===hCalendar===
hCalendar specific accessibility issues. These are separated from the [[hcalendar-issues|hCalendar issues]] in general so that they are not lost among other non-accessibility related issues.

* {{OpenIssue}} 2007-01-20 raised by [[User:AndyMabbett|Andy Mabbett]]
*# ''Where <code>DTEND</code> is a date, and not a date-time, it is required to be the day after the end of the event, thus: <code><nowiki>
<abbr class="dtend" title="2007-04-30">29 April 2007</abbr></nowiki></code>. However, "29 April 2007" is '''''not''''' an abbreviation of 2007-04-30; it is an abbreviation of 2007-04-29. The markup as shown is semantically incorrect and likely to cause problems for users and user-agents which read the title attribute, and not the text value, of the <code>abbr</code> element.''

*{{OpenIssue}} 2006-12-11 raised by Andy Mabbett
*# ''The image in [[hcalendar-brainstorming#Photos and other attachments]] has inappropriate alt text, being just the file mname. [[User:AndyMabbett|Andy Mabbett]] 15:23, 6 Mar 2007 (PST)''

*{{OpenIssue}} 2008-05-21 raised by Charles Belov
*# ''An alternate encoding which I believe would be accessible would be as follows:
<pre>Monday, May 16, 2008, 2:31pm<span class="dtstart"
style="display:none" title="2008-05-16T14:31:00-0700></span></pre>
[[User:CharlesBelov|Charles Belov]] 12:27, 21 May 2008 (PDT)''

=== abbr-design-pattern ===
*{{OpenIssue}} 2007-04-27 raised by JamesCraig, BruceLawson.
*# ''Web Standards Project ATF article and discussion about why some instances of the [http://www.webstandards.org/2007/04/27/haccessibility/ abbr-design-pattern are bad for accessibility].'

*{{OpenIssue}} [http://www.accessifyforum.com/viewtopic.php?t=6167&postdays=0&postorder=asc&start=0 2006-09-20 raised by Andy Mabbett in accessifyforum]
*# ''Use of 'abbr' in microformats''

=== include-design-pattern ===
*{{OpenIssue}} 2007-04-28 raised by [[User:PatrickLauke|PatrickLauke]]
*# although nominally empty, [http://microformats.org/wiki/include-pattern-feedback#Hyperlink_Include_-_issues_for_keyboard_users_.28including_Screen_Reader_users.29 hyperlink includes still present in tab cycle of major browsers], proving to be a problem for keyboard users (including users of screen readers)
*# [http://microformats.org/wiki/include-pattern-feedback#Test_Results:_JAWS_7.0_with_Firefox_1.5.2FWin JAWS 7.0] testing not conclusive to ascertain compatibility in other major screen readers.

===Accessibility of this wiki===

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2006-11-26</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span>
<div class="description">
*# Large blocks of italic text are inaccessible to many readers, including people with types of visual impairment, dyslexia, etc. [http://www.intranet.man.ac.uk/accessibility/Disabilities/dyslexia.html], [https://tritonlink.ucsd.edu/portal/site/tritonlink-preview/menuitem.b4448692267a11256ec5e210514b01ca?storyID=20896]. [http://accessites.org/], [http://tlt.psu.edu/suggestions/accessibility/font.html], [http://www.wd4a.co.uk/Guidelines.htm]
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2006-12-11</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span>
<div class="description">
*# [http://microformats.org/wiki?title=page-summary-formats&diff=11222&oldid=11214 Duplicating link text] breaches [http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-meaningful-links WAI-WCAG 1 guideline 13.1 Clearly identify the target of each link] and is unhelpful to users of assistive technologies and other agents, which provide links in a stand-alone, out-of-context list.
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-01-14</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span>
<div class="description">
*# Inappropriate alt text, using file name as default, on images conveying information (e.g. [http://microformats.org/wiki?title=hcard-supporting-user-profiles&diff=next&oldid=24589]). Can editors specify alt text?</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-02-07</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span>
<div class="description">
*# The [http://microformats.org/wiki?title=hcard&diff=0&oldid=25600 use of "font-size:smaller" on superscript notes] is an accessibility barrier. Superscript is already smaller than the user's default preferred text size, and such links present a too-small target for people with visual disabilities and/ or motor-coordination problems to hit, even if they can read them. The Joe Clarke article cited in support of this change is not applicable; it refers to default font size for a page, and does not excuse making text smaller than that default. Even at default text size, single-character links are often too small for such users to "hit".
</div>
</div>

== Template ==
{{issues-format}}

== Resolved Issues ==
Issues that are resolved but may have outstanding [[to-do]] items.
* ...

== Closed Issues ==
Resolved issues that have no further actions to take.

*[http://lists.w3.org/Archives/Public/w3c-wai-ig/2006OctDec/0022.html 2006-10-06 raised by John Foliot in w3c-wai-ig]
*# ''<blockquote><p>What we don't need (IMHO) is a web where everything is simply a <div> with some extraneous Microformats style association added to it. </p></blockquote>''
** I'm not sure what the issue is here? the use of div elements is NOT an accessibility issue in itself, and microformats always advocate to use the most semantic element in the first place. The following email in that thread [http://lists.w3.org/Archives/Public/w3c-wai-ig/2006OctDec/0033.html 2006-10-06 Frances Berriman] answers the issue. [[User:Brian|brian]] 14:02, 13 Aug 2007 (UTC)

*2006-11-26 raised by Andy Mabbett
*# ''Using emboldening and italics to differentiate types on, e.g. the cheatsheet pages [[hcard-cheatsheet]], is unhelpful to users of assistive technologies, text-only devices, etc. A number, letter or symbol should additionally be used. [[User:AndyMabbett|Andy Mabbett]] 14:33, 26 Nov 2006 (PST)''
*#*I think the emboldening is fine as it marks up the required properties. The italics are a bit of a problem but keep it simple at the moment. Additional characters can’t be used as they would break the class="property" template. Colours would be a way but are inaccessible to some users, so there is no real solution to that problem for now. [[User:JulianStahnke|Julian Stahnke]] 22:55, 26 Nov 2006 (GMT)
*#**"I think the emboldening is fine" - how would you understand emboldening in a text-only browser like Lynx, or in an aural browser? [[User:AndyMabbett|Andy Mabbett]] 15:17, 26 Nov 2006 (PST)
*#***Ups, I just assumed that it would use strong and em tags. Yeah, well, let’s think about it. [[User:JulianStahnke|Julian Stahnke]] 23:22, 26 Nov 2006 (GMT)
*#*Of course, one could add that stuff ''after'' the class="property" thing. That might look a little cluttered though. I’ll consider that for the next revision/next cheat sheet I do. [[User:JulianStahnke|Julian Stahnke]] 22:57, 26 Nov 2006 (GMT)
*#**All that's needed is:
::::<nowiki>* class="vcard" (1)</nowiki>
::instead of:
::::<nowiki>* class="vcard"</nowiki>
:::[[User:AndyMabbett|Andy Mabbett]] 15:24, 26 Nov 2006 (PST)
*#*'''Now resolved'''. Thanks to all who helped. [[User:AndyMabbett|Andy Mabbett]] 10:30, 11 Dec 2006 (PST)

== See Also ==
* [[accessibility]]
* [[assistive-technology]]
* [[microformats-issues]]

iso-8601

2008-05-12T22:31:07Z

CharlesBelov: /* Issues */ Added human-friendlyness issue for page creation

=ISO 8601=

The '''International Standards Organisation''''s standard, number '''8601''' is an international standard for date and time representations. It is used for all date-time representations in microformats.

==Overview==

For a plain-language overview of ISO 8601, we recommend the [http://www.cl.cam.ac.uk/~mgk25/iso-time.html ISO 8601 summary by Markus Kuhn].

==Microformats==

Microformats using ISO8601 include:

*[[hAtom]]
*[[hCalendar]]
*[[hCard]]
*[[hReview]]
*...

==<nowiki>RFC 3339</nowiki>==

RFC 3339 defines a profile of ISO 8601 for the use in Internet protocols and standards.

*It explicitly excludes durations and dates before the [http://en.wikipedia.org/wiki/Common_era common era].
*The more complex formats like week numbers and ordinal day are not permitted (see <nowiki>RFC 3339</nowiki>, section 5.6).

Microformats {{should}} use <nowiki>RFC 3339</nowiki>.

==Issues==
* How should dates before the common era be marked up? [[User:AndyMabbett|Andy Mabbett]]
* If a web page is created or edited by a non-technical human, it is unfriendly to expect them to work in ISO date format. [[User:CharlesBelov|Charles Belov]]

==See also==
*[http://en.wikipedia.org/wiki/ISO_8601 ISO 8601 on Wikipedia]
* [http://isotc.iso.org/livelink/livelink/4021199/ISO_8601_2004_E.zip?func=doc.Fetch&nodeid=4021199 ISO 8601:2004(E) from ISO] (zip-pdf, 228KB)
* [http://www.iso.org/iso/en/prods-services/popstds/datesandtime.html Summary of 8601 by ISO]
* [http://isotc.iso.org/livelink/livelink/fetch/2000/2122/138351/138352/customview.html?func=ll&objId=138352&objAction=browse&sort=name Technical Committee ISO/TC 154], Processes, data elements and documents in commerce, industry and administration.
* [http://www.phys.uu.nl/~vgent/calendar/isocalendar.htm The Mathematics of the ISO 8601 Calendar]
* [http://www.personal.ecu.edu/mccartyr/isowdcal.html Current date in '''week date''' and '''ordinal date''' format]
* [http://www.dmoz.org/Science/Reference/Standards/Individual_Standards/ISO_8601/ ISO 8601 at the Open Directory Project]
* [http://www.w3.org/TR/NOTE-datetime W3C Specification about UTC Date and Time] and IETF Internet standard <nowiki>RFC 3339</nowiki>, based on ISO 8601

==Related pages==
*[[datetime-design-pattern]]
*[[date-design-pattern]]
*[[abbr-design-pattern]]

datetime-design-pattern

2007-04-25T00:55:50Z

CharlesBelov: /* Discussion */ added question re annoyance factor

'''This page is a draft.'''

= Datetime Design Pattern =
This is a page for exploring a datetime design pattern.

== Purpose ==
* Use the [[datetime-design-pattern]] to make datetimes that are human readable also formally machine readable.

== Practical Need ==
* This design pattern arose as a result of solving the practical need for human readable dates for [[hcalendar|hCalendar]].

== How to use it ==
* enclose the human-friendly datetime that you want to make machine readable with <code><abbr></code>
* as per the [[class-design-pattern]], add the appropriate <code>class</code> attribute to the <code>abbr</code> element
* add a <code>title</code> attribute to the <code>abbr</code> element with the machine readable ISO8601 datetime or date as the value

== Current uses ==

'''note using these formats will mean your content will likely fail WCAG2.0 accessibility'''

The pattern which is now recommended in [[hcalendar|hCalendar]] and [[hreview|hReview]] is something like this:

<pre><abbr class="foo" title="YYYY-MM-DDTHH:MM:SS+ZZ:ZZ">Date Time</abbr></pre>

where foo is the semantic classname which is being applied to this date/time, the title of the <abbr> is an ISO 8601 date/time and "Date Time" is a human-friendly representation of the same date/time.

An alternative, if you are using UTC-based timestamps, would be:

<pre><abbr class="foo" title="YYYY-MM-DDTHH:MM:SSZ">Date Time</abbr></pre>

with a single "Z" as per [http://en.wikipedia.org/wiki/ISO_8601 ISO 8601]

== Profile of ISO8601 ==

We recommend that any [[microformat]] using the date-time-design pattern use a profile of ISO8601. There are currently two widely used profiles which SHOULD be reused.

* RFC 3339
* [http://www.w3.org/TR/NOTE-datetime W3C Note on Datetimes]

== Discussion ==

This pattern is likely to be highly resuable.

--[[User:RyanKing]]

Can this not be viewed as a microformat in itself?

--[[User:DimitriGlazkov]]

It could, but inventing a microformat for the sake of inventing a microformat is against the microformat principles.
If there is a specific real world problem (and uses cases) that such an elemental microformat would solve, then it would be worth considering.

Until then it is best to keep the <abbr> datetime concept merely as a microformat design pattern, to be used in _actual_ microformats that have a demonstrated practical need.

-- [http://tantek.com/log/ Tantek]

Excerpt from #microformats Aug 18th. Please edit!

<pre>
Aug 18 15:16:14 <Tantek> DanC, what do you think of RFC3339?
Aug 18 15:17:14 <Tantek> ISO8601 subset
Aug 18 15:17:19 <DanC> Date and Time on the Internet: Timestamps http://www.ietf.org/rfc/rfc3339.txt
Aug 18 15:17:30 <DanC> Klyne is a good guy. I wonder if I talked with him about this.
Aug 18 15:17:32 <Tantek> compat with W3C-NOTE-DATETIME
Aug 18 15:17:50 <Tantek> compat with xsd:dateTime
Aug 18 15:17:57 <Tantek> it's a strict intersection subset
Aug 18 15:17:59 <DanC> I consider W3C-NOTE-DATETIME obsoleted by XML Schema datatype-- yeah.. xsd:dateTime
Aug 18 15:18:32 <Tantek> compare/contrast normatively using xsd:dateTime vs. RFC3339
Aug 18 15:18:41 <Tantek> note: Atom 1.0 chose RFC3339
Aug 18 15:18:50 <Tantek> i would like input from the microformats community on this
Aug 18 15:19:27 <DanC> in what context are you evaluating RFC 3339?
Aug 18 15:19:28 <jcgregorio> http://bitworking.org/news/Date_Constructs_in_the_Atom_Syndication_Format
Aug 18 15:21:24 <DanC> which microformat is the question coming from, Tantek ?
Aug 18 15:23:31 <DanC> " The grammar element time-second may have the value "60" at the end of
Aug 18 15:23:31 <DanC> months in which a leap second occurs" The XML Schema WG is in the 27th level of
leap-second-hell for the past few months, I gather.
Aug 18 15:24:21 <DanC> yeah... here's the scary bit: " Leap seconds cannot be predicted far into the
future. The
Aug 18 15:24:21 <DanC> International Earth Rotation Service publishes bulletins [IERS] that
Aug 18 15:24:21 <DanC> announce leap seconds with a few weeks' warning."
Aug 18 15:26:03 <Tantek> DanC, which microformats? any/all that use datetime fields.
Aug 18 15:26:36 <DanC> hard to give useful advice, then.
Aug 18 15:26:58 <DanC> I expect they'll use datetime fields for different things that have different
cost/benefit trade-offs
Aug 18 15:27:26 <DanC> do you know of any particular differences that matter to anybody?
Aug 18 15:56:43 <KragenSitaker> RFC3339 suggests -07:00, which seems like an improvement over -0700 anyway
Aug 18 15:56:49 <Tantek> Kragen, agreed
Aug 18 15:57:01 <Tantek> RFC3339 is certainly preferable to the ISO8601 subset in iCalendar
Aug 18 16:05:57 <DanC> Tantek's right, Kragen; iCalendar looks like it solves the local timezone
problem but doesn't.
Aug 18 16:06:14 <DanC> and it's true that there's no standard solution to the local timezone problem
Aug 18 16:06:39 <Tantek> so instead of appearing to solve the problem but not solving it, we chose to
provide the ability to *approximate* the local timezone using e.g. "-07:00"
Aug 18 16:06:49 <DanC> the simplest thing is to have people use Z time in hCalendar. But I gather
that's unacceptably unusable?
Aug 18 16:07:35 <Tantek> DanC, yes, the simplest thing is to have everyone use UTC Z
Aug 18 16:07:38 <Tantek> However
Aug 18 16:07:50 <Tantek> it is not *nearly* as usuable/verifiable
Aug 18 16:07:55 <Tantek> as -07:00 etc.
Aug 18 16:08:02 <Tantek> hence the decision to go with the latter
Aug 18 16:08:12 <Tantek> some degree of human verifiability is important here
Aug 18 16:14:21 <Tantek> DanC, my perception is that RFC3339 is a subset
Aug 18 16:17:00 <DanC> time-numoffset = ("+" / "-") time-hour ":" time-minute
Aug 18 16:17:34 <DanC> ok, then I can't see any differences. (modulo recent leap seconds issues that
may affect xsd:dateTime )
Aug 18 16:18:07 <Tantek> would be interesting to know why Atom 1.0 chose RFC3339 over xsd:dateTime
Aug 18 16:18:21 <Tantek> if there was a "real" reason or if it was arbitrary / coin-flip.
</pre>

Here's an exhaustive [http://www.imc.org/atom-syntax/mail-archive/msg13103.html comparison] from ndw. I think xsd:dateTime also allows unqualified local times, while RFC3339 allows only UTC with no known timezone (-00:00). In the end, Atompub followed the advice of [http://www.imc.org/atom-syntax/mail-archive/msg13244.html Sam Ruby] and [http://www.imc.org/atom-syntax/mail-archive/msg13248.html Scott Hollenbeck], our area director. Atom dates make some additional restrictions on RFC3339, such as uppercase T and Z characters for compatibility with xsd:dateTime, RFC3339, W3C-DTF, and ISO8601. --[http://franklinmint.fm Robert Sayre]

<pre>
Aug 18 16:18:43 <KragenSitaker> rfc3339 is pretty short.
Aug 18 16:19:36 <Tantek> DanC, BTW, which came first? REC for xsd:dateTime or RFC3339?
Aug 18 16:19:50 <DanC> RFC3339 is dated July 2002 ...
Aug 18 16:19:54 <KragenSitaker> Right --- and you might be able to understand xsd:dateTime without
reading all of xml schema, you wouldn't be confident of it
Aug 18 16:20:25 <DanC> W3C Recommendation 28 October 2004 ... but that's 2nd ed...
Aug 18 16:20:47 <DanC> W3C Recommendation 02 May 2001
Aug 18 16:22:10 <DanC> I don't see a BNF in http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dateTime ...
Aug 18 16:22:43 <KragenSitaker> yeah, appendix D of the current xml schema datatypes document seems
a little scanty, actually
Aug 18 16:23:28 <DanC> ah... 2nd ed of http://www.w3.org/TR/xmlschema-2/#date is much more
explicit about syntax.
Aug 18 16:23:30 <KragenSitaker> it's 1100 words but still doesn't give any examples
Aug 18 16:23:35 <DanC> still, it's given in prose and not BNF
Aug 18 16:24:17 <KragenSitaker> sections 3.2.9 through 3.2.14 seem to be the relevant ones around #date
Aug 18 16:24:29 <KragenSitaker> which is another 2200 words
Aug 18 16:24:42 <DanC> wow... they changed the canonical form of date from always-Z to
timezone-allowed between 1st edition and 2nd edition
Aug 18 16:25:01 <Tantek> Kragen, DanC, these are very good analyses
Aug 18 16:25:21 <Tantek> could I ask you to summarize the pros/cons for each in a new section at
end of http://microformats.org/wiki/datetime-design-pattern
Aug 18 16:25:22 <Tantek> ?
Aug 18 16:25:58 <KragenSitaker> rfc 3339 is 4000 words, excluding the last two pages of boilerplate.
Aug 18 16:26:31 <KragenSitaker> so it's actually longer than the datetime-relevant parts of XSD but it
seems much more rigorous and clear
Aug 18 16:28:37 <DanC> my advice is: normatively cite both, and claim they specify the same
syntax, and let anybody who discovers otherwise send you a bug report
with a test case
Aug 18 16:29:12 <KragenSitaker> danc: nice hack
</pre>

The RFC3339 has a mandatory TIME portion of the DATE-TIME. Some vCard/iCalendar DATE-TIME stamps can omit the TIME. For instance, DTSTART, if that is a full day event, then you can omit the time. BDAY in vCard can be respresented by only a DATE. I like the idea of restricting the possible date formats, but i think that TIME should be optional, which it isn't in RFC3339. - [http://suda.co.uk/ brian suda]

RFC 3339 allows lowercase 't' and 'z' while XSD doesn't. Specifying RFC 3339 plus 'T' and 'Z' MUST be caps will make them the same. - [http://bitworking.org Joe Gregorio]

---

A few questions:

1) Would it make more sense for documenting the alternative codings pitting the abbr tag vs. other tags to be on this page?

2) Would using the title attribute of the abbr tag to encode the machine-readable date in fact cause a failure of WCAG 2.0 Accessibility? What about USA Section 508? It does appear to violate Technique for WCAG 2.0 [http://www.w3.org/TR/WCAG20-TECHS/#H28 H28: Providing definitions for abbreviations by using the abbr and acronym elements], although that is a supporting document and does not have the force of a guideline.

3) In order to maintain accessibility, would it make sense to enclose the machine-readable date in a span with a style of "display:none" instead of using the abbr tag?

4) For that matter, wouldn't you want to style such an abbr tag with text-decoration:none to hide that an abbr tag was used? Otherwise, visitors might cursor over the time, see the machine time, and be annoyed that their time was wasted or else be confused. And I don't think you can suppress the title from coming up if the human-readable time was inadvertently hovered.

[[User:CharlesBelov|CharlesBelov]] 16:57, 24 Apr 2007 (PDT)

== Code ==
The following regular expression (parsed VERBOSE) should break apart a datetime and cover many lightly broken cases seen in the wild. This has been tested under Python.

<pre><nowiki>
^
(?P<year>\d\d\d\d)
([-])?(?P<month>\d\d)
([-])?(?P<day>\d\d)
(
(T|\s+)
(?P<hour>\d\d)
(
([:])?(?P<minute>\d\d)
(
([:])?(?P<second>\d\d)
(
([.])?(?P<fraction>\d+)
)?
)?
)?
)?
(
(?P<tzzulu>Z)
|
(?P<tzoffset>[-+])
(?P<tzhour>\d\d)
([:])?(?P<tzminute>\d\d)
)?
$
</nowiki></pre>

== See Also ==

* [[Main_Page#Design_Patterns|All microformat design patterns]]
* [[abbr-design-pattern]] is used by [[datetime-design-pattern]]
* HTML 4.01 definition of <code><[http://www.w3.org/TR/REC-html40/struct/text.html#edef-ABBR abbr]></code> element
* RFC [http://www.faqs.org/rfcs/rfc3339.html 3339]: Date and Time on the Internet: Timestamps
* W3C: [http://www.w3.org/TR/NOTE-datetime Note on Datetimes]
* Markus Kuhn: [http://www.cl.cam.ac.uk/~mgk25/iso-time.html A summary of the international standard date and time notation]
* Wikipedia: [http://en.wikipedia.org/wiki/ISO_8601 ISO 8601]

datetime-design-pattern

2007-04-24T23:57:15Z

CharlesBelov: /* Discussion */ Added a few questions

'''This page is a draft.'''

= Datetime Design Pattern =
This is a page for exploring a datetime design pattern.

== Purpose ==
* Use the [[datetime-design-pattern]] to make datetimes that are human readable also formally machine readable.

== Practical Need ==
* This design pattern arose as a result of solving the practical need for human readable dates for [[hcalendar|hCalendar]].

== How to use it ==
* enclose the human-friendly datetime that you want to make machine readable with <code><abbr></code>
* as per the [[class-design-pattern]], add the appropriate <code>class</code> attribute to the <code>abbr</code> element
* add a <code>title</code> attribute to the <code>abbr</code> element with the machine readable ISO8601 datetime or date as the value

== Current uses ==

'''note using these formats will mean your content will likely fail WCAG2.0 accessibility'''

The pattern which is now recommended in [[hcalendar|hCalendar]] and [[hreview|hReview]] is something like this:

<pre><abbr class="foo" title="YYYY-MM-DDTHH:MM:SS+ZZ:ZZ">Date Time</abbr></pre>

where foo is the semantic classname which is being applied to this date/time, the title of the <abbr> is an ISO 8601 date/time and "Date Time" is a human-friendly representation of the same date/time.

An alternative, if you are using UTC-based timestamps, would be:

<pre><abbr class="foo" title="YYYY-MM-DDTHH:MM:SSZ">Date Time</abbr></pre>

with a single "Z" as per [http://en.wikipedia.org/wiki/ISO_8601 ISO 8601]

== Profile of ISO8601 ==

We recommend that any [[microformat]] using the date-time-design pattern use a profile of ISO8601. There are currently two widely used profiles which SHOULD be reused.

* RFC 3339
* [http://www.w3.org/TR/NOTE-datetime W3C Note on Datetimes]

== Discussion ==

This pattern is likely to be highly resuable.

--[[User:RyanKing]]

Can this not be viewed as a microformat in itself?

--[[User:DimitriGlazkov]]

It could, but inventing a microformat for the sake of inventing a microformat is against the microformat principles.
If there is a specific real world problem (and uses cases) that such an elemental microformat would solve, then it would be worth considering.

Until then it is best to keep the <abbr> datetime concept merely as a microformat design pattern, to be used in _actual_ microformats that have a demonstrated practical need.

-- [http://tantek.com/log/ Tantek]

Excerpt from #microformats Aug 18th. Please edit!

<pre>
Aug 18 15:16:14 <Tantek> DanC, what do you think of RFC3339?
Aug 18 15:17:14 <Tantek> ISO8601 subset
Aug 18 15:17:19 <DanC> Date and Time on the Internet: Timestamps http://www.ietf.org/rfc/rfc3339.txt
Aug 18 15:17:30 <DanC> Klyne is a good guy. I wonder if I talked with him about this.
Aug 18 15:17:32 <Tantek> compat with W3C-NOTE-DATETIME
Aug 18 15:17:50 <Tantek> compat with xsd:dateTime
Aug 18 15:17:57 <Tantek> it's a strict intersection subset
Aug 18 15:17:59 <DanC> I consider W3C-NOTE-DATETIME obsoleted by XML Schema datatype-- yeah.. xsd:dateTime
Aug 18 15:18:32 <Tantek> compare/contrast normatively using xsd:dateTime vs. RFC3339
Aug 18 15:18:41 <Tantek> note: Atom 1.0 chose RFC3339
Aug 18 15:18:50 <Tantek> i would like input from the microformats community on this
Aug 18 15:19:27 <DanC> in what context are you evaluating RFC 3339?
Aug 18 15:19:28 <jcgregorio> http://bitworking.org/news/Date_Constructs_in_the_Atom_Syndication_Format
Aug 18 15:21:24 <DanC> which microformat is the question coming from, Tantek ?
Aug 18 15:23:31 <DanC> " The grammar element time-second may have the value "60" at the end of
Aug 18 15:23:31 <DanC> months in which a leap second occurs" The XML Schema WG is in the 27th level of
leap-second-hell for the past few months, I gather.
Aug 18 15:24:21 <DanC> yeah... here's the scary bit: " Leap seconds cannot be predicted far into the
future. The
Aug 18 15:24:21 <DanC> International Earth Rotation Service publishes bulletins [IERS] that
Aug 18 15:24:21 <DanC> announce leap seconds with a few weeks' warning."
Aug 18 15:26:03 <Tantek> DanC, which microformats? any/all that use datetime fields.
Aug 18 15:26:36 <DanC> hard to give useful advice, then.
Aug 18 15:26:58 <DanC> I expect they'll use datetime fields for different things that have different
cost/benefit trade-offs
Aug 18 15:27:26 <DanC> do you know of any particular differences that matter to anybody?
Aug 18 15:56:43 <KragenSitaker> RFC3339 suggests -07:00, which seems like an improvement over -0700 anyway
Aug 18 15:56:49 <Tantek> Kragen, agreed
Aug 18 15:57:01 <Tantek> RFC3339 is certainly preferable to the ISO8601 subset in iCalendar
Aug 18 16:05:57 <DanC> Tantek's right, Kragen; iCalendar looks like it solves the local timezone
problem but doesn't.
Aug 18 16:06:14 <DanC> and it's true that there's no standard solution to the local timezone problem
Aug 18 16:06:39 <Tantek> so instead of appearing to solve the problem but not solving it, we chose to
provide the ability to *approximate* the local timezone using e.g. "-07:00"
Aug 18 16:06:49 <DanC> the simplest thing is to have people use Z time in hCalendar. But I gather
that's unacceptably unusable?
Aug 18 16:07:35 <Tantek> DanC, yes, the simplest thing is to have everyone use UTC Z
Aug 18 16:07:38 <Tantek> However
Aug 18 16:07:50 <Tantek> it is not *nearly* as usuable/verifiable
Aug 18 16:07:55 <Tantek> as -07:00 etc.
Aug 18 16:08:02 <Tantek> hence the decision to go with the latter
Aug 18 16:08:12 <Tantek> some degree of human verifiability is important here
Aug 18 16:14:21 <Tantek> DanC, my perception is that RFC3339 is a subset
Aug 18 16:17:00 <DanC> time-numoffset = ("+" / "-") time-hour ":" time-minute
Aug 18 16:17:34 <DanC> ok, then I can't see any differences. (modulo recent leap seconds issues that
may affect xsd:dateTime )
Aug 18 16:18:07 <Tantek> would be interesting to know why Atom 1.0 chose RFC3339 over xsd:dateTime
Aug 18 16:18:21 <Tantek> if there was a "real" reason or if it was arbitrary / coin-flip.
</pre>

Here's an exhaustive [http://www.imc.org/atom-syntax/mail-archive/msg13103.html comparison] from ndw. I think xsd:dateTime also allows unqualified local times, while RFC3339 allows only UTC with no known timezone (-00:00). In the end, Atompub followed the advice of [http://www.imc.org/atom-syntax/mail-archive/msg13244.html Sam Ruby] and [http://www.imc.org/atom-syntax/mail-archive/msg13248.html Scott Hollenbeck], our area director. Atom dates make some additional restrictions on RFC3339, such as uppercase T and Z characters for compatibility with xsd:dateTime, RFC3339, W3C-DTF, and ISO8601. --[http://franklinmint.fm Robert Sayre]

<pre>
Aug 18 16:18:43 <KragenSitaker> rfc3339 is pretty short.
Aug 18 16:19:36 <Tantek> DanC, BTW, which came first? REC for xsd:dateTime or RFC3339?
Aug 18 16:19:50 <DanC> RFC3339 is dated July 2002 ...
Aug 18 16:19:54 <KragenSitaker> Right --- and you might be able to understand xsd:dateTime without
reading all of xml schema, you wouldn't be confident of it
Aug 18 16:20:25 <DanC> W3C Recommendation 28 October 2004 ... but that's 2nd ed...
Aug 18 16:20:47 <DanC> W3C Recommendation 02 May 2001
Aug 18 16:22:10 <DanC> I don't see a BNF in http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dateTime ...
Aug 18 16:22:43 <KragenSitaker> yeah, appendix D of the current xml schema datatypes document seems
a little scanty, actually
Aug 18 16:23:28 <DanC> ah... 2nd ed of http://www.w3.org/TR/xmlschema-2/#date is much more
explicit about syntax.
Aug 18 16:23:30 <KragenSitaker> it's 1100 words but still doesn't give any examples
Aug 18 16:23:35 <DanC> still, it's given in prose and not BNF
Aug 18 16:24:17 <KragenSitaker> sections 3.2.9 through 3.2.14 seem to be the relevant ones around #date
Aug 18 16:24:29 <KragenSitaker> which is another 2200 words
Aug 18 16:24:42 <DanC> wow... they changed the canonical form of date from always-Z to
timezone-allowed between 1st edition and 2nd edition
Aug 18 16:25:01 <Tantek> Kragen, DanC, these are very good analyses
Aug 18 16:25:21 <Tantek> could I ask you to summarize the pros/cons for each in a new section at
end of http://microformats.org/wiki/datetime-design-pattern
Aug 18 16:25:22 <Tantek> ?
Aug 18 16:25:58 <KragenSitaker> rfc 3339 is 4000 words, excluding the last two pages of boilerplate.
Aug 18 16:26:31 <KragenSitaker> so it's actually longer than the datetime-relevant parts of XSD but it
seems much more rigorous and clear
Aug 18 16:28:37 <DanC> my advice is: normatively cite both, and claim they specify the same
syntax, and let anybody who discovers otherwise send you a bug report
with a test case
Aug 18 16:29:12 <KragenSitaker> danc: nice hack
</pre>

The RFC3339 has a mandatory TIME portion of the DATE-TIME. Some vCard/iCalendar DATE-TIME stamps can omit the TIME. For instance, DTSTART, if that is a full day event, then you can omit the time. BDAY in vCard can be respresented by only a DATE. I like the idea of restricting the possible date formats, but i think that TIME should be optional, which it isn't in RFC3339. - [http://suda.co.uk/ brian suda]

RFC 3339 allows lowercase 't' and 'z' while XSD doesn't. Specifying RFC 3339 plus 'T' and 'Z' MUST be caps will make them the same. - [http://bitworking.org Joe Gregorio]

---

A few questions:

1) Would it make more sense for documenting the alternative codings pitting the abbr tag vs. other tags to be on this page?

2) Would using the title attribute of the abbr tag to encode the machine-readable date in fact cause a failure of WCAG 2.0 Accessibility? What about USA Section 508? It does appear to violate Technique for WCAG 2.0 [http://www.w3.org/TR/WCAG20-TECHS/#H28 H28: Providing definitions for abbreviations by using the abbr and acronym elements], although that is a supporting document and does not have the force of a guideline.

3) In order to maintain accessibility, would it make sense to enclose the machine-readable date in a span with a style of "display:none" instead of using the abbr tag?

[[User:CharlesBelov|CharlesBelov]] 16:57, 24 Apr 2007 (PDT)

== Code ==
The following regular expression (parsed VERBOSE) should break apart a datetime and cover many lightly broken cases seen in the wild. This has been tested under Python.

<pre><nowiki>
^
(?P<year>\d\d\d\d)
([-])?(?P<month>\d\d)
([-])?(?P<day>\d\d)
(
(T|\s+)
(?P<hour>\d\d)
(
([:])?(?P<minute>\d\d)
(
([:])?(?P<second>\d\d)
(
([.])?(?P<fraction>\d+)
)?
)?
)?
)?
(
(?P<tzzulu>Z)
|
(?P<tzoffset>[-+])
(?P<tzhour>\d\d)
([:])?(?P<tzminute>\d\d)
)?
$
</nowiki></pre>

== See Also ==

* [[Main_Page#Design_Patterns|All microformat design patterns]]
* [[abbr-design-pattern]] is used by [[datetime-design-pattern]]
* HTML 4.01 definition of <code><[http://www.w3.org/TR/REC-html40/struct/text.html#edef-ABBR abbr]></code> element
* RFC [http://www.faqs.org/rfcs/rfc3339.html 3339]: Date and Time on the Internet: Timestamps
* W3C: [http://www.w3.org/TR/NOTE-datetime Note on Datetimes]
* Markus Kuhn: [http://www.cl.cam.ac.uk/~mgk25/iso-time.html A summary of the international standard date and time notation]
* Wikipedia: [http://en.wikipedia.org/wiki/ISO_8601 ISO 8601]

datetime-design-pattern

2007-04-24T23:19:51Z

CharlesBelov: Using <abbr> is recommended, not mandatory

'''This page is a draft.'''

= Datetime Design Pattern =
This is a page for exploring a datetime design pattern.

== Purpose ==
* Use the [[datetime-design-pattern]] to make datetimes that are human readable also formally machine readable.

== Practical Need ==
* This design pattern arose as a result of solving the practical need for human readable dates for [[hcalendar|hCalendar]].

== How to use it ==
* enclose the human-friendly datetime that you want to make machine readable with <code><abbr></code>
* as per the [[class-design-pattern]], add the appropriate <code>class</code> attribute to the <code>abbr</code> element
* add a <code>title</code> attribute to the <code>abbr</code> element with the machine readable ISO8601 datetime or date as the value

== Current uses ==

'''note using these formats will mean your content will likely fail WCAG2.0 accessibility'''

The pattern which is now recommended in [[hcalendar|hCalendar]] and [[hreview|hReview]] is something like this:

<pre><abbr class="foo" title="YYYY-MM-DDTHH:MM:SS+ZZ:ZZ">Date Time</abbr></pre>

where foo is the semantic classname which is being applied to this date/time, the title of the <abbr> is an ISO 8601 date/time and "Date Time" is a human-friendly representation of the same date/time.

An alternative, if you are using UTC-based timestamps, would be:

<pre><abbr class="foo" title="YYYY-MM-DDTHH:MM:SSZ">Date Time</abbr></pre>

with a single "Z" as per [http://en.wikipedia.org/wiki/ISO_8601 ISO 8601]

== Profile of ISO8601 ==

We recommend that any [[microformat]] using the date-time-design pattern use a profile of ISO8601. There are currently two widely used profiles which SHOULD be reused.

* RFC 3339
* [http://www.w3.org/TR/NOTE-datetime W3C Note on Datetimes]

== Discussion ==

This pattern is likely to be highly resuable.

--[[User:RyanKing]]

Can this not be viewed as a microformat in itself?

--[[User:DimitriGlazkov]]

It could, but inventing a microformat for the sake of inventing a microformat is against the microformat principles.
If there is a specific real world problem (and uses cases) that such an elemental microformat would solve, then it would be worth considering.

Until then it is best to keep the <abbr> datetime concept merely as a microformat design pattern, to be used in _actual_ microformats that have a demonstrated practical need.

-- [http://tantek.com/log/ Tantek]

Excerpt from #microformats Aug 18th. Please edit!

<pre>
Aug 18 15:16:14 <Tantek> DanC, what do you think of RFC3339?
Aug 18 15:17:14 <Tantek> ISO8601 subset
Aug 18 15:17:19 <DanC> Date and Time on the Internet: Timestamps http://www.ietf.org/rfc/rfc3339.txt
Aug 18 15:17:30 <DanC> Klyne is a good guy. I wonder if I talked with him about this.
Aug 18 15:17:32 <Tantek> compat with W3C-NOTE-DATETIME
Aug 18 15:17:50 <Tantek> compat with xsd:dateTime
Aug 18 15:17:57 <Tantek> it's a strict intersection subset
Aug 18 15:17:59 <DanC> I consider W3C-NOTE-DATETIME obsoleted by XML Schema datatype-- yeah.. xsd:dateTime
Aug 18 15:18:32 <Tantek> compare/contrast normatively using xsd:dateTime vs. RFC3339
Aug 18 15:18:41 <Tantek> note: Atom 1.0 chose RFC3339
Aug 18 15:18:50 <Tantek> i would like input from the microformats community on this
Aug 18 15:19:27 <DanC> in what context are you evaluating RFC 3339?
Aug 18 15:19:28 <jcgregorio> http://bitworking.org/news/Date_Constructs_in_the_Atom_Syndication_Format
Aug 18 15:21:24 <DanC> which microformat is the question coming from, Tantek ?
Aug 18 15:23:31 <DanC> " The grammar element time-second may have the value "60" at the end of
Aug 18 15:23:31 <DanC> months in which a leap second occurs" The XML Schema WG is in the 27th level of
leap-second-hell for the past few months, I gather.
Aug 18 15:24:21 <DanC> yeah... here's the scary bit: " Leap seconds cannot be predicted far into the
future. The
Aug 18 15:24:21 <DanC> International Earth Rotation Service publishes bulletins [IERS] that
Aug 18 15:24:21 <DanC> announce leap seconds with a few weeks' warning."
Aug 18 15:26:03 <Tantek> DanC, which microformats? any/all that use datetime fields.
Aug 18 15:26:36 <DanC> hard to give useful advice, then.
Aug 18 15:26:58 <DanC> I expect they'll use datetime fields for different things that have different
cost/benefit trade-offs
Aug 18 15:27:26 <DanC> do you know of any particular differences that matter to anybody?
Aug 18 15:56:43 <KragenSitaker> RFC3339 suggests -07:00, which seems like an improvement over -0700 anyway
Aug 18 15:56:49 <Tantek> Kragen, agreed
Aug 18 15:57:01 <Tantek> RFC3339 is certainly preferable to the ISO8601 subset in iCalendar
Aug 18 16:05:57 <DanC> Tantek's right, Kragen; iCalendar looks like it solves the local timezone
problem but doesn't.
Aug 18 16:06:14 <DanC> and it's true that there's no standard solution to the local timezone problem
Aug 18 16:06:39 <Tantek> so instead of appearing to solve the problem but not solving it, we chose to
provide the ability to *approximate* the local timezone using e.g. "-07:00"
Aug 18 16:06:49 <DanC> the simplest thing is to have people use Z time in hCalendar. But I gather
that's unacceptably unusable?
Aug 18 16:07:35 <Tantek> DanC, yes, the simplest thing is to have everyone use UTC Z
Aug 18 16:07:38 <Tantek> However
Aug 18 16:07:50 <Tantek> it is not *nearly* as usuable/verifiable
Aug 18 16:07:55 <Tantek> as -07:00 etc.
Aug 18 16:08:02 <Tantek> hence the decision to go with the latter
Aug 18 16:08:12 <Tantek> some degree of human verifiability is important here
Aug 18 16:14:21 <Tantek> DanC, my perception is that RFC3339 is a subset
Aug 18 16:17:00 <DanC> time-numoffset = ("+" / "-") time-hour ":" time-minute
Aug 18 16:17:34 <DanC> ok, then I can't see any differences. (modulo recent leap seconds issues that
may affect xsd:dateTime )
Aug 18 16:18:07 <Tantek> would be interesting to know why Atom 1.0 chose RFC3339 over xsd:dateTime
Aug 18 16:18:21 <Tantek> if there was a "real" reason or if it was arbitrary / coin-flip.
</pre>

Here's an exhaustive [http://www.imc.org/atom-syntax/mail-archive/msg13103.html comparison] from ndw. I think xsd:dateTime also allows unqualified local times, while RFC3339 allows only UTC with no known timezone (-00:00). In the end, Atompub followed the advice of [http://www.imc.org/atom-syntax/mail-archive/msg13244.html Sam Ruby] and [http://www.imc.org/atom-syntax/mail-archive/msg13248.html Scott Hollenbeck], our area director. Atom dates make some additional restrictions on RFC3339, such as uppercase T and Z characters for compatibility with xsd:dateTime, RFC3339, W3C-DTF, and ISO8601. --[http://franklinmint.fm Robert Sayre]

<pre>
Aug 18 16:18:43 <KragenSitaker> rfc3339 is pretty short.
Aug 18 16:19:36 <Tantek> DanC, BTW, which came first? REC for xsd:dateTime or RFC3339?
Aug 18 16:19:50 <DanC> RFC3339 is dated July 2002 ...
Aug 18 16:19:54 <KragenSitaker> Right --- and you might be able to understand xsd:dateTime without
reading all of xml schema, you wouldn't be confident of it
Aug 18 16:20:25 <DanC> W3C Recommendation 28 October 2004 ... but that's 2nd ed...
Aug 18 16:20:47 <DanC> W3C Recommendation 02 May 2001
Aug 18 16:22:10 <DanC> I don't see a BNF in http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dateTime ...
Aug 18 16:22:43 <KragenSitaker> yeah, appendix D of the current xml schema datatypes document seems
a little scanty, actually
Aug 18 16:23:28 <DanC> ah... 2nd ed of http://www.w3.org/TR/xmlschema-2/#date is much more
explicit about syntax.
Aug 18 16:23:30 <KragenSitaker> it's 1100 words but still doesn't give any examples
Aug 18 16:23:35 <DanC> still, it's given in prose and not BNF
Aug 18 16:24:17 <KragenSitaker> sections 3.2.9 through 3.2.14 seem to be the relevant ones around #date
Aug 18 16:24:29 <KragenSitaker> which is another 2200 words
Aug 18 16:24:42 <DanC> wow... they changed the canonical form of date from always-Z to
timezone-allowed between 1st edition and 2nd edition
Aug 18 16:25:01 <Tantek> Kragen, DanC, these are very good analyses
Aug 18 16:25:21 <Tantek> could I ask you to summarize the pros/cons for each in a new section at
end of http://microformats.org/wiki/datetime-design-pattern
Aug 18 16:25:22 <Tantek> ?
Aug 18 16:25:58 <KragenSitaker> rfc 3339 is 4000 words, excluding the last two pages of boilerplate.
Aug 18 16:26:31 <KragenSitaker> so it's actually longer than the datetime-relevant parts of XSD but it
seems much more rigorous and clear
Aug 18 16:28:37 <DanC> my advice is: normatively cite both, and claim they specify the same
syntax, and let anybody who discovers otherwise send you a bug report
with a test case
Aug 18 16:29:12 <KragenSitaker> danc: nice hack
</pre>

The RFC3339 has a mandatory TIME portion of the DATE-TIME. Some vCard/iCalendar DATE-TIME stamps can omit the TIME. For instance, DTSTART, if that is a full day event, then you can omit the time. BDAY in vCard can be respresented by only a DATE. I like the idea of restricting the possible date formats, but i think that TIME should be optional, which it isn't in RFC3339. - [http://suda.co.uk/ brian suda]

RFC 3339 allows lowercase 't' and 'z' while XSD doesn't. Specifying RFC 3339 plus 'T' and 'Z' MUST be caps will make them the same. - [http://bitworking.org Joe Gregorio]

== Code ==
The following regular expression (parsed VERBOSE) should break apart a datetime and cover many lightly broken cases seen in the wild. This has been tested under Python.

<pre><nowiki>
^
(?P<year>\d\d\d\d)
([-])?(?P<month>\d\d)
([-])?(?P<day>\d\d)
(
(T|\s+)
(?P<hour>\d\d)
(
([:])?(?P<minute>\d\d)
(
([:])?(?P<second>\d\d)
(
([.])?(?P<fraction>\d+)
)?
)?
)?
)?
(
(?P<tzzulu>Z)
|
(?P<tzoffset>[-+])
(?P<tzhour>\d\d)
([:])?(?P<tzminute>\d\d)
)?
$
</nowiki></pre>

== See Also ==

* [[Main_Page#Design_Patterns|All microformat design patterns]]
* [[abbr-design-pattern]] is used by [[datetime-design-pattern]]
* HTML 4.01 definition of <code><[http://www.w3.org/TR/REC-html40/struct/text.html#edef-ABBR abbr]></code> element
* RFC [http://www.faqs.org/rfcs/rfc3339.html 3339]: Date and Time on the Internet: Timestamps
* W3C: [http://www.w3.org/TR/NOTE-datetime Note on Datetimes]
* Markus Kuhn: [http://www.cl.cam.ac.uk/~mgk25/iso-time.html A summary of the international standard date and time notation]
* Wikipedia: [http://en.wikipedia.org/wiki/ISO_8601 ISO 8601]