Re: Moving longdesc forward: Recap, updates, consensus

On Fri, May 6, 2011 at 4:37 PM, Gregory J. Rosmaita <oedipus@hicom.net> wrote:
> no, i am NOT ok with dropping the Hidden Metadata Fallacy -- this is
> a fundamental philosophical/logical principle: that discoverable metadata
> is available for those who NEED it

Nobody disputes that users needs text alternatives, and HTML5 must provide
mechanisms for authors to provide them.

The hidden metadata objection simply says that encouraging authors to hide
such text alternatives makes text alternatives more likely to be poor quality.

Here's Tantek's objection from the poll:

"[@longdesc] is one of the worst forms of invisible metadata or "dark data"
which are known to rot and become inaccurate over time (see: meta keywords, RDF
in comments, sidefiles, etc.)."

Here's Lachlan's objection from poll:

"There are arguments based on the idea that hidden metadata is useful for some
unspecified use case, with the supposed problem that any additional information
that may be referenced by longdesc, must be hidden from the vast majority of
users, and not otherwise affect the design of the page.

"Such arguments are misguided, because it is far better for accessibility for
such issues to be considered a prominent part of the page's design and/or user
experience from the outset, and for the accessible content to be treated as a
first class citizen of the site. Hiding it behind the longdesc attribute, or
any other similar method, effectively treats it as a second or even third class
citizen which has been clearly demonstrated to result in suboptimal alternative
content that never actually helps those it's intended to."

http://www.w3.org/2002/09/wbs/40318/issue-30-objection-poll/results#xfigure

In the Chairs' decision, they accepted that the tendency of invisible metadata
to rot could help "explain the bad data that has been seen", but treated this
as a weak objection because only anecdotal evidence was provided that rotten
data would cause implementors or users to give up on @longdesc and no evidence
was provided that user agents could not exclude a lot of bad data.

As such, I would expect a "hidden metadata fallacy" section to put
forward arguments
in favour of any of the following:

  * Errors in visible data and hidden metadata are equally likely to be
    corrected. (This seems obviously false.)

  * In the special case of long text alternatives, authoring visible data is
    likely to compromise quality more than hiding it because of the risk that
    authors write captions that assume you can see and make sense of the image.

  * More authors will provide text alternatives if they can hide them, and this
    is worth the accuracy cost of helping them to do so.

  * User agents could excude bad data.

  * Users will not give up on @longdesc if they repeatedly encounter bad
    @longdesc values.

  * User agents will not stop implementing @longdesc if users repeatedly
    encounter bad @longdesc values.

  * Better implementations will make it easier to discover @longdesc visually,
    reducing the error rate due to it being hidden from the normal rendering
    of the page itself.

But instead, the "Hidden Metadata Fallacy" section lays seige to a nonsenical
strawman argument asserting that hidden metadata is not discoverable at all.

> i, for one, think there is a crucial distinction between "hidden metadata"
> and "discoverable metadata"

What's the distinction?

> -- one could call "hidden" any metadata attached to an image (such as a JPEG
> file) which contains info about the camera, the resolution, and other
> technical metadata because when the image is rendered, such metadata is not
> immediately available to the user unless that metadata is extracted or
> exposed using a specialized tool -- this is the entire point of such
> initiatives as the RDF in Photo work within the W3C and some of the other
> initiatives that laura has documented...

In the context of a webpage, those are all hidden metadata.

--
Benjamin Hawkes-Lewis

Received on Friday, 6 May 2011 20:30:54 UTC