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.

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 [http://www.w3.org/TR/WCAG10/ W3C's Web Content Accessibility Guidelines 1.0], to at least level 2. Further advice is available on the [http://www.accessifyforum.com/ Accessify Forums].

+

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 [http://www.w3.org/TR/WCAG20/ W3C's Web Content Accessibility Guidelines 2.0], to at least Level AA. Further advice is available on the [http://www.accessifyforum.com/ Accessify Forums].

__TOC__

__TOC__

Line 12:

Line 12:

===hCard===

===hCard===

*<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".

-

**Note: This is not an advantage to Microformats. It is a CSS best practice and can be used with or without hCard. This should probably be moved to a [[css-best-practices|CSS Best Practices]] page. - JamesCraig

+

**Note: This is not an advantage to Microformats. It is a CSS best practice and can be used with or without hCard. This should probably be moved to a [[css-best-practices|CSS Best Practices]] page. - [[User:JamesCraig|James Craig]]

****It is not an advantage of microformats; it is just CSS that can be used on any class, whether or not it happens to be ''tel''. There is no documented AT implementation that recognizes Microformats classes automatically. This is just a benefit of CSS, with or without uF. [[User:JamesCraig|James Craig]]

+

*****It is '''an advantage of microformats'''; because using "tel" in hCard requites people to mark up telephone numbers semantically, where they otherwise might not. No claim about AT implementations is being made. [[User:AndyMabbett|Andy Mabbett]] 01:04, 28 Jan 2008 (PST)

==Disadvantages==

==Disadvantages==

Line 20:

Line 22:

===abbr-design-pattern===

===abbr-design-pattern===

*As mentioned on external sites (see:[[accessibility-issues]]) and on the microformats-discuss list, the abbr-design-pattern (used in [[hcard|hCard]], [[hcalendar|hCalendar]], [[geo|GEO]] and others) is in violation of WCAG1 and WCAG2, and has potentially harmful accessibility side-effects of reading machine data to screen reader users rendering human content inaccessible.

*As mentioned on external sites (see:[[accessibility-issues]]) and on the microformats-discuss list, the abbr-design-pattern (used in [[hcard|hCard]], [[hcalendar|hCalendar]], [[geo|GEO]] and others) is in violation of WCAG1 and WCAG2, and has potentially harmful accessibility side-effects of reading machine data to screen reader users rendering human content inaccessible.

+

** Previous misuses of the abbreviation pattern should now use the [[value-class-pattern]] instead. The abbreviation pattern remains suitable and correct for human readable expansions.

===anchor-include-pattern===

===anchor-include-pattern===

*As mentioned on [[accessibility-issues]], the anchor-include-pattern is in violation of WCAG1 and WCAG2, and has potentially harmful accessibility side effects due to the missing link text.

*As mentioned on [[accessibility-issues]], the anchor-include-pattern is in violation of WCAG1 and WCAG2, and has potentially harmful accessibility side effects due to the missing link text.

+

** The include pattern now strong advises against using empty anchor elements.

==External testimonials==

==External testimonials==

* [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>

+

+

== Challenges ==

+

* Andy Mabbett - How can we make them accessible to people with (for instance) visual disabilities?

==See also==

==See also==

Current revision

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 2.0, to at least Level AA. Further advice is available on the Accessify Forums.

Contents

Advantages

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".

Note: This is not an advantage to Microformats. It is a CSS best practice and can be used with or without hCard. This should probably be moved to a CSS Best Practices page. - James Craig

It is not an advantage of microformats; it is just CSS that can be used on any class, whether or not it happens to be tel. There is no documented AT implementation that recognizes Microformats classes automatically. This is just a benefit of CSS, with or without uF. James Craig

It is an advantage of microformats; because using "tel" in hCard requites people to mark up telephone numbers semantically, where they otherwise might not. No claim about AT implementations is being made. Andy Mabbett 01:04, 28 Jan 2008 (PST)

Disadvantages

Some microformats have potential accessibility disadvantages.

abbr-design-pattern

As mentioned on external sites (see:accessibility-issues) and on the microformats-discuss list, the abbr-design-pattern (used in hCard, hCalendar, GEO and others) is in violation of WCAG1 and WCAG2, and has potentially harmful accessibility side-effects of reading machine data to screen reader users rendering human content inaccessible.

Previous misuses of the abbreviation pattern should now use the value-class-pattern instead. The abbreviation pattern remains suitable and correct for human readable expansions.

anchor-include-pattern

As mentioned on accessibility-issues, the anchor-include-pattern is in violation of WCAG1 and WCAG2, and has potentially harmful accessibility side effects due to the missing link text.

The include pattern now strong advises against using empty anchor elements.

External testimonials

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.

Challenges

Andy Mabbett - How can we make them accessible to people with (for instance) visual disabilities?