[uf-discuss] Re: One more shot at accessible hCalendar

[Benjamin Hawkes-Lewis]

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
magnifier.

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" [3] ) 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:

http://microformats.org/discuss/mail/microformats-new/2008-March/001567.html

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
> [RFC2616]).

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).

OR

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":

http://microformats.org/wiki/principles

--
Benjamin Hawkes-Lewis