accessibility: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
m (added link to assistive technology)
(→‎External testimonials: added ATF post)
Line 13: Line 13:
*<code>tel</code> in [[hcard|hCard]]: use <code>style="speak-numeral:digits"</code>, so that telephone numbers are read by aural browsers as, for example, "five-five-five one-two-three-four" and not "five-hundred and fifty-five, one-thousand, two-hundred and thirty-two".
*<code>tel</code> in [[hcard|hCard]]: use <code>style="speak-numeral:digits"</code>, so that telephone numbers are read by aural browsers as, for example, "five-five-five one-two-three-four" and not "five-hundred and fifty-five, one-thousand, two-hundred and thirty-two".


==External testimonials==
==External references to Microformats and Accessibility==
* [http://lists.w3.org/Archives/Public/w3c-wai-ig/2006JulSep/subject.html#msg133 hCard and hCalendar Formats] - 2006-08-03 in w3c-wai-ig. e.g. <blockquote><p>I think Microformats.org is doing rather well on it's own, and it isn't particularly something that the W3C would or should get involved in until it's settled down. (And then it would just be a ratification kind of thing.)</p><p>...</p><p>In fact, it is likely to be good for accessibility, as the tools for consuming microformats often require valid code.</p></blockquote>
* [http://lists.w3.org/Archives/Public/w3c-wai-ig/2006JulSep/subject.html#msg133 hCard and hCalendar Formats] - 2006-08-03 in w3c-wai-ig. e.g. <blockquote><p>I think Microformats.org is doing rather well on it's own, and it isn't particularly something that the W3C would or should get involved in until it's settled down. (And then it would just be a ratification kind of thing.)</p><p>...</p><p>In fact, it is likely to be good for accessibility, as the tools for consuming microformats often require valid code.</p></blockquote>
* [http://www.webstandards.org/2007/04/27/haccessibility/ hAccessibility] - 2007-04-27 on WaSP buzz, <blockquote><p>The creators of Microformats strayed from their accessible, semantic intentions when they extended the abbr-design-pattern to the datetime-design-pattern. This idea, though paved with good intentions, was a workaround for a browser bug and, like many others, has unintended, harmful side effects.</p></blockquote>


==See also==
==See also==

Revision as of 20:13, 1 May 2007

Accessibility

This page documents microformats and accessibility in general, in particular advantages that adopting microformats provide for accessibility, and for documenting techniques for making microformats more accessible.

We should all strive to make our published microformats, parser implementations, and this wiki, accessible to all users, regardless of their physical abilities and needs, within the limits of the time and resources of the microformats community. Readers are advised to follow the W3C's Web Content Accessibility Guidelines 1.0, to at least level 2. Further advice is available on the Accessify Forums.

Advantages

Over and above the increased convenience they bring, some microformats have potential accessibility advantages.

hCard

  • tel in hCard: use style="speak-numeral:digits", so that telephone numbers are read by aural browsers as, for example, "five-five-five one-two-three-four" and not "five-hundred and fifty-five, one-thousand, two-hundred and thirty-two".

External references to Microformats and Accessibility

  • hCard and hCalendar Formats - 2006-08-03 in w3c-wai-ig. e.g.

    I think Microformats.org is doing rather well on it's own, and it isn't particularly something that the W3C would or should get involved in until it's settled down. (And then it would just be a ratification kind of thing.)

    ...

    In fact, it is likely to be good for accessibility, as the tools for consuming microformats often require valid code.

  • hAccessibility - 2007-04-27 on WaSP buzz,

    The creators of Microformats strayed from their accessible, semantic intentions when they extended the abbr-design-pattern to the datetime-design-pattern. This idea, though paved with good intentions, was a workaround for a browser bug and, like many others, has unintended, harmful side effects.

See also