I don't think this is necessary. I can't think of anything that could be done with this that cannot already be done by noting that there is a longdesc attribute.

In my TellMeMore extensions I use document.querySelectorAll('img[longdesc]') to get a list of the elements with longdesc.

Doing something in CSS like

  img[longdesc] { border: red dashed 2px}

would provide a border on each image that has a longdesc attribute (there are obviously more complex things that could be done here, this is just the simplest I can think of).

  img[longdesc^=#] { border: none}

following the first declaration will cancel the effect for images whose longdesc is a link internal to the page.

And so on.

So I propose to reject the bug.

Chaals is absolutely right of course - I agree that there is nothing really that can't already be done.

But I was thinking of an easier way to add discoverability for longdesc targets. Specifically I was thinking that if you added this "longdesclink" (or whatever) attribute to images, it would cause the browser to display a link to the longdesc target next to the image. So for example

<img src="linegraph.jpg" 
  alt="Line graph of the number of subscribers" 
  longdesc="longdesc/linegraph.html" 
  longdesclink>

Would result in the browser displaying

<a href="longdesc/linegraph.html">Line graph of the number of subscribers</a>

beside the image at runtime.

Yes, this would be trivial to knock together with script, but even so, script is not within the realms of everyone.

(In reply to comment #2)
> even so, script is not within the realms of everyone.

This is true. Not all authors know JavaScript or CSS. I don't see why the browser couldn't provide an easy way to do this, for authors of limited skill sets.

(In reply to comment #3)
> (In reply to comment #2)
> > even so, script is not within the realms of everyone.
> 
> This is true. Not all authors know JavaScript or CSS. I don't see why the
> browser couldn't provide an easy way to do this, for authors of limited
> skill sets.

The browser could. But having the attribute won't make it happen either - what is needed is the code, and getting it into a browser.

The simplest way to do that, of course, is an extension. Here's some horrible code that could be used, but anyone who can write a browser extension (tens of thousands of people can) would probably reject this code as hideous and write something neater.

document.onload = (function(){
 function islinked(element) {
  if (element.tagName == 'A')
    return true;
  else if (element.tagName == 'BODY')
    return false;
  else
    return (islinked(i.parentElement));
 }
 function addlink(describedImage){
  var newLink = document.createElement('a');
  newLink.href = describedImage.longdesc;
  newLink.innerText = "[description of the image]";
  if (describedImage.nextSibling)
    describedImage.parentElement.insertBefore((describedImage.nextSibling),newLink);
  else
    describedImage.parent.appendChild(newLink)
 }
//LinkNextToParent is a blend of the last two functions..
 var theimages = document.querySelectorAll('img[longdesc]');
 for (i in theimages) {
  if (! isLinked(i))
    addlink(i);
  else
    linkNextToParent(i);
 }

})

Hi Chaals,

(In reply to comment #4)
>>> (In reply to comment #3)
>> (In reply to comment #2)
>> > even so, script is not within the realms of everyone.
>> 
>> This is true. Not all authors know JavaScript or CSS. I don't see why the
>> browser couldn't provide an easy way to do this, for authors of limited
>> skill sets.

> The browser could.

Yes. I believe that getting it implemented is what Chris had in mind. Specifying a new attribute would allow browsers to enable a *super simple*  way for *authors* to explicitly trigger longdesc discoverability on individual images. It would provide author control of design in a granular manner.

> The simplest way to do that, of course, is an extension.

Do you mean a browser extension or an authoring tool extension? 

As you already know and as previously noted we already have various browser extensions that enable direct user discoverability in browsers  [1]. 

Does your code do anything different than provide direct user discoverability? 

Does it allow authors or authoring tools to simply add a sister attribute (whatever it be named) into their markup in a conforming way that will make longdesc discoverable? Again, the idea of the sister attribute is to allow authors to easily surface discoverability in browsers by adding a simple sister attribute. Then if that sister attribute was present, browsers would do something: add the link or a border or an icon or whatever in whatever way was agreed upon for that particular device.

Thanks.

[1] http://www.d.umn.edu/~lcarlson/research/ld-ua.html

(In reply to comment #5)
> Hi Chaals,
> 
> (In reply to comment #4)
> >>> (In reply to comment #3)
> >> (In reply to comment #2)
> >> > even so, script is not within the realms of everyone.
> >> 
> >> This is true. Not all authors know JavaScript or CSS. I don't see why the
> >> browser couldn't provide an easy way to do this, for authors of limited
> >> skill sets.
> 
> > The browser could.
> 
> Yes. I believe that getting it implemented is what Chris had in mind.
> Specifying a new attribute would allow browsers to enable a *super simple* 
> way for *authors* to explicitly trigger longdesc discoverability on
> individual images.

Sure, but it is just as easy for browsers to enable the discoverability based on the presence of the longdesc attribute itself. And more reliable - browsers will be unhappy if you ask them to do this, and they start seeing "longdesclink" attributes when there is no actual longdesc.

I also think it will actually confuse authors and there will be 

<img src="..." longdesc="oops I put a description in here" londesclink="http://example.com/what/should/have/been/in/the/longdesc/attribute.html" ...

> It would provide author control of design in a granular
> manner.

Yeah, but this is misxing presentation back into the structure, which I think is a bad idea.
 
> > The simplest way to do that, of course, is an extension.
> 
> Do you mean a browser extension or an authoring tool extension? 

browser extension, but the same applies to authoring tool extensions

> As you already know and as previously noted we already have various browser
> extensions that enable direct user discoverability in browsers  [1]. 

yep.

> Does your code do anything different than provide direct user
> discoverability? 

No, that sample provides the discoverability you're looking for in a browser, based on the presence of a longdesc attribute. With an extra simple function, it can checkthat the attribute is valid in the first place, and if it isn't, e.g. it is a description instead of a link, it could convert that to a data URL (using the code example in the spec draft already) and still add the link...

> Does it allow authors or authoring tools to simply add a sister attribute
> (whatever it be named) into their markup in a conforming way that will make
> longdesc discoverable? Again, the idea of the sister attribute is to allow
> authors to easily surface discoverability in browsers by adding a simple
> sister attribute. Then if that sister attribute was present, browsers would
> do something: add the link or a border or an icon or whatever in whatever
> way was agreed upon for that particular device.

I don't think it should be done this way. If authors want to surface discoverability, they can write CSS. If users want to do so, they can install user CSS or a JS extension, depending on their needs and desires. To make this possible I think the right way is to use the presence of the longdesc attribute itself as the trigger.

(I agree that easy discoverability is important. I think I wrote the first implementation that provided it. I just thinkthat an extra attribute is not a good way to do it, since you can do it with the existing attribute - and in practice, more effectively IMHO).

(In reply to comment #6)

Thanks Chaals. All good points. 

Chris do you agree? If so I'm okay with closing this bug.

The Task force agreed that we don't need to do this, because the use cases can be met by the longdesc attribute on its own with exactly the same amount of work.