[uf-new] Metadata/machine-readable data patterns

[Nelson Menezes]

On 14/03/2008, Sarven Capadisli <csarven at gmail.com> wrote:
> @title value in <abbr> is not hidden data. The user is able to hover
>  the element and get to the information. The @title value is used as an
>  alternative or replacement of <abbr> textContent. This is not the case
>  in <input type="hidden">.

Point taken. But the data is still "hidden" in the sense that most
users don't tend to hover their cursor over every word to see if there
is more information about each word. It is still possible to let the
title attribute fall out of sync with the "human" content. And
likewise it's just as easy to abuse as "properly hidden" data:

<abbr style="border: none; cursor: default;" title="20010101"
class="dtfrom">Free</abbr>
<abbr style="border: none; cursor: default;" title="29991231"
class="dtfrom">stuff!</abbr>

>  It is important to keep the data paired, a) human readable
>  date/timestamp within context,  b) human readable standardised
>  date/timestamp. <abbr> is "good enough" for this or at least the most
>  semantic candidate with minimal negative impact. Screen readers may
>  have a problem with it only because of the way they are configured to
>  treat the data. The information inside <abbr> is independent from how
>  it will be interpret or treated by any UA for that matter.
>
>  e.g. <p>I will see you <abbr title="2008-03-21" class="dtstamp">next
>  week</abbr></p>

It's a good example above, but let's be honest: the real reason we
have the ISO dates in microformats like hCalendar is so that dates are
machine-readable. If it were possible to reliably parse something like
<span class="dtfrom">next Thursday at sundown</span> then we wouldn't
be having this discussion.

Using <abbr> is a decent semantic compromise in many circumstances.
But screen readers are not doing anything wrong by interpreting the
data the way they do (they are very much following the spec, and the
semantics). It's the stretching of the semantics by microformats that
unwittingly caused the issue; it's not right to expect screen readers
to address the issue by changing the way they interpret the data.

I have been convinced, so far, that using hidden input elements as a
"blanket solution" for machine-readable data is indeed a bad idea. The
title of my original email is therefore somewhat inadequate. However,
I maintain that in specific circumstances where we have data that is
*meant* for machine-readability and that has adverse effects on human
readability then we should consider using a hidden input field.

-- 
Nelson Menezes
flying.mushroom at gmail.com