Re: fear of "invisible metadata" [was Re: retention of summary attribute for TABLE element]

Thanks for the answer

Somehow I didn't really catch that the LONGDESC could be a part of the
very same page where the image is placed, so it creates a full link
between the image and its description.

I usually thought about it as a new page and didn't like the fact that
only people with a special browser would be able to access it, that's
what I meant when I said that it is a contradiction, because a
resource meant to provide greater accessibility to people that can't
access the original data isn't available to other people that would
also benefit from that same text version of the resource (there are
some tables shown in the examples of headers that in order to
understand what they meant I had to look at the source code)

So the shame is on the browser vendors for not providing a way to show
that an image has a longdesc attribute.

Am I on the right track now?

2007/6/19, Charles McCathieNevile <chaals@opera.com>:
> On Tue, 19 Jun 2007 16:22:23 +0200,
> "=?ISO-8859-1?Q?Alfonso_Mart=EDnez_de_Lizarrondo?= "Martínez de
> Lizarrondo" <amla70@gmail.com>" <"<amla70"@gmail.com>alfonso> wrote:
>
> > LONGDESC is a good description of a contradiction. It's meant to
> > provide extra information about an image, but the fact is that no
> > visual UA supports it (AFAIK), and that means that if you provide it
> > so people with visual problems can get that extra information about
> > the image then you are depriving the rest of the people with that very
> > same info.
> >
> > Is that logical?
> >
> > So the solution is to wrap the image in a link so it points to the
> > extra info and everybody can access it. And in the end the existence
> > of such attribute isn't useful at all.
> >
> > Am I wrong about this issue?
>
> In a word, yes.
>
> Longdesc is not that common on the web. The native support is woeful -
> iCab excepted, although it is inaccessible in general - but there are
> extensions that people use to make it work nicely[1]. Despite the lack of
> support, it is used occasionally, and it is very useful.
>
> It is true that in general a real description would be useful to everyone,
> but there are a lot of designers who don't see things that way. The
> d-link, even when invisible, was not a popular idea because it could
> interfere with (over-)complicated layouts. In addition, it is a lot of
> work, so not everyone is going to provide this.
>
> In an ideal world, the longdesc for Maciej's flickr photos (and others)
> would point to the paragraph below, which describes, more or less, the
> image (and is of course addressable via a URI). Being able to point
> directly to a description would allow Gregory's photos, described by
> various other people, to be annotated with a pointer to the description he
> preferred [1]. An ideal browser implementation would know whether a
> description is in the same page immediately after, or in a different page,
> and make the UI make sense for both those cases. But being able to go back
> and forth is a minimally useful answer - just as label is in some way
> related to a form control, but different use agents do a better or worse
> job of making use of that association.
>
> As a further use case, wouldn't it be nice, instead of getting random
> results for image searches, if you could at least know that people
> building searches had the possibility of looking at longdesc content? (It
> may not work for Google, who would of course get spammed with keyword
> stuffing, but it would work for the various groups who do intranet search
> engines and it would be useful). This is what having semantics is about,
> after all.
>
> Cheers
>
> Chaals
>
> --
>    Charles McCathieNevile, Opera Software: Standards Group
>    hablo español  -  je parle français  -  jeg lærer norsk
> chaals@opera.com    Catch up: Speed Dial   http://opera.com
>

Received on Tuesday, 19 June 2007 21:23:45 UTC