dfn-design-pattern: Difference between revisions
|Line 50:||Line 50:|
The proposed dfn design pattern assumes that screen readers don't treat <code>dfn</code> as a special case like <code>abbr</code> or <code>acronym</code>. Is this actually the case? Please
The proposed dfn design pattern assumes that screen readers don't treat <code>dfn</code> as a special case like <code>abbr</code> or <code>acronym</code>. Is this actually the case? Please [[assistive-technology--results|assistive technology results]] .
===Usage in the wild===
===Usage in the wild===
Revision as of 06:07, 6 January 2008
Dfn design pattern
Important: this is currently a proposal: it is not a finalised design pattern.
The abbr design pattern is used in several microformats to enclose standardised data such as the datetime design pattern in the
title attribute. However some assistive technology will expose this data directly to the user, which is often undesirable.
See also assistive technology abbr results.
This problem arises because the
title attribute has a different semantic meaning when it is attached to an
acronym than it does on other elements. Usually the
title attribute is used to provide provide advisory information. But for
title is used to provide an expanded form of the text contained between the opening and closing tags. This is why the
abbr element was chosen to contain datetime information: the ISO format is an expanded form of the human-readable text contained within the element. Because screen readers can be configured to treat
acronym elements as special cases, the
title attribute is sometimes read aloud.
Rather than expand the abbr design pattern to any element (or to a semantically neutral element such as
span), it would be better to use an element that has semantic value but which isn't treated as a special case by assistive technology.
The dfn element indicates the defining instance of the enclosed term. This element is not widely used but where it used, it is often used in a similar way to the
abbr element. Although the
title is not required for the
dfn element, it is often used to provide expanded information.
The semantic meaning of
dfn, as it is currently used, is potentially similar enough to
abbr element to allow it to be used as an alternative:
<abbr class="dtstart" title="2007-08-16T22:00:00">10pm on August 16th</abbr> <dfn class="dtstart" title="2007-08-16T22:00:00">10pm on August 16th</dfn>
dfn is not intended for definitions; it is intended for defining instances. Does this mean that it must always be used for the first instance of a term (such as a date)?
dfn element equally appropriate as the
abbr for information such as datetimes and geo or is this stretching the semantic meaning of the element beyond a reasonable limit?
In HTML5, the element semantics have completely changed and would be incompatable with this pattern.
Existing microformats parsers (such as the Operator extension to Firefox) would need to be updated to handle this proposed alternative to the abbr design pattern. However, this is true of any proposed alternatives.
Microformats are intended to be easy to publish. The number of design patterns should be kept to a minimum. Every new design pattern is potentially a new barrier to entry for publishers.
The proposed dfn design pattern assumes that screen readers don't treat
dfn as a special case like
acronym. Is this actually the case? Please note results of testing on that item in the assistive technology results page.
Usage in the wild
This design pattern is built on the assumption that, although the
dfn is not widely used, where it used, it is most often used in conjunction with the
title attribute. Please document examples and references here:
- Juicy Studios: Jargon Busting with the Definition Element
- A List Apart: The Accessibility Hat Trick: Getting Abbreviations Right