[uf-discuss] Re: One more shot at accessible hCalendar
bhawkeslewis at googlemail.com
Sat May 17 10:37:47 PDT 2008
Toby Inkster wrote:
> Andy Mabbett's proposed "data:" prefix already solves the abbr design
> pattern accessibility issue
Andy made an honest stab at solving the issue; I don't think his
proposal is workable however.
In so far as end-users want to be able to ignore the data:
1. It requires ordinary users of text-to-speech or text-to-braille
sofware to have special knowledge of microformats, if they are to skip
the data when the title attribute is read.
2. The page is still littered with tooltips that may distract people
with cognitive disabilities and may obscure the main content in a screen
In so far as end-users want to be able to actually read the data:
1. It doesn't help make the datetime read comprehensibly in (current)
text-to-speech or text-to-braille software.
2. It doesn't help make the datetime comprehensible to ordinary users
who don't understand ISO 8601 notation.
3. You still can't easily access the datetime without a mouse (keyboard,
voice control, etc.).
I think it's worth noting (again) that if end-users /really/ wanted to
read the data directly, then the most appropriate place for it would be
in the main content not quasi-hidden in an attribute.
In addition to not solving the accessibility issues, the data: prefix
doesn't solve the standards problem of misuse of @TITLE for machine,
rather than human, friendly information.
Making ISO 8601 annotations accessible to end-users and easily checkable
by publishers necessitates special software to check the data is valid,
convert it to a human friendly form appropriate to the user's locale,
and display it alongside the human friendly, potentially lossy variation
in the main content. This isn't (yet) done by mainstream user agents,
but would be a useful task for tools like Operator. It makes a lot more
sense to me to put the burden of adaptation on the (currently) rare
consumers of microformats than on users and user agents in general.
Given such problems and granted the potential for such tools, I believe
that almost any of the alternative proposals (CLASS-based data hiding,
SPAN element with TITLE surrounding human friendly date, empty SPAN
element with TITLE, empty ABBR with TITLE, OBJECT element, and INPUT
TYPE="HIDDEN"  ) would be preferable markup to the data: prefix.
Frankly, /all/ of these options seem like a bit of an icky hack. :( It's
a question of either giving up on a machine-readable alternative to
human friendly information in the current versions of (X)HTML or
choosing the option that does the least violence to the intention of the
specs, can rely on the most standardized user agent behavior, and does
the least harm to end-users.
At the moment, I'm leaning a bit towards INPUT TYPE="HIDDEN" as a
potential least worst option:
The (X)HTML DTDs allow INPUT elements outside any FORM element. The HTML
4.01 spec says (17.2.1):
> The elements used to create controls generally appear inside a FORM
> element, but may also appear outside of a FORM element declaration
> when they are used to build user interfaces. This is discussed in the
> section on intrinsic events. Note that controls outside a form cannot
> be successful controls.
Of INPUT TYPE="HIDDEN", the spec says (17.2.1 again):
> Authors may create controls that are not rendered but whose values
> are submitted with a form. Authors generally use this control type to
> store information between client/server exchanges that would
> otherwise be lost due to the stateless nature of HTTP (see
Date time information stored in INPUT TYPE="HIDDEN" could be used to
"build user interfaces" (e.g. Operator), though it wouldn't (normally)
be "submitted with a form". I'm not sure how much weight should be
placed on that qualification. "MAY" does not necessarily exclude other
uses. Granted, you could make the same argument about the spec's
allowances for @TITLE.
The key difference here, I think, is how user agents are supposed to
treat @TITLE (they may render it directly, whatever element it's on) and
how user agents are supposed to treat INPUT TYPE="HIDDEN" (they must not
render the control). I believe this makes INPUT TYPE="HIDDEN" safer in
terms of potential harm to end-users.
I strongly agree with the microformats principle that "visible data is
much better for humans than invisible metadata". Now hiding the date
time information will seem like a bad thing if you go further and hold
that microformated data must /always/ be visible. But I think those who
hold this position need to be clear about whether
1. Such data must really always be visible to users (in which case ABBR
TITLE is a clear antipattern, since in typical implementations it hides
the data unless specifically requested by users).
2. It must be possible for the user to make it visible (in which case
any standard markup will do, since the information can be extracted and
presented in much more human-friendly manner by a microformats-aware
tool and the end result will be much better than a TITLE tooltip).
To put that another way: visible data is much better for humans than
invisible metadata, but human-friendly information that can be made
visible is better than machine-friendly information that can be made
visible. As some other of the other microformats principles say: "design
for humans first, machines second" and "be presentable and parsable":
More information about the microformats-discuss