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

WebAIM have excellent resources on this topic:

Creating Accessible Images - Creating Effective Alternative (alt)Text:
http://www.webaim.org/techniques/images/alt_text.php

Creating Accessible Images - Long Descriptions:
http://www.webaim.org/techniques/images/longdesc.php

Also worth looking at the new <figure> element in HTML5:
http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html?rev=1.78#the-figure

Am I on the right track here?

<figure>
  <legend>Graph of percentage of total U.S. noninsitutionalized
population age 16-64 declaring one or more disabilities</legend>
  <img src="http://www.webaim.org/techniques/images/media/graph.jpg"
longdesc="media/description.htm" />
<figure>

I'd really like to be able to do this:

<figure>
  <legend>Graph of percentage of total U.S. noninsitutionalized
population age 16-64 declaring one or more disabilities</legend>
  <img src="http://www.webaim.org/techniques/images/media/graph.jpg">
    <table>
      <caption>Graph of percentage of total U.S. noninsitutionalized
population age 16-64 declaring one or more disabilities</caption>
      ... (fallback) data table reflecting graph in here, not shown
when <img> is rendered ...
    </table>
  </img>
<figure>

Am I still on track?
The idea comes from <object> [1] and @src in XHTML2 [2].
[1] http://www.w3.org/TR/html401/struct/objects.html#h-13.3.1
[2] http://www.w3.org/TR/xhtml2/mod-embedding.html#adef_embedding_src
XHTML2 would not require the <img> tag above, you could use <table
src="http://www.webaim.org/techniques/images/media/graph.jpg"> and
only see the table.

I don't know how effective these fallback mechanisms are with AT...
don't a lot of AT products rely somewhat on what the browser renders
(e.g. does a browser rendering an image might make it harder for
screen reader to access the table fallback?)

You may be wondering why I repeated <legend> with <caption>. I am too,
but it seems to be required as: "The entire figure element (including
the caption, if any) must be treated as being replaced by that
fallback content."

Can I also say it is very confusing using the term "caption" to refer
to <legend> in this context?
http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html?rev=1.78#the-figure



On 6/20/07, Alfonso Martínez de Lizarrondo <amla70@gmail.com> wrote:
>
> 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 Wednesday, 20 June 2007 11:47:43 UTC