W3C home > Mailing lists > Public > public-html@w3.org > June 2007

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

From: Ben Boyle <benjamins.boyle@gmail.com>
Date: Wed, 20 Jun 2007 21:47:39 +1000
Message-ID: <5f37426b0706200447m4ec9dbb0lc0482014e94cae74@mail.gmail.com>
To: "Alfonso Martínez de Lizarrondo" <amla70@gmail.com>
Cc: "Charles McCathieNevile" <chaals@opera.com>, joshue.oconnor@cfit.ie, "James Graham" <jg307@cam.ac.uk>, "Gregory J. Rosmaita" <oedipus@hicom.net>, "HTML WG" <public-html@w3.org>
WebAIM have excellent resources on this topic:

Creating Accessible Images - Creating Effective Alternative (alt)Text:

Creating Accessible Images - Long Descriptions:

Also worth looking at the new <figure> element in HTML5:

Am I on the right track here?

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

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

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

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?

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

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:22 UTC