[uf-discuss] Expanding the abbr pattern

[Joe Andrieu]

Ben Buchanan wrote:
> Hi Jeremy,
> 
> > I'd be interested in hearing other arguments for or against 
> this idea.
> 
> I think it's a humans vs. machines issue. To my mind, the 
> ABBR element is there to provide additional information to 
> the user (the human). In this case, it's being used to add a 
> timestamp in a format that I've never heard a human use. To 
> put it another way, it's not adding information for the user; 
> it's adding data for the machine.
> 
> IMHO the ABBR title should always enrich, explain or 
> disambiguate the contents of the ABBR tag. Using a 
> full-string timestamp doesn't do that (nor does geo data, to 
> touch on a related problem). Although it's tremendously 
> useful for uf parsing, I think it's trumped by the problems 
> it causes for screen reader users.

Ben,

So, I started this response thinking "How does a full-string timestamp /not/ disambiguate a March 2 date in the following?"

<div class="vevent">
  <abbr class="dtstart" title="20040502">May 2nd</abbr>
  <div class="summary">Example</div>
</div>

May 2nd is ambiguous regarding the year of the event. The timestamp is not.  I think there are compatibility problems with screen
readers that may be more important, but a lack of disambiguation doesn't seem to be the issue.

The fact that a human doesn't use an ISO timestamp is a bit beside the point as the title is an attribute of the tag, not content on
the page. The title isn't displayed to the user. It is interpreted by the renderer and displayed or output in some fashion.  The
problem may be that current readers don't handle timestamps very well, but that's a reader problem (one that we would do well to
resolve). As I discovered later, the fact that it is not the normal version as would be seen in running text, is a problem.

For a decent rant on why ABBR is for machines and not people see
http://www.smackthemouse.com/20040108


But then I read the article referred to in Jeremy's post [1] and realized ABBR pattern is neither valid nor necessary, even if
convenient.  And that article also gave several examples where the ABBR pattern isn't necessarily disambiguation, making my example
moot.


Tantek also wrote: 
> If you must have pixel-perfect rendering for your content/site in older browsers that
> don't support abbr, and you need abbr-specific styling, then yes, a workaround is to 
> add a <span> element as a styling hook for those older browsers.  However we MUST NOT
> compromise microformats for browsers that failed to implement *an entire HTML4 element*.

So much for the 80/20 rule.

According to the link provided in Jeremy's post [1], the ABBR pattern is not valid HTML 4, which is especially ironic given Tantek's
commitment to HTML4 as the baseline for judging IE's  behavior.  Here's the quote from the Web Standards Project article [1], itself
quoting the spec [2]:

>   The content of the ABBR and ACRONYM elements specifies the abbreviated expression 
>   itself, as it would normally appear in running text. The title attribute of these
>   elements may be used to provide the full or expanded form of the expression.
>     (HTML 4, ABBR)

> Unlike the ISO date format, the "full or expanded form" is intended to be human-readable. 
> Yes, machine-readable, but for the consumption of a human, and in this case, spoken 
> literally to a human. The Web Content Accessibility Guidelines (WCAG) explicitly defines 
> the expansion of abbreviations as an accessibility advantage, and the most popular screen
> readers do so.


So, ABBR is unsupported in IE6 (without jumping through hoops to use special scripts). ABBR timestamps are problematic in leading
screen readers. And ABBR timestamps violate the HTML 4 spec.

How did it actually get adopted as a pattern for uF?

Or more specifically, is there any way to fix that mistake?

I would say we should at least avoid extending it into new areas, until and unless a formal standard body endorses a viable solution
and that solution reaches viable 80/20 market share. The status of HTML5 and XHTML 2 are not worth getting into, but suffice to say
such a trigger is likely to be far into the future.

However, I do like Jeremy's suggestion for best-practices on the ABBR:

> Would everyone agree that, for the sake of screen reader users, we  
> should update the wiki to strongly encourage this more verbose  
> version of datetimes and strongly discourage the contracted version?

If we are going to continue to support a non-compliant use of ABBR, we may as well advocate a version of it that is more friendly to
existing screen readers.  That would also require updating the vCalendar Creator.

Cheers,

-j

[1] http://www.webstandards.org/2007/04/27/haccessibility/
[2] http://www.w3.org/TR/html4/struct/text.html#edef-ABBR

--
Joe Andrieu
SwitchBook Software
http://www.switchbook.com
joe at switchbook.com
+1 (805) 705-8651