RE: Longdesc change proposal update

John Foliot, Sun, 8 May 2011 08:51:58 -0700 (PDT):
> Silvia Pfeiffer wrote:

First to Silvia:
>>> Btw, I have suggested (spec text which says) that when a longdesc
>>> points to another page, then it should point to the exact fragment
>>> where the description begins ... And that there should also be an
>>> onvous end of the description. I still think that is a good idea May
>>> be, Silvia, if you try to add spec text, should should try to keep
>>> that perspective?
>> 
>> I was indeed wondering about that. If longdesc should only be used for
>> a11y purposes, then indeed it should point to the fragment offset of
>> the long description on the longdesc page.

+1

>> However, I wonder if it is
>> sufficient to provide people the opportunity to read that information
>> on a separate page that contains other interesting information, too.

What does it meant to "provide"? If it is kept outside the #fragment 
that contains the description, then it should be OK - the user can 
decide to read it if (s)he will. 

>> They are already prepared to spend more time on reading about the
>> image, so they will probably find the paragraph(s) that provide the
>> long description quickly. That would allow the longdesc link to be
>> both useful to blind and sighted users.

-1  I don't support this. However, the page where the description is 
located could perhaps be a page with extra info, where only a 
particular #fragment provided info about the the image. Thus one could 
link to the entire page as "extra info", whereas the @longdesc of the 
IMG could link to the specific section with a long description of the 
image.

And now to John:
> With no disrespect to Leif, I am not convinced that this is something that
> should be *specified* - it might be useful author information in some
> instances, but it is overly prescriptive.  There are indeed instances when
> a single page of text describing an image is both appropriate and logical,
> and adding an id fragment achieves nothing but added complexity.

I am, again, hearing echoes of things I have said before but which I 
ain't saying above.

I did not talk, above, about "instances when a single page of text [is] 
describing a image". The context was that Silvia mentioned Wikipedia's 
"about image" pages (such as 
http://en.wikipedia.org/wiki/File:Curitiba_10_2006_05_RIT.jpg). And 
those pages contains a lot of "extra stuff" - seldom do they contain 
any description at all, hence it is relevant to say that if @longdesc 
should be used in _that_ context, then it should point to a fragment.

I admit that I, earlier, have proposed the that @longdesc should always 
point to a #fragment, even when the entire page contains a description 
- this in order "demote" that @longdesc is misused to present images. 
However, that is not an idea that I am pursuing as something that 
should be part of the CP.

> For example, Dirk Ginader's jQuery plugin
> (https://github.com/ginader/Accessible-Longdesc) would become
> significantly more complicated it if had to parse page fragments, or
> needed to omit extraneous data (replication of the image) - see the
> example:
> http://blog.ginader.de/dev/jquery/longdesc/examples/webaim/index.php 

You are wrong. :-) At least when it comes to Dirk Ginader's excelent 
plug-in. 

1. Gindader's demo page:
http://blog.ginader.de/dev/jquery/longdesc/examples/webaim/index.php
2. The longdesc on the first image leads to 
"description.php#the-description"
3. The longdesc on the second image leads to "description.php"

If you read the description page,
http://blog.ginader.de/dev/jquery/longdesc/examples/webaim/description.php
then you see that the second half of the page contains, quote "more 
data that is not in the #the-description node".

This is also reflected in that clicking 'i' on the first img element 
results in less description than when you click on the 'i' for the 
second img element. So, actually, his plug-in IMO shows the point I 
tries to make very clearly! (One thing I will say though, is that via 
ARIA features, it is possible to make a page contain lots of extra 
stuff which is hidden from the A11Y user.)

> As well, looking at plugin solutions such as the WordPress longdesc
> module, the author is prompted to provide both an alternative text, as
> well as a "description" at image insertion time, and upon submit the
> module stores that descriptions as a unique db entry and dynamic url:

Sounds quite smart. I could imagine that Wikipedia could also work like 
that.

> <sample>
>    <img
> src="http://john.foliot.ca/wp-content/uploads/2011/05/dreamweaver.gif"
> alt="[Screen Capture: Dreamweaver&#039;s image tag Accessibility
> Attributes dialog box]" title="Dreamweaver Dialog Box"
> longdesc="http://john.foliot.ca?longdesc=375&#038;referrer=371"
> width="510" height="133" class="alignright size-full wp-image-375" /><a
> id="longdesc-return-375"></a>
> </sample>

That WP-plug-in sounds fine - it solves the issue nicely, I guess. 
However, a more "universal" system has to be able to handle both a 
#fragment and an entire pages. If for no other reason then at least 
because the CP says that the @longdesc may point to the very same page 
that the image is located on: in order to handle the "on the very same 
page as the image" use case, the longdesc solution *has* to be able to 
handle a #fragment.

> So while I am not saying this is right or wrong, I am saying that we need
> to be careful what we include as specification text, and what we include
> as author guidance, and including id fragments and/or replications of the
> image would be, at best, MAY suggestions.

In this round, all I have said is that if the @longdesc points to a 
page which contains more than the long description itself, the it must 
point to a fragment and not to the entire page. This rule is valid both 
when the long descripiong is located on the very same page as the image 
itself as well as when it is located on another page with more than the 
description.

But I have reread the spec text before I say more.
-- 
Leif H Silli

Received on Sunday, 8 May 2011 19:58:22 UTC