A titan arum, by any other name...

Is this new attribute different at all from longdesc=""? If so, how? If not, is there any new information that would cause us to revisit the longdesc="" issue?

(In reply to comment #1)

> Is this new attribute different at all from longdesc=""? If so, how? 

Yes. The REQUIREMENTS section provides that information.

> is there any new information 

Yes. Please refer to the REFERENCES section. I have conducted research of examples in the wild that have with no visual link text clutter.
http://www.w3.org/html/wg/wiki/LongdescRetention#Examples_with_No_Visual_Link_Text_Clutter

The removal of @longdesc leaves specific user-requirements un-met. 

Call it what you want (@titan_arum), we need to ensure that the user-requirements are addressed. aria-describedby (http://www.w3.org/TR/wai-aria/) alone does not meet all of these requirements, so it appears that the only other solution is to introduce a new attribute or re-visit @longdesc and find ways to improve it to address concerns surrounding it's flaws.

Since it has been decided that @longdesc is fundamentally broken, this bug revisits the needs requirements and leaves it to the engineers to propose a workable solution.

Laura,

I had read your requirements and references sections prior to commenting in the first place. Nevertheless, I was unable to divine how describedby="" would differ from longdesc="", an attribute we've already decided to not include in HTML5. Could you let me know how it describedby="" would differ from longdesc=""?

Edward,
Are you then suggesting that the user-requirements are not valid? Or that the engineers cannot solve these problems and deliver on the need?  The needs are clear and with merit:

1. A programmatic mechanism to reference a specific a structured description,
internal or external to the document.

The ability to link one piece of data to another is the foundation of the web. Delivering on this feature/function should be simple.


2. A way to inform users and authors that a description is present/available
via user agent (UAs could provide an option to reveal the content of
describedby via a context menu, preference, or switch etc.). This also affords
a practical method for the curious and for developers who want a tool to check
the describedby descriptive content and keep it up to date.

Currently only Opera and (to a lesser extent) Firefox has a way to inform users of a link to a longer description that exposes this fact to both sighted and non-sighted users. This was one of the criticisms of @longdesc (that it was not exposed to sighted users), so here the difference between @longdesc as supported by the majority of today's browsers, and the 'new' attribute/function is more clearly articulated *as a requirement*, something that was perhaps not as clearly stated in HTML 4's @longdesc.


3. A device independent way to access the descriptive content.

Specifically, this feature *must* be accessible to keyboard interaction, including the ability to activate the link via a keyboard. Currently only Opera offers this functionality to @longdesc, so the new attribute would require support in all browsers.


4. An explicit provision that accessing descriptive content, whether internal
or external to the document containing the image, does NOT take the user away
from the user's position in the document containing the image where the verbose
descriptor was invoked.

We have numerous example of this type of functionality on the web today - I can think of shopping carts that automatically update quantities and totals without interrupting the 'page-flow' (linearizion of the DOM/page). Today to ensure this type of functionality we usually need to invoke the aria-live attribute, however ideally this would be native to the new attribute. 


5. A way to provide user control over exposition of the descriptor so that
rendering of the image and its description is not an either/or proposition. A
visual indicator of the description should NOT be a forced visual encumbrance
on sighted users by default.

Inserting an obtrusive native indicator on a web-page has serious negative design impacts: web art directors on large web projects in particular will simply resist obtrusive mechanisms inside their view-port 'canvas' (not to be confused with <canvas>), so we need to be able to ensure that 'discoverability' of extended descriptions does not impact on visual design - if we do not ensure this, content authors will simply not include longer descriptions, or 'style-away' the indicator using @hidden (which the editor has already confirmed means content that is not relevant to the page), or by using CSS display:none; which removes the indicator from the page flow for *all* users. We currently do not have a mechanism in HTML5 today that fits this requirement.


6. A method to reference a longer description of an image, without including
the content in the main flow of a page. 

Delivering a longer description of an image must be a user-choice function: non-sighted users will likely not *always* want to hear a long description of an image, especially if they are visiting a page (with an image that has a long description) more than once. A visual metaphor is the difference between glancing at an image, and studying an image: if you have studied an image intently once, you will likely only glance at it the second, third, or multiple other times. As well features such as JavaScript Light-boxes are specifically built to not feature text, and instead focus on inserting a larger copy of a thumbnail image in an "overlay" that deliberately obscures the page's text, in favor of placing all visual focus on the image. Thus the functional requirement is to deliver on this need.

So while this bug outlines functionality that was envisioned but not articulated in @longdesc, it remains open to a new mechanism that can deliver on the requirements rather than insisting on maintaining an attribute that many engineers see as fatally flawed. Perhaps we could call it @pheonix ?

John, I'm not making any claims about the requirements. I'm asking, I think pretty clearly, about the proposal to "mint a describedby attribute for the img element." My question is, in what specific ways, if any, would such a describedby="" attribute differ from longdesc=""?

(In reply to comment #6)
> John, I'm not making any claims about the requirements. I'm asking, I think
> pretty clearly, about the proposal to "mint a describedby attribute for the img
> element." My question is, in what specific ways, if any, would such a
> describedby="" attribute differ from longdesc=""?

It has a different name. That makes it magic.

(In reply to comment #6)
> John, I'm not making any claims about the requirements. I'm asking, I think
> pretty clearly, about the proposal to "mint a describedby attribute for the img
> element." My question is, in what specific ways, if any, would such a
> describedby="" attribute differ from longdesc=""?

Sorry, facetious earlier answer.

What Laura is asking for isn't to return longdesc. She's provided a well documented use case and associated requirements for a specific functionality. You keep saying, "This is longdesc. We decided against longdesc." She's not asking for longdesc, she's asking for a specific functionality.

Do you see this functionality implemented in HTML5? If so, perhaps you could point this out.

Hi Shelley,

I'm not saying describedby="" is longdesc="". I can't tell if it is or not. I'm asking for a description of *how* describedby="" would work, hopefully one sufficiently detailed so we can evaluate the extent to which it differs from longdesc="".

A description of requirements isn't an answer to this question. I'm not asking *what problem* describedby="" is intended to solve, I'm asking *how does it solve it*. What are the mechanics by which describedby="" would function. Until we have a sufficiently concrete proposal, it's impossible to evaluate the merits of the proposed new attribute.

(In reply to comment #9)
> Hi Shelley,
> 
> I'm not saying describedby="" is longdesc="". I can't tell if it is or not. I'm
> asking for a description of *how* describedby="" would work, hopefully one
> sufficiently detailed so we can evaluate the extent to which it differs from
> longdesc="".
> 
> A description of requirements isn't an answer to this question. I'm not asking
> *what problem* describedby="" is intended to solve, I'm asking *how does it
> solve it*. What are the mechanics by which describedby="" would function. Until
> we have a sufficiently concrete proposal, it's impossible to evaluate the
> merits of the proposed new attribute.

From my reading of what Laura provided, I would imagine describedby provides a way to associate long complex description of an image specifically geared towards the blind. There currently is no way to do this. 

For myself, how I'd use describedby: 

I could put the text in the page, but I want this text for the blind -- it's an assistance for them, no different than braille in elevators, and captions for tv shows. The text is an equalizer--providing a text description of that, which others can visually perceive.

The complex description would either be in the same page, or a separate page. I would prefer a separate page, because I don't want to add to the page bandwidth for those people who wouldn't need the long description. 

However, I would like all user agents to provide access to the long description, not just user agents for those with visual impairments. After all, people can turn on captions for tv shows, even if they don't _need_ the captions. People can read the braille in an elevator, even if they don't _need_ the braille. 

I don't want to provide a link, because I don't people to assume I'm providing a caption, or a larger version of the image. I certainly don't want the text to be visible. That would be too much like trying to re-create Zork in the page. Remember Zork? 

>You are standing in front of a green house. There is a mailbox in front of the green house.

> open mailbox

>In the mailbox there is a letter

> open letter

Well, you get the picture. Zork was a great game for a text environment, but I don't think it would hold its own against the graphical games today. But when you only have text...

I would prefer that everyone can see my image directly, but some people can't. Rather than them being faced with a gaping hole in the page, I'd like to provide something. It may not be as nice, but at least they'll know what's going on.

For user agents like a visual browser, my preferences would be a right mouse click menu item, because that's usually the menu for choosing different options for processing the page content. If the browser wanted to add an icon to the status bar when my cursor was over the image, highlighting that there is a long description, that would be OK, too. 

Is that good?

Edward O'Connor wrote:
> My question is, in what specific ways, if any, would such a
> describedby="" attribute differ from longdesc=""?

1) It would have a 'universal' control that all users, not just blind users, could use to easily access extended descriptions. We could *mandate* that all browsers place access into a contextual menu, or *mandate* that a browser tool-bar include a button of some kind that would be grayed-out, but would become active if one or more images in a page had longer descriptions associated to them: perhaps if more than 1 image like this existed on the page, the button would expand a menu that provided direct access to any and all of those descriptions - a 'drop-down' like rendering or such. I personally believe however that we might also want to leave the User Agents to develop solutions that would scale to different platforms/implementations - so that on a hand-held device it might be done one-way, whilst on a desk-top version of the browser another way. But the biggest and most important difference is mandated and common User Agent support for the new attribute, given that some browsers today still do not support HTML 4's @longdesc attribute (and we really can't blame page authors for that)

2) In the only real browser implementation of @longdesc support today, to access the long description for sighted users one must place your cursor over the image to then access the right-click contextual menu. (Screen readers announce the existence of the link when announcing the image's alt value, so for Assistive Technology that works agnosticly with any browser, this is less an issue for that class of technology)  

This new attribute then should also be available via key-board access for sighted users not using a mouse, including (but not exclusively) users with mobility impairments. So the attribute would also make the image focus-able to keyboard use (or conversely, if a browser tool-bar button was chosen, then that button, when in active state, could also be focused on via keyboard tabbing).

3) Currently aria-describedby can only be linked to IDREFs, whereas the new attribute must be able to be linked to both IDREFS and URI's

And now, I will ask you a specific question: do you disagree with any of the articulated user requirements? If yes, which user-requirement do you disagree with, and why?

When *combined* with sister technologies like ARIA and HTML+RDFa, doesn't HTML5 already meet Requirements 1 and 6?

> 1. A programmatic mechanism to reference a specific a structured
> description, internal or external to the document.

We can reference descriptions internal to the document:

   <img src="foo.jpg" alt="{Short alternative}" aria-describedby="long">
   <p id="long">{Long description}</p>

We can transclude long descriptions:

   <img src="foo.jpg" alt="{Short alternative}" aria-describedby="long">
   <iframe id="#long" href="long-description.html" seamless></iframe>

We can indicate a link points to a long description for an image:

   <img src="foo.jpg" id="image" alt="{Short alternative}"
        resource="long-description.html">
   <p>
       <a xmlns:dc="http://purl.org/dc/elements/1.1/" about="#image"
          href="long-description.html"
          rel="http://purl.org/dc/elements/1.1/description">
           Long description
       </a>
   </p>

We can reference an external resource as the long description with invisible metadata:

   <img id="image"
        src="foo.jpg" 
        xmlns:dc="http://purl.org/dc/elements/1.1/"
        alt="{Short alternative}"
        about="#image"
        rel="dc:description"
        resource="long-description.html">

> 6. A method to reference a longer description of an image, without including
> the content in the main flow of a page.

"aside" designates content that is not part of the "main flow". This could be combined with "aria-describedby" like so:

    <img alt="Short alternative" aria-describedby="long">
    <aside id="#long">Long alternative</aside>

Requirements 2-5 look like UI requirements, rather than requiring additional language features.

I may be mistaken, but I think ARIA, HTML5, and HTML-RDFa technologies allow user agents to adopt the UI behaviour detailed in Requirements 2-5 in relation to "dc:description", "aria-describedby" and "aside". (If someone believes they do not, could they please cite where the drafts forbid which behaviour described?)

I've no objection to including non-normative suggestions for UI in these drafts, or other documents such as the ARIA User Agent Implementation Guide 1.0 or UAAG 2.0 Techniques. But, in general, ARIA, HTML5, and HTML-RDFa do not *mandate* any particular UI, and I don't think that they should make an exception for long descriptions. I've no particular reason to think user agents *will* adopt the described behaviour, but I've little confidence in the magic power of the spec to force them too either, or any reason to believe such ex cathedra mandates would be ideal for all users in all circumstances.

I've elaborated how I think HTML5 could meet Requirements 1 and 6, and be have conforming implementations meeting Requirements 2-5, when used together with these other technologies.

However, I've argued elsewhere that HTML5 should maintain a *native* facility for designating long alternatives for "img" elements, and that on balance keeping "longdesc" is the best choice:

http://www.w3.org/2002/09/wbs/40318/issue-30-objection-poll/results

If we do mint a new feature and it differs significantly from "aria-describedby" (for example, by taking a URI as a value rather than an IDREF), then it should be called something *other* than "describedby" to reduce confusion on the part of authors (e.g. a "longdescriptionhref" attribute or a "longdescription" element).

But if we mint a new feature because "aria-describedby" is *not* sufficient for image long descriptions - for example, if being able to reference external documents as long descriptions is critical - then we should also be trying to fix ARIA (the generic level).

Looking at the above, the key reason proposed for minting a new attribute differing from "aria-describedby" is in order to designate external documents as long descriptions. Why do users need this? Why hasn't PFWG expressed this requirement in ARIA?

(In reply to comment #12)
> When *combined* with sister technologies like ARIA and HTML+RDFa, doesn't HTML5
> already meet Requirements 1 and 6?
> 
> > 1. A programmatic mechanism to reference a specific a structured
> > description, internal or external to the document.
> 
> We can reference descriptions internal to the document:
> 
>    <img src="foo.jpg" alt="{Short alternative}" aria-describedby="long">
>    <p id="long">{Long description}</p>
> 
> We can transclude long descriptions:
> 
>    <img src="foo.jpg" alt="{Short alternative}" aria-describedby="long">
>    <iframe id="#long" href="long-description.html" seamless></iframe>
> 
> We can indicate a link points to a long description for an image:
> 
>    <img src="foo.jpg" id="image" alt="{Short alternative}"
>         resource="long-description.html">
>    <p>
>        <a xmlns:dc="http://purl.org/dc/elements/1.1/" about="#image"
>           href="long-description.html"
>           rel="http://purl.org/dc/elements/1.1/description">
>            Long description
>        </a>
>    </p>
> 

We don't want a link visually available, as I discussed in my earlier scenario. People would take it to be a longer caption, which it isn't.

> We can reference an external resource as the long description with invisible
> metadata:
> 
>    <img id="image"
>         src="foo.jpg" 
>         xmlns:dc="http://purl.org/dc/elements/1.1/"
>         alt="{Short alternative}"
>         about="#image"
>         rel="dc:description"
>         resource="long-description.html">
>

I have a question to the RDFa community about this, especially in light of previous discussions about XForms[1]. The @resource isn't intended to be clickable, but as Mark pointed out in the XForms discussion, user agents can go above and beyond the intended RDFa purpose. 

A Dublin Core description is a text-based content description of the image. Typically, these have been more captions, but I suppose it could also be defined as an exact text description of the image, suitable for the visually impaired. It isn't defined to this level of exactitude, which does concern me about its use in this regard. 

This would mean, then, that user agents such as browsers would have to provide some way to "click through" to the longer description. AT devices would then have to provide audio cues and a way of "clicking through" to the description. All the requirements John and Laura provided would have to be met--this doesn't bypass these requirements. 

The HTML5 specification would have to specifically provide an expected behavior for this unique use of RDFa, which could be a bit strange in the document. It could be tricky to implement--probably a lot trickier than just creating an attribute that provided the URI.

And if people have been using RDFa with images, as I have, you could also be "breaking" backwards compatibility. 

Seems a lot of ifs, ands, or buts, associated with this. I wouldn't mind hearing what some of the RDFa experts think on this suggestion.

Interesting idea, though.
 
> > 6. A method to reference a longer description of an image, without including
> > the content in the main flow of a page.
> 
> "aside" designates content that is not part of the "main flow". This could be
> combined with "aria-describedby" like so:
> 

>     <img alt="Short alternative" aria-describedby="long">
>     <aside id="#long">Long alternative</aside>
>

How do AT devices work with aside now? 
 
> Requirements 2-5 look like UI requirements, rather than requiring additional
> language features.
>

User agent behavior and requirements are also included in HTML5. 
 
> I may be mistaken, but I think ARIA, HTML5, and HTML-RDFa technologies allow
> user agents to adopt the UI behaviour detailed in Requirements 2-5 in relation
> to "dc:description", "aria-describedby" and "aside". (If someone believes they
> do not, could they please cite where the drafts forbid which behaviour
> described?)
> 

If you want consistent behavior among all the agents, then the behaviors, appearance, et al do need to defined in the document. 

Why would you have normative references for UI for some elements and objects, but not others?

> I've no objection to including non-normative suggestions for UI in these
> drafts, or other documents such as the ARIA User Agent Implementation Guide 1.0
> or UAAG 2.0 Techniques. But, in general, ARIA, HTML5, and HTML-RDFa do not
> *mandate* any particular UI, and I don't think that they should make an
> exception for long descriptions. 

On the contrary, the HTML5 document has mandated behavior and appearance for many elements and attributes. For reference see progress, noscript, and others.

I've no particular reason to think user agents
> *will* adopt the described behaviour, but I've little confidence in the magic
> power of the spec to force them too either, or any reason to believe such ex
> cathedra mandates would be ideal for all users in all circumstances.
> 

If the user agents wish to comply with standards, as they all fall all over each other to assure people they do, the specifying a standard UI should be enough to "force" the user agents to comply. 


> I've elaborated how I think HTML5 could meet Requirements 1 and 6, and be have
> conforming implementations meeting Requirements 2-5, when used together with
> these other technologies.
> 
> However, I've argued elsewhere that HTML5 should maintain a *native* facility
> for designating long alternatives for "img" elements, and that on balance
> keeping "longdesc" is the best choice:
> 
> http://www.w3.org/2002/09/wbs/40318/issue-30-objection-poll/results
>

Agree. And well argued objection.

 
> If we do mint a new feature and it differs significantly from
> "aria-describedby" (for example, by taking a URI as a value rather than an
> IDREF), then it should be called something *other* than "describedby" to reduce
> confusion on the part of authors (e.g. a "longdescriptionhref" attribute or a
> "longdescription" element).
> 
> But if we mint a new feature because "aria-describedby" is *not* sufficient for
> image long descriptions - for example, if being able to reference external
> documents as long descriptions is critical - then we should also be trying to
> fix ARIA (the generic level).
> 
> Looking at the above, the key reason proposed for minting a new attribute
> differing from "aria-describedby" is in order to designate external documents
> as long descriptions. Why do users need this? Why hasn't PFWG expressed this
> requirement in ARIA?

Grr, I always forget the links

http://lists.w3.org/Archives/Public/public-forms/2009Mar/0041.html

(In reply to comment #13)
> (In reply to comment #12)

> > We can reference an external resource as the long description with invisible
> > metadata:
> > 
> >    <img id="image"
> >         src="foo.jpg" 
> >         xmlns:dc="http://purl.org/dc/elements/1.1/"
> >         alt="{Short alternative}"
> >         about="#image"
> >         rel="dc:description"
> >         resource="long-description.html">
> >
> 
> I have a question to the RDFa community about this, especially in light of
> previous discussions about XForms[1]. The @resource isn't intended to be
> clickable, but as Mark pointed out in the XForms discussion, user agents can go
> above and beyond the intended RDFa purpose. 

Also see: http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Aug/0098

]]
ISSUE-45 (cite and longdesc support): Consider supporting cite and longdesc attributes in XHTML+RDFa and HTML+RDFa [RDFa 1.1 in XHTML 1.1]
[[

(In reply to comment #12)
Benjamin Hawkes-Lewis wrote:
> 
> We can reference descriptions internal to the document:
> 
>    <img src="foo.jpg" alt="{Short alternative}" aria-
> describedby="long">
>    <p id="long">{Long description}</p>
> 
> We can transclude long descriptions:
> 
>    <img src="foo.jpg" alt="{Short alternative}" aria-
> describedby="long">
>    <iframe id="#long" href="long-description.html" seamless></iframe>

Both of these techniques fail to satisfy requirement 6:

"6. A method to reference a longer description of an image, without including
the content in the main flow of a page. 

Delivering a longer description of an image must be a user-choice function:
non-sighted users will likely not *always* want to hear a long description of
an image"




> 
> We can indicate a link points to a long description for an image:
> 
>    <img src="foo.jpg" id="image" alt="{Short alternative}"
>         resource="long-description.html">
>    <p>
>        <a xmlns:dc="http://purl.org/dc/elements/1.1/" about="#image"
>           href="long-description.html"
>           rel="http://purl.org/dc/elements/1.1/description">
>            Long description
>        </a>
>    </p>


This fails to satisfy requirement 5:

"5. A way to provide user control over exposition of the descriptor so that
rendering of the image and its description is not an either/or proposition. A
visual indicator of the description should NOT be a forced visual encumbrance
on sighted users by default.

Inserting an obtrusive native indicator on a web-page has serious negative
design impacts: web art directors on large web projects in particular will
simply resist obtrusive mechanisms inside their view-port 'canvas'"

This was indeed an early technique that the web accessibility community used in the late 90's, most often as an anchor element around 'd' or 'd-link'. The 'visual' intrusion of a link associated to an image was an issue then, and so we had a situation where authors created 'invisible' (actually hidden) d-links that were targeted to screen reading technology. The use of d-links was deprecated in favor of using longdesc with the release of WCAG 1. (http://www.w3.org/TR/WCAG10-TECHS/#def-d-link / http://www.w3.org/TR/WCAG10-HTML-TECHS/#img-dlink-invis) 

There is no indication that we will not see a return to this type of behaviour: in fact, as examples from the wild show us, the hiding technique is alive and well, but now uses CSS to place the link off-screen. As a result, these types of techniques then impact on requirement 2:

" 2. A way to inform users and authors that a description is present/available
via user agent ... a way to inform users
of a link to a longer description that exposes this fact to both sighted and
non-sighted users."


> 
> We can reference an external resource as the long description with
> invisible
> metadata:
> 
>    <img id="image"
>         src="foo.jpg"
>         xmlns:dc="http://purl.org/dc/elements/1.1/"
>         alt="{Short alternative}"
>         about="#image"
>         rel="dc:description"
>         resource="long-description.html">

This is an interesting thought exercise. While this does certainly better describe what it is we have, it does not address how we provide the long description to the end user(s). In this regard, how does 'resource' and 'longdesc' differ? (answer: longdesc has some user-agent support today: most screen readers and Opera)

'Resource' here certainly intimates a link, but how would user-agents a) expose that link, b) allow activation of that link? For example, in Firefox today, right-clicking on an image with a longdesc value will render in the contextual menu the fact that the longdesc exists, and even provide the full URL of the text, but there is no programmatic way of actually accessing that link short of noting it and then entering the URL into the address bar - and 'copy and paste' of text in the context menu is not achievable, making the process extremely onerous for the end user. 

< aside> 
Regarding meta-data,see also:
http://microformats.org/wiki/rel-longdesc
http://microformats.org/wiki/existing-rel-values#POSH_usage
< /aside> 


> 
> > 6. A method to reference a longer description of an image, without
> including
> > the content in the main flow of a page.
> 
> "aside" designates content that is not part of the "main flow". This
> could be
> combined with "aria-describedby" like so:
> 
>     <img alt="Short alternative" aria-describedby="long">
>     <aside id="#long">Long alternative</aside>

At the risk of being overly pedantic, <aside> is defined as: "... content that is tangentially related to the content that forms the main textual flow of a document." http://dev.w3.org/html5/markup/aside.html#aside 

However, a sophisticated image in a document will likely rarely be tangential - in fact more often than not it is likely the primary focus/intent of the containing document, so a textual explanation of the visual asset is not tangential at all.

Another issue is that 'aria-describedby' lacks the ability for the screen-reader user to choose to access the text or not, (Requirement 6): 

"Delivering a longer description of an image must be a user-choice function:
non-sighted users will likely not *always* want to hear a long description of
an image, especially if they are visiting a page (with an image that has a long
description) more than once."

Aria-describedby (at least in WAI-ARIA 1.0) is an 'always-on' association, it cannot be toggled on or off.

Finally, this does not address the need to not have the text visible to end users at all times: often the critical text description of the image is only required by a significantly smaller percentage of the total users, and for 'artistic' considerations the text on the same page as the image is counter to the artistic requirements of the page: CSSquirrel articulates this in his blog-post (http://www.cssquirrel.com/2010/08/16/comic-update-alone-in-the-pitch-black-dark/), and I have previously asked how this would work in image gallery pages that use tools such as JavaScript Lightbox? If we have 15 thumbnails on one page, will we have 15 asides as well? (and what impact does this have on those with cognitive challenges?) And how will this "look"?



> 
> I've no objection to including non-normative suggestions for UI in
> these
> drafts, or other documents such as the ARIA User Agent Implementation
> Guide 1.0
> or UAAG 2.0 Techniques. But, in general, ARIA, HTML5, and HTML-RDFa do
> not
> *mandate* any particular UI, and I don't think that they should make an
> exception for long descriptions. I've no particular reason to think
> user agents
> *will* adopt the described behaviour, but I've little confidence in the
> magic
> power of the spec to force them too either, or any reason to believe
> such ex
> cathedra mandates would be ideal for all users in all circumstances.

Others (notably Shelly) have already pointed out that HTML5 does in fact go down this route ("...For reference see progress, noscript, and others.") I've already stated that I am less adamant of this, as I believe that different platforms and agents will need some UI flexibility: again for example a mobile version of a browser might interact slightly differently than the same desktop browser. I don't think tying the hands too tightly achieves any  progress: I am more interested in seeing that browsers expose the full functionality required, and less so on how they achieve that.


> 
> However, I've argued elsewhere that HTML5 should maintain a *native*
> facility
> for designating long alternatives for "img" elements, and that on
> balance
> keeping "longdesc" is the best choice:
> 
> http://www.w3.org/2002/09/wbs/40318/issue-30-objection-poll/results

Thumbs up!

> 
> If we do mint a new feature and it differs significantly from
> "aria-describedby" (for example, by taking a URI as a value rather than
> an
> IDREF), then it should be called something *other* than "describedby"
> to reduce
> confusion on the part of authors (e.g. a "longdescriptionhref"
> attribute or a
> "longdescription" element).

I agree. The choice of term on this bug's title is slightly confusing, as we already have aria-describedby which *does not* achieve all of the user requirements. But as I have stated often, the name is less important than the functionality. (It's also interesting that you are here suggesting the creation of an element rather than an attribute, or was this just a slip of the pen?)

> 
> But if we mint a new feature because "aria-describedby" is *not*
> sufficient for
> image long descriptions - for example, if being able to reference
> external
> documents as long descriptions is critical - then we should also be
> trying to
> fix ARIA (the generic level).

This has already been noted as a potential action item for WAI-ARIA 2 (searching for reference). This has been discussed extensively before in the HTML a11y Task Force, notably at their face-to-face meeting in Birmingham earlier this year.

> 
> Looking at the above, the key reason proposed for minting a new
> attribute
> differing from "aria-describedby" is in order to designate external
> documents
> as long descriptions. Why do users need this? Why hasn't PFWG expressed
> this
> requirement in ARIA?

When WAI-ARIA was being written, we had @longdesc that natively achieved this function. Further both WCAG 1 (http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-text-equivalent) and WCAG 2 (http://www.w3.org/WAI/GL/2010/WD-WCAG20-TECHS-20100708/H45.html) presumed that @longdesc was (and would remain) a valid technique to achieve the required functionality. 

(It is perhaps also worth noting that WAI has a long history of stating that ARIA is intended to be a bridging technology, but would prefer to see native semantics, and @longdesc was a native semantic mechanism. See: http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements#The_use_of_semantically_rich_elements_is_an_expressed_desire_of_the_W3C_Accessibility_.28WAI.29_community)

However, since HTML5 has no qualms of establishing 'willful violations' of current existing specs outside of HTML5, it breaks the chain of functionality that had been previously established. Whether or not we can address this in a future version of ARIA is not under question, but if or until such time as we do, the willful violation removes an important accessibility function, and does not offer any credible alternative to date. Thus we must re-instate @longdesc (for backwards compatibility) or mint a new attribute that delivers on the functionality required.

Thus this bug.

> We don't want a link visually available, as I discussed in my earlier
> scenario.

You might not, but other developers might.

In particular, the "WAI Consensus Resolutions on Text alternatives in HTML 5" expressly requests this facility, without specifying the link needed to be invisible:

http://www.w3.org/2009/06/Text-Alternatives-in-HTML5

This technique has better backwards compatibility and discoverability than any other approach other than including the long description on the same page.

> People would take it to be a longer caption, which it isn't.

Who are "people" here? End-users? They *might*. But I don't see why they should misunderstand a link that says "Long description", but understand a context menu item that also says "Long description". Is there evidence that people think the description links suggested by WCAG 1.0 and WCAG 2.0 Techniques point to longer captions?

http://www.w3.org/TR/WCAG10/#q16

http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G190

> The HTML5 specification would have to specifically provide an expected
> behavior for this unique use of RDFa, which could be a bit strange in the
> document.

Wouldn't it be inappropriate for anyone other than Dublin Core to mandate how their vocabulary should be consumed? It would be appropriate for UAAG 2.0 Techniques to make some suggestions, but probably out of place in HTML5+RDFa or HTML5.

> A Dublin Core description is a text-based content description of the image.
Typically, these have been more captions, but I suppose it could also be
defined as an exact text description of the image, suitable for the visually
impaired. It isn't defined to this level of exactitude, which does concern me
about its use in this regard.

[snip]

> And if people have been using RDFa with images, as I have, you could also be
> "breaking" backwards compatibility.

If DC's "description" is so mismatched with the concept of long description that treating it as a long description would cause backward incompatibilities, then we need to use a different vocabulary. Fortunately, if one doesn't already exist, anyone is free to create one. Trying to reuse AccessForAll in some form might make sense:

http://www.imsglobal.org/accessibility/

> How do AT devices work with aside now?

I assume by "AT devices", you're thinking of AT software like JAWS or Dragon Naturally Speaking or ZoomText (they're not what I'd call a "device")?

I've not tested; I suspect they don't treat it differently to "div" at the moment.

What's the import of your question? A lot of AT still does nothing at all with "longdesc", and obviously no AT does anything with the proposed "describedby" attribute. Long descriptions are a perfectly legitimate need, but they're hardly top of the accessibility priority list so I wouldn't be surprised if implementation dragged years behind the potential offered by (draft!) specifications.

For evidence of low prioritisation, see:

   * http://www.nvda-project.org/ticket/392
   * http://www.nvda-project.org/ticket/809

> User agent behavior and requirements are also included in HTML5. 

UA behaviour and requirements yes, UI requirements generally not.

> If you want consistent behavior among all the agents, then the behaviors,
appearance, et al do need to defined in the document

I want consistent behaviour for things like parsing, DOM APIs, form submission, error handling, script execution, and semantic interpretation.

I don't want consistent UI or appearance enforced by the HTML specification.

The HTML WG is in no position to design the ideal UI for all user agents of our semantic markup - or even imagine all the possible platforms, devices, and user agents that we'd need to cover! User agents, like users, vary, and that's a good thing.

Or as Mark Birkbeck put it in the email you cite in the context of RDFa: "we don't define *any* behaviour  If a browser wanted to make it clickable that would be up to them, i.e., we don't say 'this attribute must never be clickable', because we have no right to."

(This is not to deny that convention plays a role in good design, or even that UI standards are a bad thing: I just don't think they should be conflated with document format/metadata standards.)

> On the contrary, the HTML5 document has mandated behavior and appearance for
many elements and attributes. For reference see progress, noscript, and others.

Sorry - where are the MUST-level "appearance" requirements for "progress" and "noscript"? I see only SHOULD- or MAY-level suggestions.

http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#the-progress-element

http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-progress-element-0

http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#the-noscript-element

http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#display-types

> If the user agents wish to comply with standards, as they all fall all over
> each other to assure people they do, the specifying a standard UI should be
> enough to "force" the user agents to comply.

I think if HTML started mandating UI, then the costs of full compliance (suboptimal user experiences) would quickly outweigh the benefits (marketing to developers).

(In reply to comment #17)
> > We don't want a link visually available, as I discussed in my earlier
> > scenario.
> 
> You might not, but other developers might.

So then options and choices are a good thing, right? 

Just as overtly mandating browsers on UI requirements (and the relationship of diminishing returns that invokes) so too with content authors! There are many voices at the table of any large project, and why should the art director take the back-seat to the accessibility guy? What happens when the art-director is able to over-ride the accessibility guy because of 'marketing considerations'? 


> 
> > How do AT devices work with aside now?
> 
> I assume by "AT devices", you're thinking of AT software like JAWS or Dragon
> Naturally Speaking or ZoomText (they're not what I'd call a "device")?
> 
> I've not tested; I suspect they don't treat it differently to "div" at the
> moment.
> 
> What's the import of your question? A lot of AT still does nothing at all with
> "longdesc", and obviously no AT does anything with the proposed "describedby"
> attribute. 

Please, can we be sure to make the distinction between AT and screen-readers here? AT can include technology such as speech-recognition that allow mobility impaired users (quadriplegics for example) a means to interact with their computer, or head-mice and other alternative switches, or screen magnifiers, one-hand keyboards, etc.. In this case *LACK OF BROWSER SUPPORT* means they cannot interact with the DOM entry that is the longdesc value. So suggesting that poor AT support is somehow the culprit here is both false and misleading - poor browser support to date has been the #1 reason for lack of active pick-up of @longdesc, not that it is some-how a flawed attribute.

As far as screen-reader support goes for @longdesc, it is actually very good, with market leaders JAWS, WindowEyes and Hal/Supernova providing support today.

As far as the semantic value of <aside> (or any of the other newly minted landmark elements in HTML5) AFAIK no technology today really does anything with it: until we see full HTML5 parser support it's a 'work-in-progress' element that relies very much on backwards compat. - (yep, it's a meaningless container)


> Long descriptions are a perfectly legitimate need, but they're
> hardly top of the accessibility priority list so I wouldn't be surprised if
> implementation dragged years behind the potential offered by (draft!)
> specifications.
> 
> For evidence of low prioritisation, see:
> 
>    * http://www.nvda-project.org/ticket/392
>    * http://www.nvda-project.org/ticket/809

One screen-reader's choice in approaching missing functionality is hardly an indication of trends. Using this alone as justification we might as well remove all the Web Forms 2.0 stuff from HTML5, as only Opera today supports it. This is a poor argument IMHO.

(In reply to comment #17)
> > We don't want a link visually available, as I discussed in my earlier
> > scenario.
> 
> You might not, but other developers might.

And they have an element ready to hand, with the link <a>. But there is nothing comparable for those of us who don't want a visual link. 

> 
> In particular, the "WAI Consensus Resolutions on Text alternatives in HTML 5"
> expressly requests this facility, without specifying the link needed to be
> invisible:
> 
> http://www.w3.org/2009/06/Text-Alternatives-in-HTML5
> 
> This technique has better backwards compatibility and discoverability than any
> other approach other than including the long description on the same page.
>

But you see, I'm only talking about what I want, not what is in some spec or another. If I were going to provide a separate page with a long, complex description of an image that's specifically for the visually impaired, I would like to be able to do so in a way that only the blind see it (unless people know it's purpose and it is exposed as a specific type of link).
 
> > People would take it to be a longer caption, which it isn't.
> 
> Who are "people" here? End-users? They *might*. But I don't see why they should
> misunderstand a link that says "Long description", but understand a context
> menu item that also says "Long description". Is there evidence that people
> think the description links suggested by WCAG 1.0 and WCAG 2.0 Techniques point
> to longer captions?
>

What is there about the term, long description, that is specific to visual impairment?
 
> http://www.w3.org/TR/WCAG10/#q16
> 
> http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G190
> 
> > The HTML5 specification would have to specifically provide an expected
> > behavior for this unique use of RDFa, which could be a bit strange in the
> > document.
> 
> Wouldn't it be inappropriate for anyone other than Dublin Core to mandate how
> their vocabulary should be consumed? It would be appropriate for UAAG 2.0
> Techniques to make some suggestions, but probably out of place in HTML5+RDFa or
> HTML5.
>

Hard to say. It could be ugly. Could get tricky. Would have to require a great deal of effort across groups.

 
> > A Dublin Core description is a text-based content description of the image.
> Typically, these have been more captions, but I suppose it could also be
> defined as an exact text description of the image, suitable for the visually
> impaired. It isn't defined to this level of exactitude, which does concern me
> about its use in this regard.
> 
> [snip]
> 
> > And if people have been using RDFa with images, as I have, you could also be
> > "breaking" backwards compatibility.
> 
> If DC's "description" is so mismatched with the concept of long description
> that treating it as a long description would cause backward incompatibilities,
> then we need to use a different vocabulary. Fortunately, if one doesn't already
> exist, anyone is free to create one. Trying to reuse AccessForAll in some form
> might make sense:
> 
> http://www.imsglobal.org/accessibility/
>

Could be. I mainly focused on dublin core's description because that's what was used in the example. 
 
> > How do AT devices work with aside now?
> 
> I assume by "AT devices", you're thinking of AT software like JAWS or Dragon
> Naturally Speaking or ZoomText (they're not what I'd call a "device")?
> 
> I've not tested; I suspect they don't treat it differently to "div" at the
> moment.
> 
> What's the import of your question? A lot of AT still does nothing at all with
> "longdesc", and obviously no AT does anything with the proposed "describedby"
> attribute. Long descriptions are a perfectly legitimate need, but they're
> hardly top of the accessibility priority list so I wouldn't be surprised if
> implementation dragged years behind the potential offered by (draft!)
> specifications.
>

The thing is, we need to define what different categories of user agents do with aside, so we also need to do the same with whatever ends up as Laura's described-by. 

If there isn't anything mandating behavior, we really couldn't blame described-by if it's use is sporadic, and maybe even incorrectly applied. 
 
> For evidence of low prioritisation, see:
> 
>    * http://www.nvda-project.org/ticket/392
>    * http://www.nvda-project.org/ticket/809
> 
> > User agent behavior and requirements are also included in HTML5. 
> 
> UA behaviour and requirements yes, UI requirements generally not.
> 
> > If you want consistent behavior among all the agents, then the behaviors,
> appearance, et al do need to defined in the document
> 
> I want consistent behaviour for things like parsing, DOM APIs, form submission,
> error handling, script execution, and semantic interpretation.
> 
> I don't want consistent UI or appearance enforced by the HTML specification.
> 
> The HTML WG is in no position to design the ideal UI for all user agents of our
> semantic markup - or even imagine all the possible platforms, devices, and user
> agents that we'd need to cover! User agents, like users, vary, and that's a
> good thing.
> 
> Or as Mark Birkbeck put it in the email you cite in the context of RDFa: "we
> don't define *any* behaviour  If a browser wanted to make it clickable that
> would be up to them, i.e., we don't say 'this attribute must never be
> clickable', because we have no right to."
> 
> (This is not to deny that convention plays a role in good design, or even that
> UI standards are a bad thing: I just don't think they should be conflated with
> document format/metadata standards.)
>

But we do specify behavior and appearance in HTML5. I'm not talking about RDFa, I'm talking about HTML5. If we want something in HTML5 to meet Laura's requirements and needs, then part of this requires some control over how UAs handle the item.

 
> > On the contrary, the HTML5 document has mandated behavior and appearance for
> many elements and attributes. For reference see progress, noscript, and others.
> 
> Sorry - where are the MUST-level "appearance" requirements for "progress" and
> "noscript"? I see only SHOULD- or MAY-level suggestions.
> 

So how do we define EXPECTED?

http://dev.w3.org/html5/spec/rendering.html#the-progress-element-0

I see EXPECTED as equivalent to MUST. Perhaps the use of the word EXPECTED is incorrect, and too vague for use in a spec, but that's what we have. 

If it would be better, we can re-coach the requirements for behavior associated with this item using EXPECTED. 

(And I never point to WhatWG documents within the W3C bugzilla database -- we have no control over WhatWG, this database is for the W3C documents. There is no guarantee the documents are the same.)

> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#the-progress-element
> 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-progress-element-0
> 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#the-noscript-element
> 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#display-types
>

Again, when I see EXPECTED, I _expect_ it to be treated as MUST. 

HTML isn't a compiler language. Rules of use are just as important as rules of parsing.
 
> > If the user agents wish to comply with standards, as they all fall all over
> > each other to assure people they do, the specifying a standard UI should be
> > enough to "force" the user agents to comply.
> 
> I think if HTML started mandating UI, then the costs of full compliance
> (suboptimal user experiences) would quickly outweigh the benefits (marketing to
> developers).

And yet the NOSCRIPT section was updated, just because user agents did not implement the same behaviors for this element. 

I think we're also conflating all aspects of behavior, expectations, and presentation into the term UI.

Feel free to scrutinize:  http://malform.no/testing/longdesc/

(In reply to comment #16)

On 29 Aug 2010, at 19:21, John Foliot <jfoliot@stanford.edu> wrote:
> Benjamin Hawkes-Lewis wrote:

> > We can reference descriptions internal to the document:

[snip]

> > We can transclude long descriptions:

[snip]

> Both of these techniques fail to satisfy requirement 6

Those two techniques were intended to satisfy Requirement 1 not Requirement 6.

I don't see why those Requirements need to be satisfied by the same
features/techniques, *but* the RDFa approach does satisfy both 1 and 6.

> > We can indicate a link points to a long description for an image:

> This fails to satisfy requirement 5:

> "5. A way to provide user control over exposition of the descriptor so that
> rendering of the image and its description is not an either/or proposition. A
> visual indicator of the description should NOT be a forced visual encumbrance
> on sighted users by default.["]

No it doesn't, since user agents are free to hide links designated as long
descriptions and provide a context menu item on the image to follow the link -
if they agree with you that would be the best user interface for their users.

> as examples from the wild show us, the hiding technique is alive and
> well, but now uses CSS to place the link off-screen.

Indeed.

> As a result, these types of techniques then impact on requirement 2:

> " 2. A way to inform users and authors that a description is
> present/available via user agent ... a way to inform users of a link to a
> longer description that exposes this fact to both sighted and non-sighted
> users."

Note, even if you hide the link normally to satisfy art directors, you could
style the link visible when the picture is hovered or when the link receives
focus. This still leaves speech recognition users out in the cold, but I guess
they could reject your art director-ordered styles or use a link list (such as
Opera provides).

In any case, with the link annotation technique I suggested, a user agent could
(for example) change the cursor over the image to indicate a long description
is present, expose a context menu item on the image pointing to the link
destination, and maybe provide some mechanism for listing available long description
links for speech recognition users - all regardless of how the link was styled.

> how does 'resource' and 'longdesc' differ? (answer: longdesc has some
> user-agent support today: most screen readers and Opera)

Doesn't seem like a relevant question to whether we introduce "describedby".

> 'Resource' here certainly intimates a link, but how would user-agents a)
> expose that link, b) allow activation of that link?

That's up to user agents.

> For example, in Firefox today, right-clicking on an image with a longdesc
> value will render in the contextual menu the fact that the longdesc exists,
> and even provide the full URL of the text, but there is no programmatic way
> of actually accessing that link short of noting it and then entering the URL
> into the address bar - and 'copy and paste' of text in the context menu is
> not achievable, making the process extremely onerous for the end user.

I'm not sure what you mean by "no programmatic way": there *is* programmatic
access via the accessibility API and the DOM.

Firefox's built-in "longdesc" UI is unhelpful to the point of uselessness and I
believe is going to be removed along with the rest of the Properties dialog.
Fortunately, Firefox supports an add-on architecture, and there are addons
providing less useless UIs for "longdesc" access. Given we don't expect Firefox
to be self-voicing (for example), I guess this isn't totally unreasonable even
though I would prefer built-in UI. The bug remains open:

https://bugzilla.mozilla.org/show_bug.cgi?id=1996

(Incidentally, the fact that it may take a whole ecosystem of collaborating
hardware and software (switch devices, browsers, browser addons, platform
accessibility APIs, other applications like screen readers, search engines) to
produce an accessible user experience is one more reason to be sceptical about
requiring "user agents" to expose any particular UI. It over-simplifies the
conformance class.)

> At the risk of being overly pedantic, <aside> is defined as: "... content that
>is tangentially related to the content that forms the main textual flow of a
> document." http://dev.w3.org/html5/markup/aside.html#aside

Is there such a category as "overly pedantic" among us markup geeks? ;)

> However, a sophisticated image in a document will likely rarely be tangential
> - in fact more often than not it is likely the primary focus/intent of the
> containing document, so a textual explanation of the visual asset is not
> tangential at all.

Sometimes, a document will use a term that is defined or further explained in a
self-contained capsule somewhere else on the page. This is a reasonably common
style in print newspapers/magazines and I guess allows readers who already know
the term to easily skip the explanation.

The premise of using an /optional/ long description is that the full-blown text
equivalent is tangential, and therefore needs to be hidden away. Sometimes
users access this tangential content to explain the image. "aria-describedby"
provides a programmatic link between the image and its explanatory capsule, and
allows user agents to expose that capsule by request, configuration, or design
according to their users' needs.

> Another issue is that 'aria-describedby' lacks the ability for the
> screen-reader user to choose to access the text or not

What in the ARIA specification forbids giving the user this choice?

I don't see any such restriction at:

http://www.w3.org/WAI/PF/aria/states_and_properties#aria-describedby

Indeed, the specification stresses the optionality of the description:
"additional detail that some users might need".

And if there is a such a restriction, why have PFWG imposed this limitation?

Or if this is only how user agents have actually implemented
"aria-describedby", why have they implemented it that way rather than in the
way you suggest?

This sounds like a case where, before rushing to introduce a differently
designed long description feature in HTML5, we should fix ARIA, provide better
guidance to ARIA implementors, and fully understand why implementors are
making the decisions they are on behalf of their users.

> Finally, this does not address the need to not have the text visible to end
> users at all times: often the critical text description of the image is only
> required by a significantly smaller percentage of the total users, and for
> 'artistic' considerations the text on the same page as the image is counter to
> the artistic requirements of the page

This fits reasonably well with my capsule analogy.

> I have previously asked how this would work in image gallery pages that use
> tools such as JavaScript Lightbox? If we have 15 thumbnails on one page, will
> we have 15 asides as well?

Whenever an image is the subject in its own right, rather than (say) a link to
the same image in a lightbox view, its long description should be present as
well. Whether that implies 15 "aside" elements in the document at once depends
on whether all full-scale images are simultaneously present in the document or
not, which likely differs between lightbox implementations.

> what impact does this have on those with cognitive challenges?

Well, I imagine some people will want images presented with their long
descriptions, some people will want to optionally access the long descriptions,
some people will want only the long descriptions, etc. The great thing about
not mandating a UI is people are free to develop user agents (or user agent
configurations) that suit any of these preferences.

> And how will this "look"?

If their user agents do their jobs, how users want.

> > If we do mint a new feature and it differs significantly from
> > "aria-describedby" (for example, by taking a URI as a value rather than an
> > IDREF), then it should be called something *other* than "describedby" to reduce
> > confusion on the part of authors (e.g. a "longdescriptionhref" attribute or a
> > "longdescription" element).
> 
> I agree. The choice of term on this bug's title is slightly confusing, as we
> already have aria-describedby which *does not* achieve all of the user
> requirements.

Well, both the title and description explicitly request minting a "describedby"
attribute.

I assume if Laura wants something else, she'll clarify. 

> But as I have stated often, the name is less important than the
> functionality. (It's also interesting that you are here suggesting the
> creation of an element rather than an attribute, or was this just a slip of
> the pen?)

No, that was deliberate.

If I was designing long text equivalents for "img" from scratch and didn't need
to think about "longdesc" or ARIA, I'd be tempted to create some sort of
element bound to "img" by "for" and "id". Elements have a good backwards
compatibility story (i.e. you can at least see the text inside!), accept other
elements as content (e.g. to indicate changes of language or link elsewhere),
keep alternate text close to the image for hand authors, and can trivially be
restyled to bypass the diktats of art directors. "for" and "id" reuses an
existing association mechanism. Authors commonly fail to use it successfully,
but it's better than inventing yet another association mechanism for them to
break.

> > But if we mint a new feature because "aria-describedby" is *not* sufficient
> > for image long descriptions - for example, if being able to reference
> > external documents as long descriptions is critical - then we should also
> > be trying to fix ARIA (the generic level).
>
> This has already been noted as a potential action item for WAI-ARIA 2
> (searching for reference).

That's like waiting for HTML6! ;) Why the delay?

> > Looking at the above, the key reason proposed for minting a new
> > attribute differing from "aria-describedby" is in order to designate external
> > documents as long descriptions. Why do users need this? Why hasn't PFWG expressed
> > this requirement in ARIA?
>
> When WAI-ARIA was being written, we had @longdesc that natively achieved this
> function.

[snip]

> However, since HTML5 has no qualms of establishing 'willful violations' of
> current existing specs outside of HTML5, it breaks the chain of functionality
> that had been previously established.

The chain should never have existed.

ARIA *must* not rely on any HTML features given it has an explicit and
long-standing design goal of providing bolt-on accessibility across a range of
host languages. See for example this paragraph from the editor's draft:

"Some host languages exist to create semantics for features other than the user
interface. For example, SVG expresses the semantics behind production of
graphical objects, not of user interface components that those objects may
represent; XForms provides semantics for form controls and does not provide
wider user interface features. Host languages such as these might, by design,
not provide native semantics that map to WAI-ARIA features. In these cases,
WAI-ARIA could be adopted as a long-term approach to add semantic information
to user interface components, without the obsolescence that might be expected
when used in a more generic language."

http://www.w3.org/WAI/PF/aria/introduction#co-evolution

> Whether or not we can address this in a future version of ARIA is not under
> question, but if or until such time as we do, the willful violation removes
> an important accessibility function, and does not offer any credible
> alternative to date. Thus we must re-instate @longdesc (for backwards
> compatibility) or mint a new attribute that delivers on the functionality
> required.

You speak of "a future version of ARIA", but aren't both HTML5 and ARIA Working
Drafts? If this omission is valid and is serious enough to delay taking HTML5
to Last Call, then isn't it enough to delay taking ARIA back to Last Call also?

(In reply to comment #17)

On 29 August 2010, at 19:08, John Foliot wrote:
> > > We don't want a link visually available, as I discussed in my earlier
> > > scenario.
> >
> > You might not, but other developers might.
>
> So then options and choices are a good thing, right?

Not all choice comes for free, however.

> Just as overtly mandating browsers on UI requirements (and the relationship
> of diminishing returns that invokes) so too with content authors! There are
> many voices at the table of any large project, and why should the art
> director take the back-seat to the accessibility guy? What happens when the
> art-director is able to over-ride the accessibility guy because of 'marketing
> considerations'?

Same thing as what happens when the browser art-director is able to override
the accessibility guy because of "marketing considerations" - some users lose
out as accessibility is shunted to some hard-to-find extension or bolt-on
attribute.

> > What's the import of your question? A lot of AT still does nothing at all with
> > "longdesc", and obviously no AT does anything with the proposed "describedby"
> > attribute. 
> 
> AT can include technology such as speech-recognition that allow mobility
> impaired users (quadriplegics for example) a means to interact with their
> computer, or head-mice and other alternative switches, or screen magnifiers,
> one-hand keyboards, etc.

I know. But asking how these hardware devices work with "aside" now as opposed
to asking about how software like Firefox or JAWS works with it doesn't make
sense to me, so I assumed Shelley must mean software AT.

> So suggesting that poor AT support is somehow the culprit here is both false
> and misleading

I didn't mean to suggest that.

> poor browser support to date has been the #1 reason for lack of active pick-up
> of @longdesc, not that it is some-how a flawed attribute.

I'd say poor user agent support and expert discouragement by WCAG and its
popularisers provided negative feedback to a lack of supply (authors writing
long descriptions) or active demand (users requesting long descriptions). I
include the whole collaborating ecosystem of browsers, addons, AT software, and
search engines under the rubric of "user agent". How far arguable flaws in the
design, like encouraging alternate text to be placed in an external document
(not merely hidden) subject to rot or like having a name that did not include
"href", contributed to the problem is hard to judge.

> As far as screen-reader support goes for @longdesc, it is actually very good,
> with market leaders JAWS, WindowEyes and Hal/Supernova providing support today.

It's better than it was, but I don't think this list contradicts my claim that
"A lot of AT still does nothing at all with 'longdesc'". Note the absences of
VoiceOver and Orca, for example, which mean there are whole platforms where
this doesn't work.

> As far as the semantic value of <aside> (or any of the other newly minted
> landmark elements in HTML5) AFAIK no technology today really does anything
> with it

Same would apply to a newly minted "describedby" attribute. Indeed, given poor
discoverability of both "longdesc" and "aria-describedby", anyone who wants to
*guarantee* availability of long descriptions to all users had better stick to
links and same-page content, even if they also use these other features.

> One screen-reader's choice in approaching missing functionality is hardly an
> indication of trends. Using this alone as justification we might as well remove
> all the Web Forms 2.0 stuff from HTML5, as only Opera today supports it. This
> is a poor argument IMHO.

I'm not using the deprioritization of "longdesc" as a justification for
removing anything; I'm explaining why it's unrealistic to expect AT software to
do much useful with "aside" yet.

(In reply to comment #19)
> If I were going to provide a separate page with a long, complex description
> of an image that's specifically for the visually impaired, I would like to be
> able to do so in a way that only the blind see it (unless people
> know it's purpose and it is exposed as a specific type of link).

[snip]

> What is there about the term, long description, that is specific to visual
> impairment?

Text equivalents aren't only for the visually impaired. If a user does not
understand your image, the text equivalent is useful to them, hence the need
for universal access. 

See also:

"Provide text alternatives for any non-text content so that it can be changed
into other forms people need, such as large print, braille, speech, /symbols or
simpler language/." (my emphasis)

http://www.w3.org/TR/WCAG20/#text-equiv

"Text alternatives may help some people who have difficulty understanding the
meaning of photographs, drawings, and other images (e.g., line drawings,
graphic designs, paintings, three-dimensional representations), graphs, charts,
animations, etc.  Additionally, text alternatives support the ability to
search for non-text content and to repurpose content in a variety of ways."

http://www.w3.org/TR/UNDERSTANDING-WCAG20/text-equiv-all.html

As such it would be inappropriate to designate long descriptions as "specific
to visual impairment".

> Hard to say. It could be ugly. Could get tricky. Would have to require a great
> deal of effort across groups.

Yeah, that's one of the catchs with distributed extensibility.

> The thing is, we need to define what different categories of user agents do
> with aside, so we also need to do the same with whatever ends up as Laura's
> described-by. 
> 
> If there isn't anything mandating behavior, we really couldn't blame
> described-by if it's use is sporadic, and maybe even incorrectly applied. 

Defining the semantics and providing example UI should be sufficient.

> But we do specify behavior and appearance in HTML5. I'm not talking about RDFa,
> I'm talking about HTML5.

We don't generally mandate appearance.

> If we want something in HTML5 to meet Laura's requirements and needs, then
> part of this requires some control over how UAs handle the item.

No, it requires someone to implement a UA that does what Laura wants with the
available semantics. For example, Patrick Lauke could update his "longdesc" Firefox
add-on to handle "aria-describedby".

Since what Laura wants may not match what other users want, or be applicable to
all possible user agents on all possible platforms, it should not be mandated
in a specification for a semantic document/application description language.

> > > On the contrary, the HTML5 document has mandated behavior and appearance
> > > for many elements and attributes. For reference see progress, noscript,
> > > and others.
> > 
> > Sorry - where are the MUST-level "appearance" requirements for "progress"
> > and "noscript"? I see only SHOULD- or MAY-level suggestions.
> 
> So how do we define EXPECTED?
 
[snip]

> I see EXPECTED as equivalent to MUST. Perhaps the use of the word EXPECTED is
> incorrect, and too vague for use in a spec, but that's what we have. 

Did you miss the definition provided by the spec itself?

"User agents are not required to present HTML documents in any particular way.
However, this section provides a set of suggestions for rendering HTML
documents that, if followed, are likely to lead to a user experience that
closely resembles the experience intended by the documents' authors. So as to
avoid confusion regarding the normativity of this section, RFC2119 terms have
not been used. Instead, the term "expected" is used to indicate behavior that
will lead to this experience."

http://dev.w3.org/html5/spec/rendering.html#rendering

It's clear to me this means that user agents can freely ignore the entire section.

> If it would be better, we can re-coach the requirements for behavior associated
> with this item using EXPECTED. 

I would prefer it, since then the UI "requirements" would be suggestions not
mandates and user agents like Firefox, NVDA, and Google Search would be free
to disregard them in service of their users.

> And yet the NOSCRIPT section was updated, just because user agents did not
> implement the same behaviors for this element. 

I don't know what differing behaviors or what update you're referring to, or
how this is relevant.

> I think we're also conflating all aspects of behavior, expectations, and
> presentation into the term UI.

Maybe. I'm basically saying HTML5 should tell user agents how to construct a
DOM and the semantics of that DOM, not mandate what interface to expose on top
of that DOM to end-users. I think it's good for HTML5 to make interface
suggestions, though suggestions for semantics defined in other specs like ARIA
and Dublin Core are likely misplaced.

(In reply to comment #23)
> (In reply to comment #19)
> > If I were going to provide a separate page with a long, complex description
> > of an image that's specifically for the visually impaired, I would like to be
> > able to do so in a way that only the blind see it (unless people
> > know it's purpose and it is exposed as a specific type of link).
> 
> [snip]
> 
> > What is there about the term, long description, that is specific to visual
> > impairment?

I meant, what is there about "long description" that implies this item is going to be an exact text equivalent of the image, and not a longer caption?

There's nothing to the term that provides an unequivocal understanding of exactly what the person will find if they click the link. 

If an attribute is provided, and user agents implement something for people to access it, the definition of the attribute would provide this meaning.

For all of the talk about the importance of "semantics" in HTML5, and having semantic equivalents for this and that, why on earth would we then remove an attribute that does have a specific "semantic" meaning? 

It's a heck of a lot more useful than something like hidden. 

> 
> Text equivalents aren't only for the visually impaired. If a user does not
> understand your image, the text equivalent is useful to them, hence the need
> for universal access. 
> 
> See also:
> 
> "Provide text alternatives for any non-text content so that it can be changed
> into other forms people need, such as large print, braille, speech, /symbols or
> simpler language/." (my emphasis)
> 
> http://www.w3.org/TR/WCAG20/#text-equiv
> 
> "Text alternatives may help some people who have difficulty understanding the
> meaning of photographs, drawings, and other images (e.g., line drawings,
> graphic designs, paintings, three-dimensional representations), graphs, charts,
> animations, etc.  Additionally, text alternatives support the ability to
> search for non-text content and to repurpose content in a variety of ways."
> 
> http://www.w3.org/TR/UNDERSTANDING-WCAG20/text-equiv-all.html
> 
> As such it would be inappropriate to designate long descriptions as "specific
> to visual impairment".
> 

And I believe that's why Laura asked that the contents pointed to in described-by should be accessible to all people.

> > Hard to say. It could be ugly. Could get tricky. Would have to require a great
> > deal of effort across groups.
> 
> Yeah, that's one of the catchs with distributed extensibility.
>

This has nothing to do with distributed extensibility. That's one of the catches with semantics. 
 
 
> > > > On the contrary, the HTML5 document has mandated behavior and appearance
> > > > for many elements and attributes. For reference see progress, noscript,
> > > > and others.
> > > 
> > > Sorry - where are the MUST-level "appearance" requirements for "progress"
> > > and "noscript"? I see only SHOULD- or MAY-level suggestions.
> > 
> > So how do we define EXPECTED?
> 
> [snip]
> 
> > I see EXPECTED as equivalent to MUST. Perhaps the use of the word EXPECTED is
> > incorrect, and too vague for use in a spec, but that's what we have. 
> 
> Did you miss the definition provided by the spec itself?
> 
> "User agents are not required to present HTML documents in any particular way.
> However, this section provides a set of suggestions for rendering HTML
> documents that, if followed, are likely to lead to a user experience that
> closely resembles the experience intended by the documents' authors. So as to
> avoid confusion regarding the normativity of this section, RFC2119 terms have
> not been used. Instead, the term "expected" is used to indicate behavior that
> will lead to this experience."
> 
> http://dev.w3.org/html5/spec/rendering.html#rendering
> 
> It's clear to me this means that user agents can freely ignore the entire
> section.
>

Expected means "likely to happen". I expect the UAs to implement the renderings in the section.

So, the the same type of expectation can be provided for described-by.  


> > If it would be better, we can re-coach the requirements for behavior associated
> > with this item using EXPECTED. 
> 
> I would prefer it, since then the UI "requirements" would be suggestions not
> mandates and user agents like Firefox, NVDA, and Google Search would be free
> to disregard them in service of their users.
>
> > And yet the NOSCRIPT section was updated, just because user agents did not
> > implement the same behaviors for this element. 
> 
> I don't know what differing behaviors or what update you're referring to, or
> how this is relevant.
> 
> > I think we're also conflating all aspects of behavior, expectations, and
> > presentation into the term UI.
> 
> Maybe. I'm basically saying HTML5 should tell user agents how to construct a
> DOM and the semantics of that DOM, not mandate what interface to expose on top
> of that DOM to end-users. I think it's good for HTML5 to make interface
> suggestions, though suggestions for semantics defined in other specs like ARIA
> and Dublin Core are likely misplaced.


People are going to see EXPECT, and their expectations are going to be set. I would expect that most UAs would understand this, and act accordingly. UAs should have enough sense to know that when customer expectations are set, they better meet them.

So, the same expectations for described-by should be sufficient.

Thanks to everyone for your input.

A couple of comments:

* I am open to changing the attribute's name from describedby to something else. Perhaps it could be called "closeddescription" or "cdescription" or "closeddesc" or "cdesc"(invisible by default like a television closed-caption but can be opened via the user agent).

* My Research so far on Longdesc Examples In the Wild:
http://www.d.umn.edu/~lcarlson/research/ld.html

(In reply to comment #24)
> what is there about "long description" that implies this item is going
> to be an exact text equivalent of the image, and not a longer caption?

What implies to Opera users that the context menu item called "Long Description" points to an equivalent?

If you're just saying we should come up with a better term to use as UI text, feel free to try.

As to what tells the user agent that it's a long description, that's the purpose of an RDFa annotation.

> For all of the talk about the importance of "semantics" in HTML5, and having
> semantic equivalents for this and that, why on earth would we then remove an
> attribute that does have a specific "semantic" meaning? 

This bug is not about the removal of an attribute, but the addition of one.

> Expected means "likely to happen". I expect the UAs to implement the renderings
> in the section.

[snip]

> People are going to see EXPECT, and their expectations are going to be set. I
> would expect that most UAs would understand this, and act accordingly. UAs
> should have enough sense to know that when customer expectations are set, they
> better meet them.

If you say so, but people's "expectations" do not change what is required for conformance.

(In reply to comment #25)
> I am open to changing the attribute's name from describedby to something
> else. Perhaps it could be called "closeddescription" or "cdescription" or
> "closeddesc" or "cdesc"(invisible by default like a television closed-caption
> but can be opened via the user agent).

A couple points:

   * Many authors may not be sure what "closed captions" are, so this analogy may be lost on them. I recommend using more straightforward language.

   * One of the contributing factors to the "longdesc" lottery is authors inserting text rather than a URI as a value, perhaps under the influence of "alt". Including "href" in the attribute name might help reduce the frequency of such errors.

(In reply to comment #25)

> * I am open to changing the attribute's name

 It is hardly useful to document @longdesc support if you suggest a new name -- so I assume that in reality, you are open to the name @longdesc. (That's at least the only thing I'm open to.)

> * My Research so far on Longdesc Examples In the Wild:
> http://www.d.umn.edu/~lcarlson/research/ld.html

(a) the list of  #redundant examples: How useful is it, for a user of JAWS (which supports @longdesc) if @longdesc has to be duplicated in a redundant anchor element? Please keep in mind that the only announcement JAWS seems to make is "Press enter for long description". Thus, the user might not realize that the @longdesc as well as the redundant anchor link, leads to the same place. If the longdesc link really has to be invisible and available only to screenreader users, then using an invisible image map that is accessible to all of them, without duplication, could possibly be better than having to use @longdesc *and* and additional link as well.

(b)  the list of  #redundant examples is too short:  All these examples redundant anchor links in addition to @longdesc:

  1) all the CSSsquirrel's comics examples
  2) http://www.fdic.gov/regulations/examinations/supervisory/insights/siwin09/Interest_Rate_Risk.html 
  3) http://doe.k12.hi.us/specialeducation/SpEdHandbook2006/06appendix_a.htm#SeizureAlgorithm   (The first @longdesc URL is invalid, while the image is wrapped in an anchor element with a working URL.)
  4) http://www.hse.gov.uk/aboutus/strategiesandplans/hscplans/strategicplan0104/plan0104-09.htm#httpwwwhsegovukaboutusstrategiesandplanshscplansstrategicplan0104plan010409longdeschtmLongdescriptionavailable
  4) http://ntl.bts.gov/lib/jpodocs/repts_pr/13669/section03.htm

(c) CSSsquirrel's use of @longdesc raises many questions:

     *  He uses it to link to a transcript. His @alt text, however, is just a single word .... Has the @longdesc become an escape for a good @alt text? Apart from Episode #72, could he just have used @alt for his transcripts? Or, if he used <object> instead of <img>, could it have been inside the fallback? Or, perhaps the @alt should have been empty – with a visible transcript link for all? Please note that @longdesc, according to HTML4, always works in tandem with an @alt text. This is the DTD definition: -- link to long description (complements alt) --.  Thus, if there is no useful @alt, then it does in principle not seem justified to add a @longdesc.

     * According to you - http://lists.w3.org/Archives/Public/public-html-a11y/2010Aug/0190 - a table can be a bad WCAG longdesc description for a diagram. And a transcript is possibly a bad WCAG longdesc description of a cartoon, as well. This is at least true for CSSquirrel's Comic #72 - a non-sighted user will not understand what the humor in the image of episode #72 is about, as there is not description of the image! Ironically, it is the _transcript_ that is lacking, since that image is an image of some words  - obviously those words should have been provided as @alt text.

     * But if, for Comic #72, CSSquirrel had chosen to add a "real" WCAG longdesc description, then he could EITHER have created a new, separate document with that description. OR he could add it to the existing transcript. In the latter case, should he then just use @longdesc to pont to the WCAG londesc description part of the document? And another link to point to the transcript part of the documetn? My answer is: why not. It is definitely a possibility. THus, two links: one linke to a transcript. And another one to the longdesc document. Voila: we get to use a link and a @longdesc simultaneously. Excellent, in my view.

However, often an author will not do that. Often an author will only provide a transcript in some form - possibly with some vague image description. In that case, what is the best way to link to the transcript? If we forget the problem of whether the link should be visible to sighted or not, would it best for the non-sighted to know that it is a transcript? Or should he be told that it is a long description? In other words: rel="longdesc" or rel="alternate" (or, if someone defined its meaning, rel="transcript")? To put it another way: very often something like rel="transcript" would be useful. And not only to the sighted. (For my own part, I tend to read his transcripts more thorougly  than his cartoons.) ;-)

Statement: the choice between rel="longdesc" and rel="alternate" is more easily made if one can use the anchor/area element for both link types. This is not an argument _against_ @longdesc. I just think that if @rel="longdesc" exists, then authors' thinking about these things will improve. I think especially the case that @longdesc links are typically duplicated, is an argument in favor of adding @rel="longdesc" to the HTML language, so that authors can get the same feature by use of a normal link.

(In reply to comment #24)
>> what is there about "long description" that implies this item is going
>> to be an exact text equivalent of the image, and not a longer caption?
>
>What implies to Opera users that the context menu item called "Long
>Description" points to an equivalent?

According to Laura, 

http://lists.w3.org/Archives/Public/public-html-a11y/2010Aug/0190

then @longdesc is not link to an "exact equivalent". And I don't believe that that is what WCAG is saying either. It actually clearl up a lot to keep that in mind ... If the purpose is to link to represenation in some other format - such as table instead of diagram, then a rel="alternate" link type might be better.

(In reply to comment #21)

>If I was designing long text equivalents for "img" from scratch and didn't need
>to think about "longdesc" or ARIA, I'd be tempted to create some sort of
>element bound to "img" by "for" and "id".

Thus it would be interesting to have your comment to rel="longdesc" in combination with image maps: http://malform.no/testing/longdesc/

(In reply to comment #28)

>Statement: the choice between rel="longdesc" and rel="alternate" is more easily
>made if one can use the anchor/area element for both link types. This is not an
>argument _against_ @longdesc. I just think that if @rel="longdesc" exists, then
>authors' thinking about these things will improve. I think especially the case
>that @longdesc links are typically duplicated, is an argument in favor of
>adding @rel="longdesc" to the HTML language, so that authors can get the same
>feature by use of a normal link.

rel="longdesc" couls possibly be useful when it comes to the use duplicate, redundant anchor links in combination with @longdesc. For example, if we have this:

<a rel="longdesc" href="link-A"><img longdesc="link-A" src="*" alt="*"/></a>

the perhaps JAWS, which do support @longdesc,  would be able to avoid presenting the same link twice. it just has to compare the rel="longdesc" links against the @longdesc links and come up with a way to eliminate duplicate link presentation.

(In reply to comment #26)
> (In reply to comment #24)
> > what is there about "long description" that implies this item is going
> > to be an exact text equivalent of the image, and not a longer caption?
> 
> What implies to Opera users that the context menu item called "Long
> Description" points to an equivalent?

Actually, it says "Image Description". Opera documentation tells us why this menu item exists, and what to expect from the browser when clicking on this item.

> 
> If you're just saying we should come up with a better term to use as UI text,
> feel free to try.
> 
> As to what tells the user agent that it's a long description, that's the
> purpose of an RDFa annotation.
>

But without there being a agreed to approach to the use of RDFa, it's meaningless. All it can do is add an additional piece of data that can be combined with other data. That can be useful, but isn't anything specific to accessibility. 

It is those aforementioned expectations of behavior that really matter.

 
> > For all of the talk about the importance of "semantics" in HTML5, and having
> > semantic equivalents for this and that, why on earth would we then remove an
> > attribute that does have a specific "semantic" meaning? 
> 
> This bug is not about the removal of an attribute, but the addition of one.
> 

Whether the removal of one, or the addition of the other, it all boils down to what is the criteria by which these decisions are based.

Isn't semantics the reason for 30+ new elements and attributes? Wouldn't something like described-by be just as meaningful as, say, &hidden? What are the factors being used to decide what is semantically meaningful enough in order to be added to HTML5? Or, as the case may be, left in HTML5? 

What is the objective criteria used to judge when an element or attribute is semantically meaningful enough to be added to, or kept in, HTML5?

There has to be fundamental design principles governing these decisions; ones concrete enough that each decision can be tested against the principles for determining inclusion or not.

> > Expected means "likely to happen". I expect the UAs to implement the renderings
> > in the section.
> 
> [snip]
> 
> > People are going to see EXPECT, and their expectations are going to be set. I
> > would expect that most UAs would understand this, and act accordingly. UAs
> > should have enough sense to know that when customer expectations are set, they
> > better meet them.
> 
> If you say so, but people's "expectations" do not change what is required for
> conformance.

Conformance that goes against expectations leads to failure.

JAWS, the example-to-follow when it comes to @longdesc, announces the presence of a longdesc URL *after* it has read the @alt text, with these words:

  ]] Press enter for long description [[

Is there any reason why

  <a href="URL" rel="longdesc"><img src="*" alt="*"/></a>

can't be presented the same way? 

(Perhaps with the addition of the word 'link' at the end of the sentence?)

>   <a href="URL" rel="longdesc"><img src="*" alt="*"/></a>

What does one do if the image itself is already wrapped in an anchor?

(In reply to comment #11)

I asked:
> > My question is, in what specific ways, if any, would such a
> > describedby="" attribute differ from longdesc=""?

John replied:
> 1) It would have a 'universal' control that all users, not just blind users,
> could use to easily access extended descriptions. We could *mandate* that all
> browsers [... various UI proposals ...]

Whether or not we should mandate any browser UI aside, this doesn't appear to be a difference between the proposed attribute describedby="" and the previous attribute longdesc="". (Same response to your #2.)

> 3) Currently aria-describedby can only be linked to IDREFs, whereas the new
> attribute must be able to be linked to both IDREFS and URI's

That's a difference between describedby="" and aria-describedby="", not a difference between describedby="" and longdesc="". AFAICT, this is evidence in favor of the thesis that describedby="" is just longdesc="" with a new name.

> And now, I will ask you a specific question: do you disagree with any of the
> articulated user requirements? If yes, which user-requirement do you disagree
> with, and why?

1. Modulo quibbling about the meaning of "programmatic," this seems fine to me, though I think we should encourage such descriptions to be internal to the document when possible.

2. I don't think we should mandate UA interface features in this way.

3. Not sure what this actually requires.

4. I don't think we should mandate AT interface features in this way.

5 has two parts. I don't think I understand the first sentence. I don't have an opinion on the second one.

6. Not crazy about it, but I could live with it. (Generally, like I said re: req 1 above, I think in-page descriptions are to be preferred over external descriptions.)

(In reply to comment #10)

I asked:
> > I'm asking for a description of *how* describedby="" would work, hopefully
> > one sufficiently detailed so we can evaluate the extent to which it differs
> > from longdesc="".

Shelley replied:
> From my reading of what Laura provided, I would imagine describedby provides a
> way[...] 

What is that way? Is the intent for authors to write markup like <img src="url-to-source" alt="replacement text" describedby="url-to-a-description">? If so, how is this different from longdesc=""? It looks like all we've done here is change the name of the attribute. I'm trying to presume that Laura doesn't intend describedby="" to work in this manner, but in some other way instead.

> Is that good?

Your answer focused on various browser and/or AT UI features that sound neat, but aren't really what I was asking.

(In reply to comment #34)
> >   <a href="URL" rel="longdesc"><img src="*" alt="*"/></a>
> 
> What does one do if the image itself is already wrapped in an anchor?

(1) The example above represent millions of images. Is it smart to let a substantially less common usecase stand in the way of the most common usecase?

(2) http://malform.no/testing/longdesc/ARIA+anchor@rel=longdesc.html

(2a) Microformat with @rel="longesc" and <q cite="">

   <a href="long_description.html" rel="longdesc" title="Link to detail description of The scream" >
      <q cite="http://en.wikipedia.org/wiki/File:The_Scream.jpg">
              <img src="file" alt="Munch’s The scream has some characteristic colors and lines" />
      </q>
    </a>

(2b)  Microformat with @rel="longesc" and image maps
       <img src="*" alt="Lorem ipsum" 
                  usemap="#map" width="100" height="100" />
      <map id="map" name="map">
          <area href="bar" alt="Link text" shape="rect" coords="0,0,100,100" />
          <a href="long-desc.html" rel="longdesc">Optional link text</a>          
      </map>

And so on and so forth.

(In reply to comment #34)
> >   <a href="URL" rel="longdesc"><img src="*" alt="*"/></a>
> 
> What does one do if the image itself is already wrapped in an anchor?

I want to point out that for the code example above, the only link text is the @alt text. Thus the alt text has to serve a double cause: as link text and as @alt text. By the addition of rel="longdesc", the AT has the option of stating "long description" as the text of the - in this case - longdesc link.

It is logical to solve the simple and most widespread problems first ...

(In reply to comment #37)
> (1) The example above represent millions of images. Is it smart to let a
> substantially less common usecase stand in the way of the most common usecase?

When the less common use case represents a fundamental feature of hypertext? Yeah, kinda.

I think all of the proposals presented so far are complicating the creation of long descriptions to the point that just reverting to visible D-links will be the standard case. I doubt that any assistive technology will implement support for markup so complex that it's likely to be broken in many cases.

> I want to point out that for the code example above, the only link text
> is the @alt text. Thus the alt text has to serve a double cause: as link
> text and as @alt text.

That's the common case for alt text today. I don't know what problem this solves. If there's alternate content that's not expressed in @alt, I believe it should still be bound within the element, not in an <a> wrapper. Anchors are an already well-defined semantic, and I don't like the idea of telling authors that you can either link an image or provide a long description simply in the name of expediency.

(In reply to comment #30)
> Thus it would be interesting to have your comment to rel="longdesc" in
> combination with image maps: http://malform.no/testing/longdesc/

Two thoughts:

   * Testing in Chrome, opening the long description involved moving focus to a imperceptible link. I think that contravenes WCAG2's Visible Focus requirement.
   * Normally, "rel" specifies a relationship between the destination and the current document, not a relationship between the destination and a component of the current document. So I think you'd need to use some other attribute(s), like "resource" from RDFa (something like I suggested above) or "itemprop" from Microdata.

(In reply to comment #34)
> >   <a href="URL" rel="longdesc"><img src="*" alt="*"/></a>
> 
> What does one do if the image itself is already wrapped in an anchor?

The underlying premise of that question is that the justification of @longdesc has to do with _technology_. That @longdesc provides a workaround for technical challenge.

But, no. Reading what Laura said [1], one has to come to the conclusion that it is about semantics - @longdesc is supposed to link to a description of some particular quality.
[1] http://lists.w3.org/Archives/Public/public-html-a11y/2010Aug/0190

However, in practise, @longdesc does _not_ provide a workaround: when taking in the corrections that I pointed out in Comment #28, then most of the @longdesc examples in the wild that Laura has documented, duplicate the @longdesc URL in anordinary anchor link. A link without any link type information whatsoever.

Also, if we concentrate on @rel="longdesc" and use of image maps, then we can in fact smash the longdesc usecase together with the image map issue - which also needs to be solved better in HTML5.

(In reply to comment #39)
> (In reply to comment #37)
> > (1) The example above represent millions of images. Is it smart to let a
> > substantially less common usecase stand in the way of the most common usecase?
> 
> When the less common use case represents a fundamental feature of hypertext?
> Yeah, kinda.

Reading your comment at the bottom, I understand that you simply dismisses the entire usecase. (See bottom.)

As for "represents a fundamental feature of hypertext", then what do you mean? Does @longdesc (and @cite also, then, I assume) represent a fundamental hypertext feature? They are links, so in that way yes. Not sure if I catched

Just for the record: I am in favour of @longdesc. I want it. But my mission here is to gather support for @rel="longdesc". Users deserve something that work. I understand that you see no value in @rel="longdesc" - could sound as you only see problems with it, even.

> I think all of the proposals presented so far are complicating the creation of
> long descriptions

I suppose @longdesc is supposed to provide something for the user? At least, that is why I am enganging in this debate, coming up with alternatives - as well as with defence!  Of course, @longdesc is much simpler to author. But "simple to author" is not as important as "actually works".

> to the point that just reverting to visible D-links will be
> the standard case. I doubt that any assistive technology will implement support
> for markup so complex that it's likely to be broken in many cases.

So, I suppose you are against image map solution together with <canvas> also then? It is too complex? The coding problems that can bee seen from my test case (http://malform.no/testing/longdesc/ARIA+anchor@rel=longdesc.html) has to do with lack of unified image map support. It is also related to ARIA - perhaps HTML5's native sematics will solve some of those problems. Also, the complicated code is due to the fact that I attempted to make it compatible with user agents and AT which do not support @longdesc (http://malform.no/testing/longdesc/index.html) - I don't know if you took that into account, before letting us here you negative view?

When you dismiss <a href="*"><q cite="cite"><img src="*" alt="*"></q></a> as a solution to some use cases, then I feel that you dismisses your own point, because @cite and @longdesc are the same kind of features. (Again, I support both @longdesc and @cite - see Comment #15.)
 
> > I want to point out that for the code example above, the only link text
> > is the @alt text. Thus the alt text has to serve a double cause: as link
> > text and as @alt text.
> 
> That's the common case for alt text today. 

Can you show me concrete examples which shows that the @alt text is authored in such a way that it can function well both as link text and as "textual substitute" for the image?

>I don't know what problem this solves.

It establishes a microformat, which solves the exact same use case as @longdesc. It is possible to give concrete advice to the author that they, when they use this microformat, should consentrate on writing a good "textual substitute" for the image rather than focusing on the fact that the @alt text also serves as link text. The link text will instead by provided by the user agent - the same way that JAWS presents @longdesc today. It is one-to-one the same as @longdesc, except that it works for more users. If, in reality, authors will not use this method, because of desing prettyness considerations ... OK. But I'm pretty sure that some authors *will* use it.

> If there's alternate content that's not expressed in @alt, I believe it
> should still be bound within the element, not in an <a> wrapper. 

Perhaps this was not so easy to understand, but I meant exactly this microformat:

<a href="link" rel="longdesc"><!-- no text here! --><img src="s" alt="Lorem"><!--no text here! --></a>

Thus, every text must be inside the @alt attribute, in this microformat - no text is permited outside the <img> element. Every text between the <img> and the <a> wrapper, is forbidden.

> Anchors are an
> already well-defined semantic, and I don't like the idea of telling authors
> that you can either link an image or provide a long description simply in the
> name of expediency.

I don't understand what, in this context, you mean by "link an image" (??) and "provide a long description" (do you mean "provide longdesc linnk"?).  But in a preceding comment, I made it very clear that, to provide a @longdesc URL does not free you from writing a proper @alt text. Also see this comment, to CSSquirren's Comic #72, which fails that test, by providing virtually an empty @alt together with a @longdesc: http://twitter.com/komputist#status_star_22556395542
The same goes if you use rel="Longdesc" instead of @longdesc: you must have proper @alt. I don't know if that cleared up anything.

Regarding what to tell authors: it *impossible* today to tell author to use @longdesc, unless you know that their audience use some very specific user agents. In addition you have learn them some kind of workaround - duplication of @longdesc link in a anchor element, something like that.

(In reply to comment #39)
> 
> That's the common case for alt text today. I don't know what problem this
> solves. If there's alternate content that's not expressed in @alt, I believe it
> should still be bound within the element, not in an <a> wrapper. Anchors are an
> already well-defined semantic, and I don't like the idea of telling authors
> that you can either link an image or provide a long description simply in the
> name of expediency.

I have to agree with Matt here. The purpose of this bug is to define a
mechanism (an attribute) that allows us to link an image (any image) to a
longer description, while at the same time not crippling it in another way. 

Another very common use-case is a thumb-nail gallery, where activating the link
presents the sighted user with a larger version of the image. I would argue
that the thumb-nail images deserve the long-description, as for non-sighted
users they care less for the size of the image, than the content of the image.
Insisting that the only time the longer description is provided is on the
larger image is not 'right', and in the case of 'lightbox' javascripts in use
today, providing the longer description "in page" (when the image is not in a
page per-se, but in a layered' div) is contrary to the entire visual experience
being created, and graphic driven design considerations will oppose the text
and 'scrolling' that an in-page requirement imposes.

(In reply to comment #41)

> 
> But, no. Reading what Laura said [1], one has to come to the conclusion that it
> is about semantics - @longdesc is supposed to link to a description of some
> particular quality.

while semantics can play a role here, it is a *mechanism* to link longer
descriptions of images to those images that is being sought out. How do we
associate a longer description to an image that does not break other
functionality or 'aesthetic' considerations?

(In reply to comment #40)
> (In reply to comment #30)
> > Thus it would be interesting to have your comment to rel="longdesc" in
> > combination with image maps: http://malform.no/testing/longdesc/
> 
> Two thoughts:
> 
>    * Testing in Chrome, opening the long description involved moving focus to a
> imperceptible link. I think that contravenes WCAG2's Visible Focus requirement.

Q1: You tested with VoiceOver? Or was it without screenreader? Which of the 5 test pages was it? 
Q2: Please note that I have taken every step to hide the long description URLs from GUI browsers (media="screen") - only AT and textual browsers are meant to have access - I suppose this does not break WCAG.  Or,  is the correct way to read your comment to assume that you would have said the same thing as you said about (one of) those tests about @longdesc?

>    * Normally, "rel" specifies a relationship between the destination and the
> current document, not a relationship between the destination and a component of
> the current document. So I think you'd need to use some other attribute(s),
> like "resource" from RDFa (something like I suggested above) or "itemprop" from
> Microdata.

Do you have any backup info? I'll note that Julian Reschke of the link type registry did not express any such reservations when I aired this (2-3 weeks ago - public-html). Instead it sounded interesting to him, as I perceived it. Also, when I filed a bug, then Ian accepted the proposal. Perhaps you disagree with his resolution? [*] 

[*] http://www.w3.org/Bugs/Public/show_bug.cgi?id=10434

I note that what you say, though, seems to be reflected in HTML5:  

]] Links are a conceptual construct, created by a, area, and link elements, that represent a connection between two resources, one of which is the current Document. [[
]] In this section, the term referenced document refers to the resource identified by the element representing the link, and the term current document refers to the resource within which the element representing the link finds itself. [[

Whereas HTML4 says that 'source anchor' is not the document itself, but the anchor element.  From the definition of <a>:

]] href = uri [CT] This attribute specifies the location of a Web resource, thus defining a link between the current element (the source anchor) and the destination anchor defined by this attribute. [[

In HTML4, only the link element as draws a link between documents:  ]] The LINK element defines a relationship between the current document and another resource. [[

Likewise, the link registry [*] defines the 'alternate' link relation as follows:  ]] Designates a substitute for the link's context. [[  So what is the link's context? 'Context' is a least not wider than 'the current document'.  
[*] http://www.iana.org/assignments/link-relations/link-relations.txt

Looking at @longdesc, then it is a link, and its context is very clear: the IMG element. With help of ARIA, however, we can say <a role="img" href="*" > So, when I think about it ... One shoudl think that if you have <a role="img" href="*" aria-labelledby="img" ><img id="img" src="*" alt="Blah blah"></a> then the @link is related to the img element, and not to the entire document as such ...

Until I hear from Ian  and/or Julian that @rel="longdesc" with the semantics I have proposed (and which they both have heard) is a problem, then I choose to believe that it isn't. Clearly, the current version of HTML - HTML4 - seems to consider such relations as possible.

(In reply to comment #43)
> (In reply to comment #39)

> Another very common use-case is a thumb-nail gallery, where activating the link
> presents the sighted user with a larger version of the image. I would argue
> that the thumb-nail images deserve the long-description,
   [ snip ]
> (In reply to comment #41)
> > But, no. Reading what Laura said [1], one has to come to the conclusion that it
> > is about semantics - @longdesc is supposed to link to a description of some
> > particular quality.
> 
> while semantics can play a role here, it is a *mechanism* to link longer
> descriptions of images to those images that is being sought out. How do we
> associate a longer description to an image that does not break other
> functionality or 'aesthetic' considerations?

Core to what Laura said is tht the @longdesc URL points to a resource that is especially crafted for non-sighted. That's a quality thing. I also perceive in some arguments that there is a link between this quality and the technical solution: Since it is only of interest to non-sighted, it is not important that it is accessible to sighted. (And my tests with image maps did manage to create a solution which was accessible to screenreader users and textbrowser users.)

I assume that the "goal" of the usecase you described above, is that the <img> is wrapped inside an <a> element, but that it still works. That is possible to do, cross browser with the help image map:

See: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/605

Simplified code: 
  <a href=longdesc ><img src=* alt=* usemap="#map"/></a>
  <map id="map"><area shape="rect" href="full-size" coords="0,0,999,99" /></map>

This seemed to work in the big four: Firefox, Opera, Webkit, IE. HTML5, however, has ridiculous requirements: Since that IMG elemetn has a @usemap, then it is forbidden. I don't know why. I tested LiveDomViewer example in VoiceOver: In VoiceOver then I could only (?) activate the longdesc URL. Whereas without VoiceOVer, I could open the thumbnail. 

Perhaps you will file a bug againt HTML5 to make it legal? ...

(In reply to comment #45)

> Perhaps you will file a bug againt HTML5 to make it legal? ...

It is legal both HTML4 and XHTML1.

(In reply to comment #46)
> (In reply to comment #45)
> 
> > Perhaps you will file a bug againt HTML5 to make it legal? ...
> 
> It is legal both HTML4 and XHTML1.

Another solution is to use <object> elements - then the <map> element is permitted inside the <object> and thus "within" the image:

<object role="image" data="image" type="image/gif" usemap="#map" aria-labelledby="map" >
 <map id="map">
    Mum and dad visiting.
   <a href="longd-description">long descript</a>
  <area href="full-size" shape="rect" coords="0,0,100,00" alt="Full size link" />
</map>
 </object>

Of coures, then you will say "but object, it doesn't work with  ... " 

I'm not sure, btw, if the kind of description link you suggest here really is covered by the semantics of @longdesc.

I think, thus that to create a photo album which also works for blind, require much more than @longdesc. It requires that you think through the whole user experience of the album.

(In reply to comment #44)
> (In reply to comment #40)
> > (In reply to comment #30)
> > > Thus it would be interesting to have your comment to rel="longdesc" in
> > > combination with image maps: http://malform.no/testing/longdesc/
> > 
> > Two thoughts:
> > 
> >    * Testing in Chrome, opening the long description involved moving focus to a
> > imperceptible link. I think that contravenes WCAG2's Visible Focus requirement.
> 
> Q1: You tested with VoiceOver? Or was it without screenreader? Which of the 5
> test pages was it? 

Without VoiceOver. Tried all of them, I think.

> Q2: Please note that I have taken every step to hide the long description URLs
> from GUI browsers (media="screen") - only AT and textual browsers are meant to
> have access - I suppose this does not break WCAG.

It breaks WCAG2 if a control has focus but focus is invisible or it is not clear what the control will do when activated. See Success Criteria 1.1.1, 2.4.7, 2.4.4/9, and Principles 1 and 3. The fact that I can tab to the "longdesc" link/area and activate it means the focus and purpose should be clear.

Also note that text equivalents (of which "longdesc" is one) are potentially appropriate for /any/ user, not just users of AT or textual browsers. Which is why Laura, although she describes "describedby" as for visual impairments, stresses it needs to be available to all users. See also the quotations from WCAG2 and supporting documentation in comment #23.

>  Or,  is the correct way to
> read your comment to assume that you would have said the same thing as you said
> about (one of) those tests about @longdesc?

No, since "longdesc" does not create a stop in the tab order and therefore never receives focus.

> >    * Normally, "rel" specifies a relationship between the destination and the
> > current document, not a relationship between the destination and a component of
> > the current document. So I think you'd need to use some other attribute(s),
> > like "resource" from RDFa (something like I suggested above) or "itemprop" from
> > Microdata.
> 
> Do you have any backup info? I'll note that Julian Reschke of the link type
> registry did not express any such reservations when I aired this (2-3 weeks ago
> - public-html). Instead it sounded interesting to him, as I perceived it. Also,
> when I filed a bug, then Ian accepted the proposal. Perhaps you disagree with
> his resolution?

It's an entirely reasonable link relationship; I'm just talking about the "rel" attribute.

I was saying you'd need to modify the referent of "rel" using additional attributes from RDFa.

> Whereas HTML4 says

HTML4 says the same thing about "rel" on "a":

"This attribute describes the relationship from the current document to the anchor specified by the href attribute."

http://www.w3.org/TR/html401/struct/links.html#adef-rel

The anchor specified by the "href" attribute, in this case, would be the long description URL.

I guess one can work around this by arguing that "a rel='longdesc'" specifies one long description /belonging to/ the document, much as "a rel='cite'" specifies one citation belonging to the document, and then there's some magic processing to hook it up with a particular "img" element.

> Likewise, the link registry [*] defines the 'alternate' link relation as
> follows:  ]] Designates a substitute for the link's context. [[  So what is
> the link's context? 'Context' is a least not wider than 'the current document'. 
> [*] http://www.iana.org/assignments/link-relations/link-relations.txt

rel="alternate" *does* refer to the current document, though use of "alternate" for stylesheet links seems fairly incoherent. Even then, however, "rel" is still designating a relationship between the current document and another resource (the alternate stylesheet).

(In reply to comment #48)
> Without VoiceOver. Tried all of them, I think.

Sorry, my comment doesn't apply to the *first* one, which doesn't contain any "a" or "area" to focus, only "longdesc".

Note with HTML+RDFa and rel="longdesc" defined as relating a long description to the link context, you could do:

<img src="foo.jpg"
     alt="{Short alternative}"
     id="image"
     about="#image"
     rel="longdesc"
     resource="long-description.html">

or

<img src="foo.jpg"
     alt="{Short alternative}"
     id="image">

<a href="long-description.html"
   rel="longdesc"
   about="#image">Image description</a>

or

<img src="foo.jpg"
     alt="{Short alternative}"
     id="image">

<span resource="long-description.html"
      rel="longdesc"
      about="#image"></span>

(In reply to comment #48)
> (In reply to comment #44)
> > (In reply to comment #40)
> > > (In reply to comment #30)
> > > > Thus it would be interesting to have your comment to rel="longdesc" in
> > > > combination with image maps: http://malform.no/testing/longdesc/
> > > 
> > > Two thoughts:
> > > 
> > >    * Testing in Chrome, opening the long description involved moving focus to a
> > > imperceptible link. I think that contravenes WCAG2's Visible Focus requirement.
> > 
> > Q1: You tested with VoiceOver? Or was it without screenreader? Which of the 5
> > test pages was it? 
> 
> Without VoiceOver. Tried all of them, I think.

So your concern is the GUI browser user.

> > Q2: Please note that I have taken every step to hide the long description URLs
> > from GUI browsers (media="screen") - only AT and textual browsers are meant to
> > have access - I suppose this does not break WCAG.
> 
> It breaks WCAG2 if a control has focus but focus is invisible or it is not
> clear what the control will do when activated.

So, since @longdesc causes authors to insert redundant anchor links to help those that do not have @longdesc supporting UAs, @longdesc actually causes authors to insert controls that break the WCAG guidelines. E.g. consider again cssquirrel (http://www.cssquirrel.com/comic/?comic=72). 

So as I understand it if I were able to hide a control for all media, except screen readers, then WCAG's recommendations are fulfilled.

> See Success Criteria 1.1.1,
> 2.4.7, 2.4.4/9, and Principles 1 and 3. The fact that I can tab to the
> "longdesc" link/area and activate it means the focus and purpose should be
> clear.

Purpose is clear, or can be made clear, when the link has rel="longdesc": UA can implement support for rel="longdesc. And/Or author can make it visible via CSS This would do the trick:

 a:link:focus, #map a:visited:focus { /* some CSS that makes it visible */ }

I may update my tests so this happens, as soon a I get the time to do it.

> Also note that text equivalents (of which "longdesc" is one)

@longdesc is not a text equivalent, only @alt is. @longdesc only *complements* the @alt. For istance, in this example, the UA will not see the @longdesc, since empty @alt = role="presentation":

<img longdesc="url" alt="" src="image" >

One problem with the above example is that for example my web browser, iCab - which supports @longdesc - *does* present the longdesc URL (in a context menu, as Laura suggests), even when the @alt  is empty, and thereby giving the false impression that non-sighted users can benefit from that @longdesc ....

(Perhaps, btw, an <img> acting as image map should not be considered presentational even if it has an empty @alt - after all, the <map> provides "fallback".)

>  are potentially
> appropriate for /any/ user, not just users of AT or textual browsers. Which is
> why Laura, although she describes "describedby" as for visual impairments,
> stresses it needs to be available to all users. See also the quotations from
> WCAG2 and supporting documentation in comment #23.

I do support that UA make @longdesc visible to all.

> >  Or,  is the correct way to
> > read your comment to assume that you would have said the same thing as you said
> > about (one of) those tests about @longdesc?
> 
> No, since "longdesc" does not create a stop in the tab order and therefore
> never receives focus.

So, again, if we were able to completely hide (so that no "stop" happens) an anchor for everyone, except for screenreader usres, then WCAG would be met?

What about this, which I saw in some of Laura's "examples in the wild": <a class="redundant longdesc link" href="URL"><img width=1 height=1 alt="longdesc link"></a>. To a sighted user, it is completely meaningles.


> > >    * Normally, "rel" specifies a relationship between the destination and the
> > > current document, not a relationship between the destination and a component of
> > > the current document. So I think you'd need to use some other attribute(s),
> > > like "resource" from RDFa (something like I suggested above) or "itemprop" from
> > > Microdata.
> > 
> > Do you have any backup info? I'll note that Julian Reschke of the link type
> > registry did not express any such reservations when I aired this (2-3 weeks ago
> > - public-html). Instead it sounded interesting to him, as I perceived it. Also,
> > when I filed a bug, then Ian accepted the proposal. Perhaps you disagree with
> > his resolution?
> 
> It's an entirely reasonable link relationship; I'm just talking about the "rel"
> attribute.

Got it.

> I was saying you'd need to modify the referent of "rel" using additional
> attributes from RDFa.
> 
> > Whereas HTML4 says
> 
> HTML4 says the same thing about "rel" on "a":
> 
> "This attribute describes the relationship from the current document to the
> anchor specified by the href attribute."
> 
> http://www.w3.org/TR/html401/struct/links.html#adef-rel

My quotes were from HTML4 as well. I agree that HTML4 also says what you are quoting.

> The anchor specified by the "href" attribute, in this case, would be the long
> description URL.
> 
> I guess one can work around this by arguing that "a rel='longdesc'" specifies
> one long description /belonging to/ the document, much as "a rel='cite'"
> specifies one citation belonging to the document, and then there's some magic
> processing to hook it up with a particular "img" element.

Absolutely.

> > Likewise, the link registry [*] defines the 'alternate' link relation as
> > follows:  ]] Designates a substitute for the link's context. [[  So what is
> > the link's context? 'Context' is a least not wider than 'the current document'. 
> > [*] http://www.iana.org/assignments/link-relations/link-relations.txt
> 
> rel="alternate" *does* refer to the current document

That's what HTML5 says. However, the link registry says that it refers to the link's context.  Clearly, the document/page is the link's context. However, the link element and its parent element also defines a context.

It seems to me these discussions should be happening in the email lists, not a bug. But that's up to the powers that be, I guess.

I'm looking at the "solutions" provided, and none seem to meet the needs of what Laura is asking for. 

On the one hand, Laura wants a simple, semantic solution whose use would hopefully encourage its use. John and Matt further clarified that it can't break existing uses (such as when an image is wrapped in a a link).

On the other hand, whatever solution is provided, has to have a set of _expectations_ associated with it so that UAs implement the solution's behavior consistently.

The solutions I'm seeing about object and imagemap and so on are, sorry, bordering on the arcane. And they don't meet HTML5's underlying semantic criteria. 

The solution for RDFa does have interest, especially if RDFa is used elsewhere in the document (because the use would serve a dual purpose: accessibility and "linked data" to use the hot new term). However, there is no place to define a set of expected behaviors for the specific use of RDFa. It doesn't fit in RDFa, it doesn't fit in HTML5, yet it uses pieces of both. 

Not being able to define expected behavior just means that the real purpose of the markup--to ensure the description is easily accessible by those using AT, and also provide a way to access it for folks not using an AT device--can't be fulfilled. 

Benjamin, do you have a solution as to how expected behavior can be defined for the uses of RDFa?

Again, though, even if a way to define expected behavior is provided, the solution is not going to be attractive to folks not using RDFa for other purposes in their document.

Sorry, should be:

On the one hand, Laura wants a semantic solution whose simplicity would
hopefully encourage its use. John and Matt further clarified that it can't
break existing uses (such as when an image is wrapped in a a link).

(In reply to comment #52)

> I'm looking at the "solutions" provided, and none seem to meet the needs of
> what Laura is asking for. 

It does not impress me that you use irony.

> On the one hand, Laura wants a simple, semantic solution whose use would

rel="longdesc" is both simple and semantic. 

> hopefully encourage its use. John and Matt further clarified that it can't
> break existing uses (such as when an image is wrapped in a a link).

Adding rel="longdesc" does not break @longdesc. 
 
> On the other hand, whatever solution is provided, has to have a set of
> _expectations_ associated with it so that UAs implement the solution's behavior
> consistently.
> 
> The solutions I'm seeing about object and imagemap and so on are, sorry,
> bordering on the arcane.

Please note that it is rel="longdesc" that is the solution. Image maps (linked to <img> of <object> - or <canvas>) is just a possible way to implement the solution.

> And they don't meet HTML5's underlying semantic  criteria. 

What is "HTML5's underlying semantic criteria" ? 

I myself am inspired by HTML4, which says that the <map> element may contain anchor elements that renders outside the MAP for the purpose of accessibility - and HTML5 allows the same thing:

]]
Block-level content. This content should include A elements that specify the geometric regions of the image map and the link associated with each region. Note that the user agent should render block-level content of a MAP element. Authors should use this method to create more accessible documents.
[[ http://www.w3.org/TR/html4/struct/objects#edef-MAP

(In reply to comment #54)
> (In reply to comment #52)
> 
> > I'm looking at the "solutions" provided, and none seem to meet the needs of
> > what Laura is asking for. 
> 
> It does not impress me that you use irony.

Sorry, misplaced scare quotes. Consider them removed. 

> 
> > On the one hand, Laura wants a simple, semantic solution whose use would
> 
> rel="longdesc" is both simple and semantic. 
> 
> > hopefully encourage its use. John and Matt further clarified that it can't
> > break existing uses (such as when an image is wrapped in a a link).
> 
> Adding rel="longdesc" does not break @longdesc. 
> 
> > On the other hand, whatever solution is provided, has to have a set of
> > _expectations_ associated with it so that UAs implement the solution's behavior
> > consistently.
> > 
> > The solutions I'm seeing about object and imagemap and so on are, sorry,
> > bordering on the arcane.
> 
> Please note that it is rel="longdesc" that is the solution. Image maps (linked
> to <img> of <object> - or <canvas>) is just a possible way to implement the
> solution.
> 
> > And they don't meet HTML5's underlying semantic  criteria. 
> 
> What is "HTML5's underlying semantic criteria" ? 
>

It's the criteria used to justify adding 30+ elements and attributes. 
 
> I myself am inspired by HTML4, which says that the <map> element may contain
> anchor elements that renders outside the MAP for the purpose of accessibility -
> and HTML5 allows the same thing:
> 
> ]]
> Block-level content. This content should include A elements that specify the
> geometric regions of the image map and the link associated with each region.
> Note that the user agent should render block-level content of a MAP element.
> Authors should use this method to create more accessible documents.
> [[ http://www.w3.org/TR/html4/struct/objects#edef-MAP

Above you said all that would be needed is rel=longdesc. But here you're talking about using map. If map is part of the implementation, than more than rel="longdesc" is needed. 

Where would this usage be defined, in such a way that we could set expectations about what the UAs do?

In the meantime, these bug messages are showing up in the ally email list, but they're showing up unthreaded, which makes them difficult to follow on that list. That's why I wondered if this wouldn't be better as an email discussion. An email discussion would seem to be more suited to what's happening.

But, that's just a suggestion. Feel free to ignore.

(In reply to comment #55)
> (In reply to comment #54)
> > (In reply to comment #52)

> Sorry, misplaced scare quotes. Consider them removed. 

Removed.

> > > The solutions I'm seeing about object and imagemap and so on are, sorry,
> > > bordering on the arcane.
> > 
> > Please note that it is rel="longdesc" that is the solution. Image maps (linked
> > to <img> of <object> - or <canvas>) is just a possible way to implement the
> > solution.
> > 
> > > And they don't meet HTML5's underlying semantic  criteria. 
> > 
> > What is "HTML5's underlying semantic criteria" ? 
> 
> It's the criteria used to justify adding 30+ elements and attributes. 

Still not sure what you mean.  I only know that you disagree with the addition of many of those elements and attributes. Thus you should be happy that rel="longdesc" only adds a @rel value, and nothing. (Well, there is probably something to add, somewhere about what you call expecations.)
 
> > I myself am inspired by HTML4, which says that the <map> element may contain
> > anchor elements that renders outside the MAP for the purpose of accessibility -
> > and HTML5 allows the same thing:
> > 
> > ]]
> > Block-level content. This content should include A elements that specify the
> > geometric regions of the image map and the link associated with each region.
> > Note that the user agent should render block-level content of a MAP element.
> > Authors should use this method to create more accessible documents.
> > [[ http://www.w3.org/TR/html4/struct/objects#edef-MAP
> 
> Above you said all that would be needed is rel=longdesc. But here you're
> talking about using map. If map is part of the implementation, than more than
> rel="longdesc" is needed. 

I wanted to hear if you would describe HTML4's suggestion about how to use <map> as against (some) HTML principle.

It goes without saying that rel="longdesc" needs more - it needs a link element. @usemap is only a way to programmatically associate an IMG and a such a link. (Btw, I could have provided simpler image map examples. But had they been too simple then I perhaps would have gotten to hear that they don't work ... The more image map bugs user agents have, the more complicated must one make the example ... )  Nevertheless, in Comment #45 I showed an example which is quite simple and legal in HTML4/XHTML1 - that it is illegal in HTML5 cannot be used agaisnt it, I mean @longdesc is illegal as well ... (Caveat: unlike my tests as http://malform.no/testing/longdesc/, I have only tested it in one screen reader - VoiceOver)

If @longdesc's only justification is technical, namely those times when the IMG is already wrapped in an anchor element, then it goes without saying that @longdesc isn't going to be much used. I don't think, however, that any of the "examples in the wild" that Laura has documented, has any example of such a use case. If the users don't get used to them, then they only get confused from them - that to me seems logical, and Joshue has also shown a video, that we all know,  and which shows that such confusion can occur in practise.

@longdesc i more than 10 years old. Perhaps we should try to bring to live something which is only 7 years old, the The CSS 'Reader' Media Type:  http://www.w3.org/TR/css3-reader/  That way we would be able to hide links from all users other than screenreaders. That way authors would more easily meet WCAG 2 requirements: rel="longdesc" anchor elements could be hidden from those media that don't need them - see Comment #51. 
 
> Where would this usage be defined, in such a way that we could set expectations
> about what the UAs do?

FIrst: this bug report has digged up many holes in @longdesc. No wonder, of course, as @longdesc has never really been discussed in public-html - it has only been "shouted". (Only once the change proposal was voted over, did anyone actually file @longdesc related bug reports.) One of the holes in @longdesc is: what happens to the @longdesc if the @alt is empty? But of course, this could be described in HTML5. And, since I don't support removal of @longdesc, I suggest that they be described.

Second: One of the change proposals - initiated by you even - is removal of a section in HTML5 which describes how to solve some usecase, including, as I remember, dialogs. (I don't want that section myself.) But I guess that some document would need to describe how to solve the technial problem that @longdesc is able to solve, without @longdesc. Steve's spec is a good place for such advice.

That said, HTML5 also defines image maps, so cleary some of this belongs there. 

Also, such a thing as <a href="*" rel="longdesc"><img src=diagram alt=description ></a> requires that we take a look at the "how to write @alt texts" section again. It also requires, I guess,  a look at the anchor/area elements.

> In the meantime, these bug messages are showing up in the ally email list, but
> they're showing up unthreaded, which makes them difficult to follow on that
> list. That's why I wondered if this wouldn't be better as an email discussion.
> An email discussion would seem to be more suited to what's happening.
> 
> But, that's just a suggestion. Feel free to ignore.

I have some minor mail problems in the moment. But feel free to respond via public-a11y next time.

(In reply to comment #56)
> > > 
> > > > And they don't meet HTML5's underlying semantic  criteria. 
> > > 
> > > What is "HTML5's underlying semantic criteria" ? 
> > 
> > It's the criteria used to justify adding 30+ elements and attributes. 
> 
> Still not sure what you mean.  I only know that you disagree with the addition
> of many of those elements and attributes. Thus you should be happy that
> rel="longdesc" only adds a @rel value, and nothing. (Well, there is probably
> something to add, somewhere about what you call expecations.)
>

I want consistency. 

If we're going to incorporate elements and attributes specifically because they make a semantic unit, then we should apply the same reasoning for all elements and attributes -- not cherry pick through the batch.

If we feel justified in adding a @hidden, we are more than justified in keeping a @longdesc, or adding a @described-by. 

I do not see consistency in the decisions. I'm not talking about words agreeing, I'm talking about the same principles guiding all decisions.

> > > I myself am inspired by HTML4, which says that the <map> element may contain
> > > anchor elements that renders outside the MAP for the purpose of accessibility -
> > > and HTML5 allows the same thing:
> > > 
> > > ]]
> > > Block-level content. This content should include A elements that specify the
> > > geometric regions of the image map and the link associated with each region.
> > > Note that the user agent should render block-level content of a MAP element.
> > > Authors should use this method to create more accessible documents.
> > > [[ http://www.w3.org/TR/html4/struct/objects#edef-MAP
> > 
> > Above you said all that would be needed is rel=longdesc. But here you're
> > talking about using map. If map is part of the implementation, than more than
> > rel="longdesc" is needed. 
> 
> I wanted to hear if you would describe HTML4's suggestion about how to use
> <map> as against (some) HTML principle.
> 
> It goes without saying that rel="longdesc" needs more - it needs a link
> element. @usemap is only a way to programmatically associate an IMG and a such
> a link. (Btw, I could have provided simpler image map examples. But had they
> been too simple then I perhaps would have gotten to hear that they don't work
> ... The more image map bugs user agents have, the more complicated must one
> make the example ... )  Nevertheless, in Comment #45 I showed an example which
> is quite simple and legal in HTML4/XHTML1 - that it is illegal in HTML5 cannot
> be used agaisnt it, I mean @longdesc is illegal as well ... (Caveat: unlike my
> tests as http://malform.no/testing/longdesc/, I have only tested it in one
> screen reader - VoiceOver)
> 
> If @longdesc's only justification is technical, namely those times when the IMG
> is already wrapped in an anchor element, then it goes without saying that
> @longdesc isn't going to be much used. I don't think, however, that any of the
> "examples in the wild" that Laura has documented, has any example of such a use
> case. If the users don't get used to them, then they only get confused from
> them - that to me seems logical, and Joshue has also shown a video, that we all
> know,  and which shows that such confusion can occur in practise.
> 
> @longdesc i more than 10 years old. Perhaps we should try to bring to live
> something which is only 7 years old, the The CSS 'Reader' Media Type: 
> http://www.w3.org/TR/css3-reader/  That way we would be able to hide links from
> all users other than screenreaders. That way authors would more easily meet
> WCAG 2 requirements: rel="longdesc" anchor elements could be hidden from those
> media that don't need them - see Comment #51. 
> 
> > Where would this usage be defined, in such a way that we could set expectations
> > about what the UAs do?
> 
> FIrst: this bug report has digged up many holes in @longdesc. No wonder, of
> course, as @longdesc has never really been discussed in public-html - it has
> only been "shouted". (Only once the change proposal was voted over, did anyone
> actually file @longdesc related bug reports.) One of the holes in @longdesc is:

> what happens to the @longdesc if the @alt is empty? But of course, this could
> be described in HTML5. And, since I don't support removal of @longdesc, I
> suggest that they be described.
>

I would assume that longdesc acts the same way. Just because they're both accessibility attributes doesn't mean they're joined at the hip.
 
> Second: One of the change proposals - initiated by you even - is removal of a
> section in HTML5 which describes how to solve some usecase, including, as I
> remember, dialogs. (I don't want that section myself.) But I guess that some
> document would need to describe how to solve the technial problem that
> @longdesc is able to solve, without @longdesc. Steve's spec is a good place for
> such advice.
>

Sorry, I don't think I wrote anything on dialog. I did write something on not using dt/dd in figure and details, and that was a successful proposal.
 
> That said, HTML5 also defines image maps, so cleary some of this belongs there. 
>

It does?
 
> Also, such a thing as <a href="*" rel="longdesc"><img src=diagram
> alt=description ></a> requires that we take a look at the "how to write @alt
> texts" section again. It also requires, I guess,  a look at the anchor/area
> elements.
> 
> > In the meantime, these bug messages are showing up in the ally email list, but
> > they're showing up unthreaded, which makes them difficult to follow on that
> > list. That's why I wondered if this wouldn't be better as an email discussion.
> > An email discussion would seem to be more suited to what's happening.
> > 
> > But, that's just a suggestion. Feel free to ignore.
> 
> I have some minor mail problems in the moment. But feel free to respond via
> public-a11y next time.

I can't. I'm not a member. And I probably won't be continuing in this discussion, either, because I'm not sure what's going to happen since Ian was removed, and Paul and Sam added as asignees. And I'm not sure I'm adding anything to the discussion.

(In reply to comment #57)
> (In reply to comment #56)
> > > > 
> > > > > And they don't meet HTML5's underlying semantic  criteria. 
> > > > 
> > > > What is "HTML5's underlying semantic criteria" ? 
   [ snip ]
> I do not see consistency in the decisions. I'm not talking about words
> agreeing, I'm talking about the same principles guiding all decisions.

I thought that you leveled "don't meet HTML5's underlying semantic  criteria" against "rel='longdesc'". 
 
>> what happens to the @longdesc if the @alt is empty? [...]

> I would assume that longdesc acts the same way. Just because they're both
> accessibility attributes doesn't mean they're joined at the hip.

Fact 1: The consensus is that an empty @alt equals role="presentation". For the @longdesc to be presented even when @alt is empty, then it seems logical to me that one must eventaully establish an exception to that rule, then. (Because, currently,  an UA should ignore an image which has role="presentation".) 

Fact 2: HTML4 says that @longdesc _complements_ @alt. 

 [ ... ]
> > That said, HTML5 also defines image maps, so cleary some of this belongs there. 
> 
> It does?

Examples of how something can be used  can be placed in the spec.

>> Also, such a thing as <a href="*" rel="longdesc"><img src=diagram
>> alt=description ></a> requires that we take a look at the "how to write @alt
>> texts" section again. It also requires, I guess,  a look at the anchor/area
>> elements.
 
I guess, btw, that if a link wrapper takes you to a document with a larger version of the image, then that page with the larger photo could also contain a visually hidden, longer description. If a screenreader user cannot live with that, then I think he/she should perhaps also consider using Emacsspeak or some other text based browser.  If a photo web site _does_ offer a text-only long description links to its images, then it proves what I said earlier: much more than @longdesc is needed to make a photo site suitable for blind users.

> > I have some minor mail problems in the moment. But feel free to respond via
> > public-a11y next time.
> 
> I can't. I'm not a member. 

Sorry, I misunderstood you, once again. Now that you say it, I of course remember that your  are not a member. 

> And I probably won't be continuing in this
> discussion, either, because I'm not sure what's going to happen since Ian was
> removed, and Paul and Sam added as asignees. And I'm not sure I'm adding
> anything to the discussion.

They must tak for themselves.

(In reply to comment #52)
> It seems to me these discussions should be happening in the email lists, not
> a bug. But that's up to the powers that be, I guess.

People are 100% free to discuss things wherever they want, but so long as the discussion is relevant to the actual bug request, I would be much happier if it stayed in one place (which means here, as it started here).

> And they don't meet HTML5's underlying semantic criteria. 

I fear a thorough discussion of the principles HTML WG should adopt to deal with all issues - a subject on which I suspect the WG would *never* achieve consensus - risks derailing the discussion about this particular bug.

> there is no place to define a set of expected behaviors for the specific use
> of RDFa. It doesn't fit in RDFa, it doesn't fit in HTML5, yet it uses pieces
> of both. 

Why do you think it's a bad fit for UAAG Techniques?

> Benjamin, do you have a solution as to how expected behavior can be defined
> for the uses of RDFa?

    1. Pick or create a vocabulary that expresses the semantic relationship we want.
    2. Spec out the behavior you'd like and put it at some permanent URL.

> Again, though, even if a way to define expected behavior is provided, the
> solution is not going to be attractive to folks not using RDFa for other
> purposes in their document.

I doubt the set of people able and willing to provide long descriptions significantly differs from the set of people able and willing to use HTML+RDFa (or authoring tools that use HTML+RDFa), assuming it ever gets standardized.

(In reply to comment #59)
> (In reply to comment #52)
> > It seems to me these discussions should be happening in the email lists, not
> > a bug. But that's up to the powers that be, I guess.
> 
> People are 100% free to discuss things wherever they want, but so long as the
> discussion is relevant to the actual bug request, I would be much happier if it
> stayed in one place (which means here, as it started here).

Whatever. As long as it continues constructive, I suppose. 

> 
> > And they don't meet HTML5's underlying semantic criteria. 
> 
> I fear a thorough discussion of the principles HTML WG should adopt to deal
> with all issues - a subject on which I suspect the WG would *never* achieve
> consensus - risks derailing the discussion about this particular bug.
>

I don't believe so. 

If some elements and attributes are added because they're semantically meaningful--rather than using alternatives--then that must be justification for adding another attribute for the same purpose.
 
> > there is no place to define a set of expected behaviors for the specific use
> > of RDFa. It doesn't fit in RDFa, it doesn't fit in HTML5, yet it uses pieces
> > of both. 
> 
> Why do you think it's a bad fit for UAAG Techniques?
>

It could be. But that's not RDFa+HTML5 or HTML5. Or are you suggesting that this be handled by another group? In which, this is definitely outside of the scope of a but for the HTML WG.
 
> > Benjamin, do you have a solution as to how expected behavior can be defined
> > for the uses of RDFa?
> 
>     1. Pick or create a vocabulary that expresses the semantic relationship we
> want.
>     2. Spec out the behavior you'd like and put it at some permanent URL.
> 

And we define UA expectations...how?

> > Again, though, even if a way to define expected behavior is provided, the
> > solution is not going to be attractive to folks not using RDFa for other
> > purposes in their document.
> 
> I doubt the set of people able and willing to provide long descriptions
> significantly differs from the set of people able and willing to use HTML+RDFa
> (or authoring tools that use HTML+RDFa), assuming it ever gets standardized.

I would think that a simpler approach would have more adherents than a complex one. I like RDFa, but I've never thought of defining expectations for behavior based on RDFa. I especially never thought about approaching say, JAWS, or the like and tell them they now have to incorporate support for RDFa, just so that we don't have to have something like described-by.

(In reply to comment #59)
> (In reply to comment #52)
    [...]

> > Benjamin, do you have a solution as to how expected behavior can be defined
> > for the uses of RDFa?
> 
>     1. Pick or create a vocabulary that expresses the semantic relationship we
>        want.
>     2. Spec out the behavior you'd like and put it at some permanent URL.

A page at microformats.org? 

> I doubt the set of people able and willing to provide long descriptions
> significantly differs from the set of people able and willing to use HTML+RDFa
> (or authoring tools that use HTML+RDFa), assuming it ever gets standardized.

Like Shelley, I don't think we can expect Jaws to handle RDFa. I also think that A11Y people should not have to learn RDFa in order to make accessible pages. But couldn't a rel="d-link"/rel="longdesc" be compatible with your RDFa idea? Shouldn't they work together? Via RDFa on can be more exact about the relationship, I should think  - not?

Meanwhile, I don't believe a theory and/or principle based discussion of @longdesc can ever "reach home" unless we are also solve the fundamental practical problem that @longdesc raises:

1. @longdesc's relationship to @alt, especially to empty @alt
     (since empty @alt makes the img ignored).
2. What to do when/while there is lack of user agent support? 
     Duplicate the @longdesc in a link?

Regarding 2., then is it ever any good to duplicate a @longdesc URL in an anchor element?   Does the programmatic relationship of @longdesc generally outweigh the confusion that can be had when someone with Jaws get both a @longdesc announcement as well as a link to the same page? 

In other words: a main problem with @longdesc, as I see it, is that it does not offer "progressive enhancement/fallback": A user agent supporting @longdesc should have a method for ignoring a link that is used for the same purpose, no? Jaws does announce "visited link" if the link has already been visited. Fine. But the user may not understand that the visited link is in fact equal to @longdescs link.

If the UA were able to understand that a link is used  in the same role as @longdesc, then they could possibly ignore the link. Is JAWS, for instance, able to ignore a D-link that points to the same places as a @longdesc link pionts? Anyone knows? 

Of course, I must mention that @rel="longdesc"/rel="d-link" could play a role for the progressive enhancement: when @longdesc is present, then the ua could ignore an <a rel="longdese" href=*></a> link that points to the same resource.

(In reply to comment #56)
> (In reply to comment #55)
> > (In reply to comment #54)
> > > (In reply to comment #52)

> If @longdesc's only justification is technical, namely those times when the IMG
> is already wrapped in an anchor element, then it goes without saying that
> @longdesc isn't going to be much used. I don't think, however, that any of the
> "examples in the wild" that Laura has documented, has any example of such a use
> case.

Actually, she has. At least this page: http://www.ncddr.org/kt/products/focus/focus25/index.html

WebLight is a cross platform  link and validation tester which includes @longdesc URL checking.

http://www.illumit.com/weblight/

(In reply to comment #60)
> If some elements and attributes are added because they're semantically
> meaningful--rather than using alternatives--then that must be justification
> for adding another attribute for the same purpose.

No elements/attributes were added *purely* because someone proposed a meaning
for them and HTML5 is *not* produced by an automatic application of consistent,
appropriate principles. Discussing the lack of such principles may be worthwhile,
but it is no more relevant to this bug than any other.
 
> > Why do you think it's a bad fit for UAAG Techniques?
> 
> It could be. But that's not RDFa+HTML5 or HTML5. Or are you suggesting that
> this be handled by another group? In which, this is definitely outside of the
> scope of a but for the HTML WG.

The bug tracker can express dependencies on bugs assigned to other WGs, if
necessary.

> > > Benjamin, do you have a solution as to how expected behavior can be
> > > defined for the uses of RDFa?
> > 
> >     1. Pick or create a vocabulary that expresses the semantic relationship
> > we want.
> >     2. Spec out the behavior you'd like and put it at some permanent URL.
> > 
> 
> And we define UA expectations...how?

Well, *one* possible approach would be as follows:

   1. Submit a new WCAG2 Technique demonstrating how to use RDFa to associate a
long text alternatives with an "img" element, comparable the existing
HTML4/XHTML1 "longdesc" technique [1], using the submission form provided [2].
   
   2. Reformulate Requirements 2-5 in terms of UAAG2 [3] success criteria
(3.1.1-3, 3.10.6, 3.11.7, 3.12.2, 3.13.2, 4.1.1 look relevant) as a series of
examples for inclusion in Implementing UAAG2 [4].

Another approach would be to publish a spec then try and implement it.
 
> > I doubt the set of people able and willing to provide long descriptions
> > significantly differs from the set of people able and willing to use
> > HTML+RDFa (or authoring tools that use HTML+RDFa), assuming it ever gets
> > standardized.
> 
> I would think that a simpler approach would have more adherents than a
> complex one.

You're right. I'll restrict myself to the hypothesis that there is more overlap
between the two groups than not. Please note by "use HTML+RDFa", I mean copying
and pasting HTML+RDFa markup, not understanding the intricacies of HTML+RDFa
parsing. Much like people copy and paste Facebook's HTML+RDFa [5] without even
realizing it's HTML+RDFa!

> I especially never thought about approaching say, JAWS, or the like and tell
> them they now have to incorporate support for RDFa, just so that we don't
> have to have something like described-by.

Ideally, we'd simply want UAs to give URLs designated as long descriptions
the same accessibility API mapping they give to "longdesc" today (e.g. IE puts
"longdesc" in the MSAA "accDescription" property), to avoid burdening AT with
implementing HTML+RDFa.

The risk is that HTML+RDFa might never be standardized or implemented by the
popular browsers with which popular AT is typically partnered.

I don't think anyone disagrees that simple, native features are preferable for
requirements HTML WG agrees to support.

[1] http://www.w3.org/WAI/GL/2010/WD-WCAG20-TECHS-20100708/H45.html
[2] http://www.w3.org/WAI/GL/WCAG20/TECHS-SUBMIT/
[3] http://www.w3.org/TR/UAAG20/
[4] http://www.w3.org/TR/IMPLEMENTING-UAAG20/
[5] http://developers.facebook.com/docs/opengraph

(In reply to comment #61)
> Like Shelley, I don't think we can expect Jaws to handle RDFa. I also think
> that A11Y people should not have to learn RDFa in order to make accessible
> pages.

Covered both issues in my reply to Shelley in comment #64.

> But couldn't a rel="d-link"/rel="longdesc" be compatible with your RDFa
> idea? Shouldn't they work together? Via RDFa on can be more exact about the
> relationship, I should think  - not?

Did you see my comment #50?

> Meanwhile, I don't believe a theory and/or principle based discussion of
> @longdesc can ever "reach home" unless we are also solve the fundamental
> practical problem that @longdesc raises:
> 
> 1. @longdesc's relationship to @alt, especially to empty @alt
>      (since empty @alt makes the img ignored).
> 2. What to do when/while there is lack of user agent support? 
>      Duplicate the @longdesc in a link?

If you want your text alternative to be available to users of all user agents,
include it in-page or use a visible link, since these methods work in every
user agent and make the alternative discoverable by every user.

> Regarding 2., then is it ever any good to duplicate a @longdesc URL in an
> anchor element?

Yes, it can do *some* good.

> Does the programmatic relationship of @longdesc generally outweigh the
> confusion that can be had when someone with Jaws get both a @longdesc
> announcement as well as a link to the same page? 
> 
> In other words: a main problem with @longdesc, as I see it, is that it does not
> offer "progressive enhancement/fallback"

I agree that's a drawback of "longdesc" and, more relevantly to *this* bug, the
proposed new attribute.

> A user agent supporting @longdesc should have a method for ignoring a link
> that is used for the same purpose, no?

If it wants.

> Jaws does announce "visited link" if the link has already been visited. Fine.
> But the user may not understand that the visited link is in fact equal to
> @longdescs link.

Duplicate links like the following are a common antipattern on the web:

    <a href="somewhere.html">
        <img src="somepic.jpg" alt="{Article title}">
    </a>
    <a href="somewhere.html">{Article title}</a> 

How much does this antipattern confuse real users?

I've known screen reader users to complain about clutter on web pages, but
inability to access a text alternative arguably constitutes a greater
accessibility barrier than the clutter of a duplicate link.

> If the UA were able to understand that a link is used in the same role as
> @longdesc, then they could possibly ignore the link.

They could, though it's not without risk.

If a UA ignored the long description annotation when the user reads the "img",
the user might never reach the long description link. But if it ignored the
long description link, the user might miss out on any additional JS behavior
the author attached to that control.

> Is JAWS, for instance, able to ignore a D-link that points to the same places
> as a @longdesc link pionts?

JAWS 11 apparently includes a feature for automatically filtering out all
duplicate links:

http://www.freedomscientific.com/downloads/jaws/JAWS-whats-new.asp

I don't know if it applies this behavior to "longdesc".

(In reply to comment #65)
(In reply to comment #61)
>> Like Shelley, I don't think we can expect Jaws to handle RDFa. I also think
>> that A11Y people should not have to learn RDFa in order to make accessible
>> pages.
>
> Covered both issues in my reply to Shelley in comment #64.

OK.

> > But couldn't a rel="d-link"/rel="longdesc" be compatible with your RDFa
> > idea? Shouldn't they work together? Via RDFa on can be more exact about the
> > relationship, I should think  - not?
> 
> Did you see my comment #50?

You don't show any examples where the @rel appears inside an anchor/area element ...  So I guess that's a diff between your and mine idea: You want screenreaders to treat some RDFa code the same way that they treat @longdesc - simply put, you want screenreaders to support "dark links"  in RDFa.

Whereas I suggest to link a behaviour to @rel="longdesc", only when used in <a> or <area>.

Please note that in Charles's change proposal, then <img> would become defined as an interactive element. It seems like you operate with another understanding of "interactive" than he does ... 

But back to my question: are our ideas compatible, or not?  

Let us say that we agree about a definition of rel="longdesc" - whenever there is no RDFa in use. This would allow authors to become creative in using <area> and <a> to create longdesc link solutions.  I am quite sure that many would come up with solutions.

Then, also take in your idea: In addition user agents could implement support for a specific subset of RDFa - such as you showed in comment #50. The would the use the same rel="longdesc". Except that they would not need to use it inside an <a> or <area> element.

> > Meanwhile, I don't believe a theory and/or principle based discussion of
> > @longdesc can ever "reach home" unless we are also solve the fundamental
> > practical problem that @longdesc raises:
> > 
> > 1. @longdesc's relationship to @alt, especially to empty @alt
> >      (since empty @alt makes the img ignored).
> > 2. What to do when/while there is lack of user agent support? 
> >      Duplicate the @longdesc in a link?
> 
> If you want your text alternative to be available to users of all user agents,
> include it in-page or use a visible link, since these methods work in every
> user agent and make the alternative discoverable by every user.
> 
> > Regarding 2., then is it ever any good to duplicate a @longdesc URL in an
> > anchor element?
> 
> Yes, it can do *some* good.

OK?

> > Does the programmatic relationship of @longdesc generally outweigh the
> > confusion that can be had when someone with Jaws get both a @longdesc
> > announcement as well as a link to the same page? 
> > 
> > In other words: a main problem with @longdesc, as I see it, is that it does not
> > offer "progressive enhancement/fallback"
> 
> I agree that's a drawback of "longdesc" and, more relevantly to *this* bug, the
> proposed new attribute.

Yup. It would also be a drawback to the RDFa solution you suggest, though - unless you apply the RDFa to a "real" link element.

> > A user agent supporting @longdesc should have a method for ignoring a link
> > that is used for the same purpose, no?
> 
> If it wants.

Well, it should probably be optional, yes.

> > Jaws does announce "visited link" if the link has already been visited. Fine.
> > But the user may not understand that the visited link is in fact equal to
> > @longdescs link.
> 
> Duplicate links like the following are a common antipattern on the web:
> 
>     <a href="somewhere.html">
>         <img src="somepic.jpg" alt="{Article title}">
>     </a>
>     <a href="somewhere.html">{Article title}</a> 
> 
> How much does this antipattern confuse real users?

Enough to make Jaws create a filter for the issue - according to what you say below. ;-)

> I've known screen reader users to complain about clutter on web pages, but
> inability to access a text alternative arguably constitutes a greater
> accessibility barrier than the clutter of a duplicate link.

Sure. So if a user cannot access the longdesc resource simply because his/her UA doesn't support @longdesc ... We have an accesibility issue ... Has anyone created javascript library that adds suppport for @longdesc, somehow?

But it is *then* that one must start asking if it isn't necessary to add something to HTML which, by the right authoring choices, can be made to work in all user agents. I don't ask for removal of @longdesc, I just ask for the opportunity to create something that works for all. Adding some kind of RDFa microformat will not help (unless, of course, it is used inside a/area). Only a link based solution can be truly acessible her and now.

Btw, w.r.t. to RDFa, you did see comment #15? There is a Issue in the RDFa Working Group (requested by yours truly) to define an RDFa mapping for @longdesc. You should perhaps see that threed - the working group seemed to be in favour of some kind of "hard coded" semantics for @longdesc. And I just wondered if rel="longdesc" etc should/can be "hardcoded" as well. (Probably best to discuss it "over there".

> > If the UA were able to understand that a link is used in the same role as
> > @longdesc, then they could possibly ignore the link.
> 
> They could, though it's not without risk.
> 
> If a UA ignored the long description annotation when the user reads the "img",
> the user might never reach the long description link. But if it ignored the
> long description link, the user might miss out on any additional JS behavior
> the author attached to that control.

But if that link had rel="longdesc", then it would have reason to trust that it could filter it out.

> > Is JAWS, for instance, able to ignore a D-link that points to the same places
> > as a @longdesc link pionts?
> 
> JAWS 11 apparently includes a feature for automatically filtering out all
> duplicate links:
> 
> http://www.freedomscientific.com/downloads/jaws/JAWS-whats-new.asp

Thanks for the info!

> I don't know if it applies this behavior to "longdesc".

with regards to benjamin's suggestion:

QUOTE
Please note by "use HTML+RDFa", I mean copying
and pasting HTML+RDFa markup, not understanding the intricacies of HTML+RDFa
parsing. Much like people copy and paste Facebook's HTML+RDFa [5] without even
realizing it's HTML+RDFa!
UNQUOTE

supporting author ignorance by simply telling them "copy-and-paste" this markup into your content if X equals Y is a HORRENDOUS idea -- the point of native semantics is to be easily understood and implemented by developers and authors alike -- telling authors to use pre-canned snippets of HTML+RDFa is a complete non-starter -- HTML should NOT be encouraging authors to copy-and-paste snippets of code without the author/content creator understanding how that code works, how it is expressed by a UA or assistive technology, and how to tailor that code to the content creator's needs...

also, i would like to point out that there are many users of assistive technology not only in the HTML A11y Task Force, but in the HTML WG itself -- when questions about specific technologies and the support provided thereby arise, they should be addressed to actual end users of the technology, not those who know accessibility only as a checklist or an abstraction -- as i have noted in an earlier bug, bugzilla is NOT the optimal forum for such exchanges, as bugzilla itself has major accessibility problems -- i would, therefore, ask members of the HTML WG to PLEASE address specific inquiries about how assistive technology handles specific markup or what options are open to the user of the AT, by posting to public-html-a11y@w3.org

a native HTML5 describedby attribute, which can link to external as well as internal structured content, can be leveraged by a content creator to create a visual binding between an image and its description using simple CSS -- this is an example of describedby having utility for those who do not use an assistive technology, but who would benefit greatly from an visual binding of a description and the object it describes

(In reply to comment #68)

> an example of describedby having utility for those who do not use an assistive
> technology, but who would benefit greatly from an visual binding of a
> description and the object it describes

I will  note that Laura, when she filed this bug said:

" Like the HTML4 longdesc attribute a correct and proper describedby is redundant for people who have sight. "

I think, if we want something that works also for sighted, the we should focus on a link relation - something like rel="longdesc". That way we would be able to achieve something that is useful to all.

(In reply to comment #67)
> supporting author ignorance by simply telling them "copy-and-paste" this markup
> into your content if X equals Y is a HORRENDOUS idea -- the point of native
> semantics is to be easily understood and implemented by developers and authors
> alike -- telling authors to use pre-canned snippets of HTML+RDFa is a complete
> non-starter -- HTML should NOT be encouraging authors to copy-and-paste
> snippets of code without the author/content creator understanding how that code
> works, how it is expressed by a UA or assistive technology, and how to tailor
> that code to the content creator's needs...

> supporting author ignorance by simply telling them "copy-and-paste" this
> markup into your content if X equals Y is a HORRENDOUS idea -- the point of
> native semantics is to be easily understood and implemented by developers and
> authors alike -- telling authors to use pre-canned snippets of HTML+RDFa is
> a complete non-starter -- HTML should NOT be encouraging authors to
> copy-and-paste snippets of code without the author/content creator
> understanding how that code works, how it is expressed by a UA or assistive
> technology, and how to tailor that code to the content creator's needs...

Authors operate at varying levels of abstraction.

It seems to me that most authors operate at a high level of (doubtless highly
leaky) abstraction and don't understand how HTML "works" beyond the level of
inserting "a", "b" and "i" tags and expecting the browser to link and render
the text accordingly.

If you literally tell authors to copy and paste code with no explanation
whatsoever, then of course they will fail. If you tell them what parts of the
code they need to change and why, they may well achieve their goal (in this
case, associating images with long descriptions) without understanding every
detail of how it works (in this case, how bytes are converted into characters
which are parsed into a DOM, from which N-triples are extracted, some of which
are selected to be mapped into MSAA in the "accDescription" field, on the
basis of which JAWS will notify the user a long description is present and
allow the user to open the long description in a new window).

For example, you could give authors a hidden long description recipe as
follows:

   - Create a separate HTML page containing your long description.  Identify
     your "img" element with a unique "id" attribute (e.g. "my-image")
   - Put an empty "span" element beside it to hold machine-readable information
     about how to locate the long description.
   - Set the "resource" attribute of the "span" to the URL of the long
   - description.  Set the "about" attribute of the "span" to reference the
   - "img" element (not the image source) by fragment URL by putting a hash
     sign before the "id" value (e.g. "#my-image").
   - Set the "rel" attribute of the span to "longdesc" to indicate the resource
     is a long description for the subject of the "about" attribute (i.e. the
     "img" element).

Note how the Facebook Open Graph documentation does not attempt to explain to
authors the mysteries of how the Open Graph annotations are converted to
N-triples, and concentrates on explaining to authors what the various
properties mean.

Given WG opposition to retaining "longdesc" and given uncertainty about the
direction ARIA will take, I'm trying to assess Laura's assertion that "HTML5
fails to adequately provide" Requirements 1-6 by looking at whether HTML5 and
sister technologies (specifically ARIA and HTML+RDFa) can meet these
requirements or not. It seems to me that while these technologies do not (and I
would argue should not) mandate user interface, they can be used to express the
semantics of associating a long description with an image and enable the
building of user interfaces meeting the stated requirements. (At any rate,
nobody has demonstrated that they cannot.)

I do not dispute that simpler features are preferable, and will see higher
adoption.

(In reply to comment #67)
> also, i would like to point out that there are many users of assistive
> technology not only in the HTML A11y Task Force, but in the HTML WG itself --
> when questions about specific technologies and the support provided thereby
> arise, they should be addressed to actual end users of the technology, not
> those who know accessibility only as a checklist or an abstraction -- as i have
> noted in an earlier bug, bugzilla is NOT the optimal forum for such exchanges,
> as bugzilla itself has major accessibility problems -- i would, therefore, ask
> members of the HTML WG to PLEASE address specific inquiries about how assistive
> technology handles specific markup or what options are open to the user of the
> AT, by posting to public-html-a11y@w3.org

Will that work?

I thought HTML WG members cannot mail that list without being members of the
HTML Accessibility Task Force, and that members of the public (like Shelley)
cannot mail that list at all?

As a WG member, I've asked to join the Task Force, for what it's worth.

In reply to comment #69

i, for one, have maintained from the beginning that a verbose description mechanism is NOT only for those who cannot process an image at all, but that it has benefits for many other user groups:  for example, a user with an extremely limited viewport may only be able to process the information contained in the image through the direction and guidance provided by the verbose descriptor; likewise, it is relatively easy, using simple CSS, to make a strong visual binding between a verbose descriptor and the object it describes -- a box of a certain color could be generated to provide a color-coded border for an image for which a verbose descriptor has been defined/cited and the same color
could be used as a background color for the description of the object bounded by that background color (optimally, a the user could use an intelligent user agent to provide such visual bindings through the use of a client side style sheet, which is a process that i and others have been waiting and suggesting for a long time that an intelligent user agent will assist end users in creating client-side style-sheets through a "wizard" type interface, so that an end user need not know CSS in order to designate client-side styling)

this is why i have oft articulated the mantra: "a verbose descriptor
should not be an either-or option for a user -- there are users who 
will benefit greatly from the description even though they are capable
of visually processing the described image, in whole or in part

this is an aspect of the verbose descriptor requirment (whether met 
by longdesc or native describedby) i have attempted to convey in 
collecting "Verbose Descriptor Requirements" on the HTML A11y TF 
wiki:

http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs

(In reply to comment #16)
> (In reply to comment #12)

John, 

> This was indeed an early technique that the web accessibility community used in
> the late 90's, most often as an anchor element around 'd' or 'd-link'. The
> 'visual' intrusion of a link associated to an image was an issue then, and so
> we had a situation where authors created 'invisible' (actually hidden) d-links
> that were targeted to screen reading technology. The use of d-links was
> deprecated in favor of using longdesc with the release of WCAG 1.
> (http://www.w3.org/TR/WCAG10-TECHS/#def-d-link /
> http://www.w3.org/TR/WCAG10-HTML-TECHS/#img-dlink-invis) 

There is no deprecation. WCAG 2 includes D-links too. Though they are no referred to as 'description links' and they have also  jumped away from usign that visible (or even hidden) "D".  Take a look at WCAG technique G73:

http://www.w3.org/TR/WCAG20-HTML-TECHS/G73.html#G73-description
 
> There is no indication that we will not see a return to this type of behaviour:
> in fact, as examples from the wild show us, the hiding technique is alive and
> well, but now uses CSS to place the link off-screen. As a result, these types
> of techniques then impact on requirement 2:

G73 suggests hiding the description by wrapping an invisible (1px wide) <img> in a link - I wonder which ARIA @role to use on that <img> ...
G73 also suggest using the caption as a caption element and descriibing the purpose of the link in the @title attribute. 
(But according to Steve, screenreader users don't use the @title attribute - http://www.paciellogroup.com/resources/articles/WE05/forms.html.)
 
> " 2. A way to inform users and authors that a description is present/available
> via user agent ... a way to inform users
> of a link to a longer description that exposes this fact to both sighted and
> non-sighted users."

Indeed. Therefore I don't understand why you don't come out in support of @rel="longdesc". As G73 makes clear: *even* when one can use a visible link (as a caption), there is still necessary to make clear that that it is a link to a long description.

in reply to comment #71

benjamin -- i for one would very much welcome more and varied participation in
the HTML A11y TF, especially yours, as i have found your work for the WG to be
consistently thorough...

re-checking the TF's work statement, located at:

http://www.w3.org/WAI/PF/html-task-force

i found the following:

QUOTE
Members of the public who are not covered by the W3C Patent Policy can send
input to the public-pfwg-comments mailing list [public-pfwg-comments archive],
or the public-html-comments mailing list [public-html-comments archive].
Messages should clearly indicate the deliverable to which they are related and
that they are relevant to the work of the HTML Accessibility Task Force.
UNQUOTE

since this has been a question that has arisen before (how to submit comments
so that they are efficiently and expeditiously brought to the attention of the
HTML Accessibility Task Force's members and facilitators) would it be possible
for the chairs to speak on this issue, as:

1. there are already too many HTML5-centric lists to which one can post; how
best to funnel feedback directly to the A11y TF needs to be determined by the
chairs, as the public-html-a11y@w3.org list is publicly viewable, but one
cannot -- as you pointed out -- post to it if one isn't already subscribed to
public-html-a11y; 

2. the severe limitations of bugzilla -- in the case of this bug, like so many
others, without headers to mark the beginning of individual comments,
everything after the FORM-stuffed-in-a-TABLE appears as undifferentiated text,
making it difficult to navigate what not only constitutes the "meat of the
matter" but also comprises the vast bulk of the information contained in the
bug report without recourse to copying-and-pasting the complete bug report into
a plain text editor (which is obviously less-than-optimal, as one is then
forced to work on a snapshot of the bug report, rather than working with a
document that may be updated during the composition of a comment

therefore, should accessibility inquiries, comments, questions and suggestions
be funneled to the HTML A11y TF via public-pfwg-comments@w3.org ?

(In reply to comment #72)
> In reply to comment #69
> 
> i, for one, have maintained from the beginning that a verbose description
> mechanism is NOT only for those who cannot process an image at all, but that it
> has benefits for many other user groups:

Good. I said it only because a correct problem description affects which solutions we look at. If we want to reach many uses, then we should also look at the feature that all users use: links. Hence rel="longdesc".

>  for example, a user with an extremely
> limited viewport may only be able to process the information contained in the
> image through the direction and guidance provided by the verbose descriptor;

An excellent usecase! Would love that on my Nokia mobile phone.

> likewise, it is relatively easy, using simple CSS, to make a strong visual
> binding between a verbose descriptor and the object it describes -- a box of a
> certain color could be generated to provide a color-coded border for an image
> for which a verbose descriptor has been defined/

Indeed. But the same could also be possible with the help of  selector such as  [rel="longdesc"]. 

  [...]
> this is why i have oft articulated the mantra: "a verbose descriptor
> should not be an either-or option for a user -- there are users who 
> will benefit greatly from the description even though they are capable
> of visually processing the described image, in whole or in part

I absolutely agree that many authors and designer are willing to provide visible long descriptions, even when the long descripion could be redundant. 

However, I think that if the long description is linked to via a feature (read @longdesc) which  most user agents do not support and which most users are unaware of, then they may not be as willing to make it clear. 

That's why, in addition to @longdesc, we should *also* be able to use plain old links, equipped with programmatic purpose information, to link to long description.

(in response to comment #70)

benjamin -- i agree with your recipe for providing meaningful verbose description generation:

QUOTE
  - Create a separate HTML page containing your long description.  Identify your "img" element with a unique "id" attribute (e.g. "my-image")

  - Put an empty "span" element beside it to hold machine-readable information about how to locate the long description.

  - Set the "resource" attribute of the "span" to the URL of the long

  - description.  Set the "about" attribute of the "span" to reference the

  - "img" element (not the image source) by fragment URL by putting a hash sign before the "id" value (e.g. "#my-image").

  - Set the "rel" attribute of the span to "longdesc" to indicate the resource is a long description for the subject of the "about" attribute (i.e. the "img" element). 
UNQUOTE

in fact, i would encourage you to submit your step-by-step list for providing verbose descriptors to the Authoring Tool Accessibility Working Group (http://www.w3.org/WAI/AU/ for consideration and possible addition to http://www.w3.org/TR/2010/WD-IMPLEMENTING-ATAG20-20100708/#principle_b2 "Implementing Principle B.2: Authors must be supported in the production of accessible content") 

NOTE: the Authoring Tool Accessibility Guidelines version 2.0's last call review period ends today, 2 september 2010 -- the last call draft is available at http://www.w3.org/TR/2010/WD-ATAG20-20100708/ whilst comments should be sent to: public-atag2-comments@w3.org

personally, i am an ardent advocate of RDFa, its use and deployment, but as a user dependent upon assistive technology, i am more concerned at this point in the webolutionary proccess that AT developers more consistently and completely support ARIA before i would expect or demand that they be able to parse RDFa...

of course, in the best of all possible worlds, assistive technologies would be implementing support for both ARIA and RDFa, for RDFa notation could be leveraged by an assistive technology to make a user's interaction with content marked-up with RDFa a far richer and meaningful by providing explicit annotations that could be used for selecting, sorting, navigating, and a far fuller discovery of the annotated content; especially when the material being annotated comprises educational materials, historical documents, or legal or medical records

FYI, this bug got a sister: bug 10455, "Mint a link type for pointing to long descriptions (rel="longdesc")"

(In reply to comment #39)
> (In reply to comment #37)

> > I want to point out that for the code example above, the only link text
> > is the @alt text. Thus the alt text has to serve a double cause: as link
> > text and as @alt text.
> 
> That's the common case for alt text today. I don't know what problem this
> solves. 

WCAG 2.0 technique G73 only demonstrate how to use *adjacent* links as description links. An image wrapped in a link is only discussed from the angle of creating images as links, including invisible image links.

http://www.w3.org/TR/WCAG20-HTML-TECHS/G73

(In reply to comment #77)
> FYI, this bug got a sister: bug 10455, "Mint a link type for pointing to long
> descriptions (rel="longdesc")"

Sorry, wrong number for the bug - correct number: bug 10434.

(In reply to comment #74)
> in reply to comment #71

> therefore, should accessibility inquiries, comments, questions and suggestions
> be funneled to the HTML A11y TF via public-pfwg-comments@w3.org ?

The HTML WG Chairs feel that the answer to this question is YES.

If anyone has difficulty doing this they should contain one of the HTML WG chairs for assistance.

/paulc

benjamin previously asked,

quote
> Does the programmatic relationship of @longdesc generally outweigh the
> confusion that can be had when someone with Jaws get both a @longdesc
> announcement as well as a link to the same page? 
unquote

and

quote 
> Is JAWS, for instance, able to ignore a D-link that points to the same places
> > > as a @longdesc link pionts?
> > 
> > JAWS 11 apparently includes a feature for automatically filtering out all
> > duplicate links:
unquote

quote
> http://www.freedomscientific.com/downloads/jaws/JAWS-whats-new.asp
> I don't know if it applies this behavior to "longdesc".
quote

one cannot filter out LONGDESC from links because JAWS 11 does not include LONGDESC values in its list of links, it does not include longdesc in the tab-navigation order, nor does it provide an indication that a long description is available for a graphic; 

since longdesc values do NOT appear in the tab navigation order when using JAWS, in order to get to a longdesc, one can use the list of graphics contained in the document in order to retrieve the long description, by using the Graphics List to move focus to an individual graphic, whose longdesc can then be accessed by hitting the ENTER key (not the way i would have designed it, but that is the way it works)

longdesc values do NOT appear in JAWS' list of links, nor does JAWS provide a means of indicating to the user that a long description is available -- to discover if a longdesc is available, one needs to place focus on a graphic and then hit enter to ascertain if a long description is available

D-links do appear in the JAWS list of links, but unless WCAG 2.0 Technique C7 is used, it is difficult (read: impossible for most users) to differentiate between individual D links

so, even when one enables "filter duplicate links" with current and past versions of JAWS, it will still include the D-link even if there is a identical longdesc value defined for the graphic, and there remains the problem (repeatedly reported to JAWS' developers) that there is a need to indicate when/if a longdesc is available for a graphic in the list of graphics and to include an option for users to place graphics with long descriptions defined for them into the tab-order

i hope this clarifies what JAWS can and does do with longdesc and supplemental D-links that point to the identical resource

longdesc and D-links in W3C documents

as a member of the (now-defunct) Rich Web Applications Backplane Incubator Group (RWAB XG), i ensured that the RWAB XG's final report 

http://www.w3.org/2005/Incubator/app-backplane/XGR-app-backplane-20091030/

contained a long description for each illustration contained in the report... (ironically, i had to write them with a sighted assistant, since i was the one who pushed for them)

there was some concern on the part of other XG members that since longdesc is spottily implemented, it would be prudent to supplement the longdesc value by providing a "modern" D-Link, that is a link which appears on the visual palette as:

[_D_]

where the underscores mark the beginning and the end of the descriptive text, as was the model provided by CSS2, which provided redundant D links as a means of providing support for the long descriptions contained in CSS2 as an "until user agent..." strategy, as then recommended by WCAG 1.0; the problem with such 
a strategy is that by using repeated link text (namely "D") to refer to different resources 

in the RWAB XG document, the D link concept was "modernized" using WCAG 2.0 Technique C7 to provide contextual content which is hidden from the visual palette using CSS overflow; this was done in order to make it possible for users to differentiate between the 9 D-links by providing contextualization for each D-link 

example:
<p><img longdesc="figure1.html" src="figure1.gif" 
alt="Figure 1: Layers of a Rich Internet Application" /></p>

<p>Figure 1: Layers of the Rich Web Application Backplane [<a 
href="figure1.html" 
title="description of Figure 1: Layers of the Rich Web Application"
>D<span class="context">escription of Figure 1</span></a>]</p>

(In reply to comment #81)

> where the underscores mark the beginning and the end of the descriptive text,
> as was the model provided by CSS2, which provided redundant D links as a means
> of providing support for the long descriptions contained in CSS2 as an "until
> user agent..." strategy, as then recommended by WCAG 1.0; the problem with such 
> a strategy is that by using repeated link text (namely "D") to refer to
> different resources 

the last clause of this paragraph should be:

the problem with such a strategy is that by using repeated link text (namely "D") to refer to different resources makes it extremely difficult for a user to associate each individual D-link with the graphic which it describes -- it has been suggested that one could use aria-describedby to associate an individual D-link with the graphic it describes, but the D-link "solution" was meant as a bridging technique until native support for longdesc was implemented by user agents, and mechanisms for indicating that a long description is available for a graphic should be something that is handled natively by the user agent, as long descriptions benefit more than those who are totally bind, as has been pointed out repeatedly in the past

References:

Research
http://www.d.umn.edu/~lcarlson/research/ld.html

Examples In the Wild
http://www.d.umn.edu/~lcarlson/research/ld.html#wild

Guidelines, Laws, Policy, and Standards
http://www.d.umn.edu/~lcarlson/research/ld.html#glps

Tools
http://www.d.umn.edu/~lcarlson/research/ld.html#tools

Online Tutorials and Documentation
http://www.d.umn.edu/~lcarlson/research/ld.html#tutorials

Related Articles and Blog Posts
http://www.d.umn.edu/~lcarlson/research/ld.html#articles

HTML5 Issue
http://www.d.umn.edu/~lcarlson/research/ld.html#issue

An offer to the HTML5 team to save longdesc
http://rebuildingtheweb.com/en/offer-to-save-longdesc/

This bug is directly related to Issue-30:
http://www.w3.org/html/wg/tracker/issues/30
 
/paulc

The HTML WG co-chairs believe that this bug has been addressed by the WG's decision on ISSUE-30.

/paulc
on behalf of the HTML WG co-chairs

The bug-triage sub-team thinks this should be accessibility task force priority. A couple of bugs have been filed to fill the vacuum that the removal of @longdesc has left, there is discussion on the mailing list, so we believe this should be discussed in the task force.

Given that the longdesc extension is now a FPWD[1], the Task Force has decided to close this issue.

[1] http://www.w3.org/TR/html-longdesc/