W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2004

RE: D-links (was Conformance Testing Proposal)

From: John M Slatin <john_slatin@austin.utexas.edu>
Date: Wed, 7 Apr 2004 16:40:56 -0500
Message-ID: <C46A1118E0262B47BD5C202DA2490D1A1E30EE@MAIL02.austin.utexas.edu>
To: "Joe Clark" <joeclark@joeclark.org>, "WAI-GL" <w3c-wai-gl@w3.org>

Thanks, Joe, for the good critique.

In fact I'm beginning to think that longdesc is the problem, not the
d-link.  The problem is that (as far as I'm aware) longdesc is available
*only* to people who use screen readers or talking browsers that support
it. If that's true, then extended descriptions that might benefit people
who have difficulty processing (but not perceiving) complex visual
materials will be inaccessible to them if it's available only via the
longdesc.  Using a d-link makes it available to anyone who uses a user
agent that supports text links.  So I would argue that longdesc should
be the method of choice only when authors are certain that people who
are blind are the only ones who will need the description.

As for your second point, where to place a text link that's long enough
to indicate which image-description it refers to is a design question,
not a guidelines question.  The requirement to clearly identify the
target of each link has been in WCAG for five years, and it's a good
requirement.  Multiple links that say More ... And point to different
places don't meet that checkpoint, nor do multiple links that say "d"
and point to descriptions fo different images.  At the very least the
identifying information should be in the title attribute.  (And, as to
the design question, what designer likes to have a page littered with
little orphan letter d's?)

John


"Good design is accessible design." 
Please note our new name and URL!
John Slatin, Ph.D.
Director, Accessibility Institute
University of Texas at Austin
FAC 248C
1 University Station G9600
Austin, TX 78712
ph 512-495-4288, f 512-495-4524
email jslatin@mail.utexas.edu
web http://www.utexas.edu/research/accessibility/


 



-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On
Behalf Of Joe Clark
Sent: Wednesday, April 07, 2004 4:06 pm
To: WAI-GL
Subject: D-links (was Conformance Testing Proposal)



> Some comments about longdesc and d-links:
> 1. We should not *require* redundant use of longdesc *and* d-link for
> <img> elements that need additional description.   If support for
> longdesc isn't widespread enough to be reliable,

Well, what do you mean by that?

The user agent that WCAG WG has historically custom-crafted its
guidelines to cater to, Jaws on IE for Windows, can read a longdesc.
Window-Eyes supports it. You can read longdescs in Mozilla. There are
other implementations, for all I know. (iCab, even, not that it really
counts.)

It's in the spec. Some user agents support it, and the rest of them are 
gonna have to eventually.

The D-link option was always a kludge and simply is not justifiable. It
is
extra-specification: To endorse it is to concede that the HTML spec
isn't good enough. It says the spec is so bad, in fact, that we have to
recommend nonstandard workarounds. Well, why?

> we should require that
> descriptions be provided either on-page or in a separate, linked 
> file/window.

I think not.

> 2. On pages that display multiple images that require description, 
> link-text pointing to the descriptions should identify the image to 
> which the description refers.

How's that gonna work on photoblog pages with valid code and correct 
alt-text usage?

<http://leavesrustle.com/photos/?album=UpNorth2003>

<http://photomatt.net/photos/log/3-12-2004>
(using null alt text when adjacent text does the job)

Where are you gonna put 20 letter Ds?

<http://joeclark.org/book/sashay/serialization/Chapter06.html#d-links>
(Hi, Chris!)

Let's stick to the spec.

-- 

    Joe Clark | joeclark@joeclark.org
    Accessibility <http://joeclark.org/access/>
    Expect criticism if you top-post
Received on Wednesday, 7 April 2004 17:40:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:29 GMT