- From: John McKenzie <davros@accesscable.net>
- Date: Tue, 10 Apr 2007 19:08:49 -0300
- To: public-html@w3.org
Gregory: I too, would like to say that your post on "abbreviations in canonical HTML" was well done. It certainly makes this post look bad in comparison. Everyone: My apologies if my response becomes an unwanted tangent on the subject, but the ideas Gregory expressed could address an issue I have thoughts about. A bit of a prologue: As soon as I heard about microformats I started reading the Microformats Blog (http://www.microformats.org). After a long time, I implemented a microformat for the first time, an hcard (http://microformats.org/wiki/hcard) example. However, there was something about it that bothered me. There is a design pattern used by microformats (http://microformats.org/wiki/Main_Page#Design_Patterns) called the Abbr design pattern (http://microformats.org/wiki/abbr-design-pattern). This design pattern sometimes uses the ABBR element to provide machine readable information about a piece of human readable text. These two pieces of info may have the same practical meaning, but not the same literal expression. For example the ABBR element may contain the longitude and latitude coordinates of a city while the text just gives the name of the city. Code Example: <ABBR class="geo" title="44.7657;-63.6609">Halifax</ABBR> This concerned me, so I did some research and discovered that yes indeed, this approach has accessibility issues. In my above example, the city name, Halifax would be read as an abbreviation by a screen reader in some case, while in every case it is just a regular word. An addition to the type (or possibly expressed-as) attribute Gregory was describing for his proposed IABBR element could help this situation. Perhaps with a better name, something like an "equivalence" type could be added to the list of IABBR types. The equivalence type would be used to indicate something that is the same as what is described in the title attribute, but expressed differently. In a way that is what all acronyms are; "SOund Navigation And Ranging" and SONAR are the exact same thing, with the same meaning and connotation, just expressed differently. Now, I know you may be asking yourself, why should we add to the list of possible type attributes, for just one thing (a microformat design pattern) that bothered just one person (me). Well, I see doing this as having flexibility and being helpful in many situations. The abbr-design-pattern lead me to this place in my mind, but is not the defining reason or need behind it. As an example of another usage of this idea of equivalence, imagine a web page used by aviation professionals describing origins and destinations. Every airport has a three letter code used to identify it (four letter codes also exist but my example will use three). The ABBR or IABBR element with the right attribute could be used to provide the code in a non-intrusive way. Example <P>Flights arriving in <IABBR type="equavilance" title="HAV">Havana</IABBR> are required to be bug sprayed, even if arriving from colder climates such as the ones found in <IABBR type="equavilance" title="HEL">Helsinki</IABBR> and <IABBR type="equavilance" title="YHZ">Halifax</IABBR>. With this example the paragraph is machine readable in a way that extracts airport codes from the page, something useful for other aviation systems. Doing the same in reverse could be helpful in some contexts. <P>...this applies to all flights arriving in <IABBR type="equavilance" expressed-as="characters" title="Havana">HAV</IABBR>.</P> If a user agent choose to give options on how it displays/not-displays/allows-access-to the title information from those examples, it could be even more useful. I wish I could think of more concrete examples right now. (As someone who works at an aiport though, I can assure you that the above examples could be very helpfull for internal web pages.) Regardless, I think that the best use of this would be discovered as it got used in the wild. Embedding information into the source code that is the factual equivalent of another piece of information, but expressed differently, could have great potential.
Received on Wednesday, 11 April 2007 00:56:34 UTC