Warning:
This wiki has been archived and is now read-only.

Talk:LongdescRetention

From HTML WG Wiki
Jump to: navigation, search

Hi Mike,

I give up. Matt can do whatever he wants with this page. I won't be working on it further.

My original research still exists at: http://www.d.umn.edu/~lcarlson/research/ld.html

Laura

--

Hi Mike,

I see one of my edits has been reverted without comment again. Could you undo and lock the page again while we discuss?

Regards Matt

--

Hi Laura,

The current duplication of information is sub-optimal. Your titles are not research quality - how does one decide "Examples with Redundant Link Text" is a useful title when it could just as usefully be "Text Links with Redundant Longdesc"?

Other information e.g. about whether a D-Link is visible or hidden is clearly relevant information.

I've removed the duplicated information.

Regards Matt


Hi Matt,

You deleted my "Examples with No Visual Link Text Clutter" and "Examples with Redundant Link Text" research twice. I reinstated them. That is the truth.

Please do not remove my research again.

Laura

---

Hi Laura,

I'm going to put this as tactfully as I can: if your case to reinstate the longdesc attribute relies on circulating mistruths, making up evidence and misleading by omission, imho you have a very weak case.

We have a shared goal here: we both believe that making all the relevant information available will help folks to reach an informed decision on the case for/against a longdesc attribute. I do not see how deliberately removing relevant information supports that goal.

I'm going to add my additional information again. If you wish to remove this information I think you should describe why you think it is necessary to omit relevant information on this page first.

Regards Matt


Hi Laura,

I've updated the age with new categories. I've also removed one longdesc example, because it did not use a longdesc attribute (just a d-link implemented via a "d" image) http://www.laits.utexas.edu/txp_media/html/part/features/0603_01/slide1.html

I've also added CSS2.1 spec (visible d-link), and 2 mass.gov examples (hidden d-link) via Sarah Bourne

Regards Matt


2010-08-30 JST: I'm unlocking the page. A reminder about rules: Anybody is allowed again to make changes to this page freely. Nobody is allowed to revert anybody else's edits. If we have another case of anybody doing that on this page, I will lock it up again. --Mike

Hi Laura,

Gregory discussed the original goal of this page here: http://www.w3.org/2008/02/19-xhtml-minutes.html

I think our goal for this page should be to provide all the relevant information the Working Group may need, without misleading by commission or omission.

Regards Matt


Hi Matt,

This page is named "Longdesc Retention". The goal is Retention. Your goal is the opposite of that.

I have researched and gathered a huge amount of significant new information for my argument to retain Longdesc. I am preparing arguments not a Wikipedia article. My work was disrupted and hacked to pieces.

Please feel free, to copy my research and organize it on a LongdescDeletion page if you wish. However, I would really appreciate it if you would please refrain from disrupting my work further. We are at cross purposes. I have more data and analysis to do. I would like to get back to doing it in peace.

Laura

---

Hi Laura,

If the links are the sticking point here I could re-edit the page to include my new information but keep your two headings. See below - but the two initial headings were imho poorly chosen, so I would prefer to replace them with more informative headings. FWIW I think the moral of the story is choose good, neutral headings from the beginning in future.

Something like:

1.6.1 Examples with No Visual Link Text Clutter

1.6.1.1 Without a Link on the Image, No Fallback

1.6.1.2 Without a Link on the Image, With Spacer Image Link

1.6.1.3 With a Link on the Image to the LONGDESC URL

1.6.1.4 With a Link on the Image to a Different URL

1.6.2 Examples with Redundant Link Text

1.6.2.1 Without a Link on the Image, With Hidden Text Link

1.6.2.2 Without a Link on the Image, With Non-Hidden Text Link

Not ideal, but in its current form any decision that cited the examples in the wild on this page would be unsound, since it would not be based on all the information available. Regarding the poor quality of the current examples, I think the answer is to find better examples, not to hide information about how poor they are.

On a related note, I would also like to discuss the possibility of removing your example, since it was created after the chairs made their decision, and it's main use case appears to be to provide another example for this page. Your thoughts?

Regards Matt

--

Hi Mike, Hi Laura,

I think the new information I added is clearly relevant to the page's existing content and the ongoing longdesc discussion, and it should be reinstated.

I don't think it's a show stopper if a page anchor is broken, if the net effect is better information.

Regards Matt

--

Hi Mike,

I have spent an extraordinary amount of time researching new longdesc information and am in the process of organizing and analyzing and gathering more: Longdesc Examples in the Wild with No Visual Link Text Clutter.

http://www.w3.org/html/wg/wiki/LongdescRetention#Examples_with_No_Visual_Link_Text_Clutter

My research is investigating: "Examples with No Visual Link Text Clutter" and "Examples with Redundant Link Text" (another subcategory will be D links and probably others). Please don't let my work be reorganized ino a different research methodology.

I have linked to that section of the page in several places in the wild and people are referring to it. Those headings/link anchors are important. It's been sent it to a dozen or so mailing lists and forums. It is in the wild. Please don't allow others to break my links.

Matt unilaterally reorganized the information that I had gathered and changed the topics I am investigating. He added no new links. The name of this page is LongdescRetention. The goal of this page to retain LongDesc. Matt does not want to contribute to the Retention of LongDesc. His intentions are to insure it is dropped.

If someone wants to copy all of the research I have added to this page (I contributed all of those links) to another page and do a separate analysis that is fine with me. But please don't stop my progress here.

Thanks.

--- Laura, I'm noticing that you reverted, without comment, some additions that another user had made to the page. I think the protocol for the Wiki is that we should not revert each others' edits without discussion. Is there a dispute about whether the reverted content was relevant or not? If so, could we please have some discussion here and get it resolved? Maybe one thing worth considering is having the information on another page and linking to that.

Reasons for Deprecating LONGDESC and Alternative Proposals

Eric Eggert

I’m in favor dropping @longdesc because I think there are better alternatives. First I have a few considerations, when @longdesc would make sense.

  1. Images which are showcased and where you need every detail.
  2. Academic graphics and graphs.

There’s no use using @longdesc with other images either because there description with @alt is sufficient or because surrounding Elements give enough impression or because it's just plain decorative and should have been done with CSS but wasn’t.

My solution would be dropping the @longdesc in favor for a @rel=longdesc. This would be consistent in all current, past and future browsers eliminating any accessibility problems and give screen readers something they can rely on.

To make it more universal you could even name it alternative (like stylesheets) to provide alternative ways for captchas, for example.

One major drawback is, that the image itself can’t be a link to e.g. another image (like in galleries), which can or cannot be acceptable considering that I think the most links on images are some kind of @longdesc at the moment.

source: Eric Eggert, post to public-html on 25 June 2007

Peter Krantz

I agree with previous comments that there is a need to describe complex images in a more structured way. The current method of using longdesc to link to an extended description may not be the best way.

Problems with the current longdesc method

  1. Assistive devices need to make an extra HTTP request to retrieve the content. A risk for availability problems.
  2. It is unclear how the web page containing the extended description should look. If it includes the web site navigation toolbars and headers it increases the time to reach the content for the user.
  3. It is difficult to script usage of the extended content to e.g. display it in a popup when hovering the image.
  4. Search engines need to make an extra request to get information about the image.
  5. Forcing the user to navigate to a separate page increase the risk for usability problems (do they know they can click the image?).

Proposal

If research shows that longdesc usage is limited, now is a good time to change the markup. Eric Eggert's suggestion makes sense but there should be a connection with the image to enable programmatic discovery and manipulation of the extended description text. As we should strive for backwards compatibility I suggest the following.

  • longdesc attribute of the img element is removed
  • the role attribute is used to identify a longdesc
  • the for attribute is used to connect the extended description to a particular image

An example:

 
<img src="/flag.gif" id="ukflag" alt="">

...

<div role="longdesc" for="ukflag">
  <p>The Flag of Union has been the official flag of the United Kingdom since the Act of Union of 1807, which created the modern political entity known as the United Kingdom, which, this year, celebrates its 200th anniversary.</p>
  <ul>
      <li>Whatever...</li>
  </ul>
</div>
 

This method has the following advantages:

  1. Backwards compatible with HTML 4. Current UA:s will render the content.
  2. Easier for assistive devices to parse and present extended description in a different context.
  3. Better usability. Extended description is available without the need to navigate to a new page.
  4. Scriptability. Etended content div can e.g. be hidden and displayed on mouseover or whatever the designer wants.
  5. Easy to add this markup to existing web pages. An editor only needs to wrap the existing description in a div like above to increase accessibility.

This method has the following disadvantages:

  1. Makes pages with many complex images heavier to download.

Robert Burns

Are we talking about visual UAs here? Or all UAs? I've said this before, but I think it bears repeating because the point gets lost (often with facetious responses). We should understand that @longdesc is the after-thought addition of fallback content to an element that is defined as canonically empty. @alt is also part of dealing with that problem. So I think we should deal with those two attributes in that context. We should try to think of how we can move <img> to a true embedded content element (like <picture> that has been suggested). We should figure out how @alt relates to genuine fallback content (and @longdesc as a feeble attempt at fallback content). In other words is it unnecessary for elements with genuine fallback content and only necessary for <img> and <embed> because they lack that capability.

Then I think we should deal with this in a forward looking way. Perhaps we need do nothing in the short-term with @longdesc. It can merely be one of those omitted attributes along with the <img> element in HTML5. The future will bring <picture>fallback</picture>, alongside <video> and <audio>.

For the present implementation compatibility, I'm not sure what we need do. We could recommend authors use @longdesc to point to local elements only (within the same document). Perhaps we need a <longdesc> element. UAs could easily add longdesc {display: none} for screen media to their default stylesheets and easily support this interim approach. However, in the long-term I think we should fix these deficiencies in the language so that someday we won't have to deal with these piecemeal approaches anymore.

I've seen a several dismissive remarks on adding a <picture> element in the HTML5 iscussions. However, the need for a new embedded element with fallback content for still images is far more important than adding <video> and <audio>. I'm not saying I'm against those new elements, but the need for them is far less than for a new embedded content element with fallback for still images.

If we're talking about visual UAs, I think that this content could be made available through an inspector or contextual menu. By adding this to visual UAs it would help raise awareness for authors. However, most users of purely visual UAs will not need to access this content.

[source: http://lists.w3.org/Archives/Public/public-html/2007Jun/1063.html Robert Burns, post to public-html 30 June 2007]

Robert Burns' Addendum

Let me just add a two more related themes I've been trying to convey along with this.

1) <img> had fallback content added to it twice. Once as @alt and once as @longdesc: each has strengths and weaknesses. @alt is loaded right there with the other content, but has no rich semantic capabilities. While @longdesc has rich semantic capabilities but is either loaded from an entirely separate page or an element within the same page that now must have iss display or visibility property managed (presumably hidden by default). By following the <object> element method this gains the benefits of both @alt and @longdesc but without an of their drawbacks. However, this division of fallback methods on the <img> element has also lead to a divergence in practice: in other words different use-cases for the two different fallback methods. @allt is expected to be short and sweet. While @longdesc is expected to point to a more elaborate fallback description.

So the other question I"ve been trying to raise is whether @alt may be needed on all of the other embedded content elements in addition to the elements contents. We also have @title that serves a similar role (so that suggests maybe we don't). But if we don't need @alt on these other elements (to serve as this secondary abbreviated fallback description) than do we really need it on <img> (at least an <img> that already has @longdesc)? Again, I don't have an answer to this, I'm just posing it to hopefully help make the language cleaner in some distant future.

2) Based on my understanding for the rationale for listing elements and attributes as omitted (i.e., we omit @style not because it won't be there for use, but because we feel its not best practice for authors once the alternative HTML5 mechanisms are sufficiently implemented).,So, do we need another category for something like <embed>.. Here we have an element where we need to add @alt and @longdesc (most likely) and call for UAs to implement those on this element. At the same time its an element(along with <img>) that should not be used in best practice in the future (like @style).

(Note, I'm not saying we've made any decisions on any of these I'm speaking hypothetically about decisions we might make and how we should best handle them). So in this case we would need to omit <embed> while at the same time add @longdesc and @alt to it. Similarly we would be omitting <img> and with that @longdesc. Again, I'm just trying to facilitate some discussion of these issues and get us all on the same page.

source: Robert Burns, post to public-html, 30 June 2007

Lachlan Hunt

Fixing the existing <object> element, which at least already works in some UAs, provides a much better solution than introducing a new element that doesn't work in any UA.

 
<object data="image">fallback</object> is equivalent to the <picture> idea.
 

Ben Hoyle: Thoughts on LONGDESC and Inline Fallback Content

Ian Hickson asked we define issues - real issues and not "X is omitted from spec"

I ask if this is the kind of issue analysis required. I'm reluctant to edit the wiki without getting a feel from the mailing list first.

The issue: fallback mechanisms are required for embedded content. (I trust I don't need to repeat the reasons why here, our design principles cover this from many angles).

Let us not assume (yet) any proposal is correct.

HTML 4 has:

  1. <img>: @alt for short (text only) embedded alternatives and @longdesc for rich (HTML) alternatives accessible via URI.
  2. <object>: fallback content (HTML) within <object>

Note that these two fallback mechanisms are different.

HTML 5 draft currently proposes:

  1. <img> with @alt (currently does not include @longdesc)
  2. <object> - same as HTML4
  3. <embed> with NO fallback mechanism
  4. <video> and <audio> with (HTML) fallback derived from content
  5. <figure> (with any of the above) provides <legend> for captions

Note that video/audio use the same mechanism as object, embed offers nothing, figure adds something new and img has lost its (explicitly defined) richer fallback mechanism.

When I read this spec, it means this to me: Aha, new elements. Aha, fallback is done through child elements, like <object> in HTML 4 and the proposal to use @src everywhere in XHTML2* Hmm, @longdesc isn't there.

I deduce that @longdesc isn't there yet because (yes I know, we haven't researched it fully) people aren't convinced it effectively solves the problem. I deduce that video and audio do not use @alt and @longdesc because people are convinced the <object> fallback mechanism is a better solution to the problem. I deduce that video and audio DO have a defined fallback mechanism, in contrast to @longdesc on img, because people DO believe it adequately solves the problem.

Now, does anyone else think fallback mechanism for all embedded content is the same problem, regardless of media type or tag name?

I don't understand why img and embed do not have comparable fallback mechanisms defined. If the <object> fallback model is best, shouldn't we adopt it for all embedded content? If @alt is better, shouldn't it be used on all embedded content? If @longdesc is best, shouldn't we use that? (And it need not be either, all three - and more - could be used, if there was a good case for doing so).

I apologise for not "making a use case" at this point. I look forward to producing some soon. For now I want to let you ponder why we propose different fallback mechanisms...

  • nothing for embed
  • text only (@alt) for img
  • HTML for video, audio, object

To summarise my view: the problem appears to be solved, but hasn't been applied retrospectively to img and embed elements.

source: Ben Boyle, post to public-html, 30 June 2007

Geoffrey Sneddon

Simply: backwards-compatibility. |embed| could have an attribute added to it (but its content model can't be changed without breaking all current UAs). |img| similarly can't have its content model changed. The rest of the elements can have such things in backwards compatible ways (|video| and |audio| due to HTML's handling of unknown elements, and |object| because it is already implemented in that way).

source: Geoffrey Sneddon, post to public-html, 30 June 2007

Lachlan Hunt

The method used to reveal the long description is up to the assistive technology. It doesn't need to navigate away from the page as if following an ordinary link, it could reveal it in a separate context instead (e.g. a side bar or popup). Authors certainly shouldn't attempt to override the UAs behaviour by using scripts in this case, since interfering with that is likely to cause more problems that it solves. Just let the UA do its job and deal with the issue of how to give the user access to the page.

(source: Lachlan Hunt, post to public-html, 30 June 2007

Joshue O Connor

Presenting the longdesc content in another pop-up is IMO an inelegant solution also so I would suggest a discussion on what would be the best way to present this information to the user in a manner that is non disruptive. (Although this is a user agent issue it is still important that for our side we have a clear idea of how it ideally should be rendered.

I think if it could be retrieved by the UA and then automatically read out, rather like @summary and the user could just move focus when they have finished. No pop-ups, navigating to other pages etc.

(source: Joshue O Connor, post to public-html, 30 June 2007

Peter Krantz

Am I right in assuming that you mean something like this:

 
<picture src="ukflag.gif">
   <p>The UK flag consists of yada yada.... and:;/p>
   <ul>
      <li>hackety hack</li>
   </ul>
</picture>
 

If I want to display the fallback content and the picture at the same time, how should that be rendered in UAs? Or do I have to repeat the fallback content elsewhere in the page?

(source: Peter Krantz, post to public-html, 30 June 2007)

The description of a complex picture may be helpful to people without a disability. Why hide it in the fallback content and force editors to repeat the content elsewhere? If I make it part of the page, how would e.g. a screen reader know that the particular content is connected to the image?

Why not make it possible to use CSS and script to modify the presentation of the description. An example could be that the user is able to click and slide out the description from underneath the image or choose to display it some other way.

(source: Peter Krantz, post to public-html, 1 July 2007)

Robert Burns

I think you're discussing two different issues at the same time.

  1. How we recommend UAs (especially visual UAs) handle fallback content;
  2. How one should author content that is not fallback content; and
  3. Whether fallback content is necessary if the author has already said everything desired in the main content.

In terms of the first issue: yes, it may be desirable to have UAs make fallback content available for viewing alongside the parent content or to swap between the two. One use case I could imagine would be someone with a visual impairment who is not totally blind. Similarly, someone with a cognitive disability may benefit from reading textual description of visual and aural media that is otherwise difficult to comprehend.

On the second and third issues, an author may include lengthy prose about embedded content and then the author may determine she has nothing else to say in the fallback content. For example this author may note be targeting an audience that requires any further descriptive content. The media itself provides everything necessary through its own fallback content such as closed captioning. Or as I've stated before, we might recommend UAs extract description metadata right out of an image and an author determines that metadata description is sufficient for the audience's fallback content. In these cases the fallback would be left blank.

The HTML5 recommendation could eventually include some discussion of these boundary issues and how authors might or might not require fallback content. It also might be useful to provide specific guidance to visual UAs on how they might present content with fallback content combined or alternate between the two.

(source: Robert Burns, post to public-html, 1 July 2007)

Sander Tekelenburg

Then the content isn't fallback content and shouldn't be marked up as such. The <picture> will then need other, true fallback content. Or the picture may be purely decorative and thus ought to have no fallback content.

By the way, this made me realise that there seems to be a downside to <picture>: how could authors indicate that <picture src="meaninglessdecoration.gif"></picture> has no fallback content on purpose?

Same applies to <object>, <video> and <audio>.

(source: Sander Tekelenburg, post to public-html, 1 July 2007

Peter Krantz

Let's change the example to make it more realistic:

 
<picture src="http://homepage.floodcity.net/users/mastdog/ezrachurch.jpg">
  <p>The coferedat  brigades of Lee, Thomas and Schfield  surround the
city of Atlanta.</p>
  <p>2 miles from Atlanta, close to Ezra church, Logan's base camp was
set up.</p>
  <p>Inside atlanta were:</p>
  <ul>
    <li>....</li>
  </ul>
</picture>
 

In my opinion this counts as reasonable fallback content for the linked picture. And, it isn't unreasonable to assume that this content would be valuable for all visitors to the page as would be the case for many other images that desribe more complex scenarios than a flag.

So, maybe we are discussing separate issues here as Robrt Burns said?

(source: Peter Krantz, post to public-html, 1 July 2007)

Lachlan Hunt

In that case, there is little value in explicitly providing the text as a long description. It is only useful if the image contains significant information that is unavailable or cannot be deduced from elsewhere in the page.

If the image is merely a graphical representation of the surrounding content, then just provide suitable alt="" and title="" attributes that explain what the image is. For that example, I would recommend just marking it up something like this:

 
   <img src="http://homepage.floodcity.net/users/mastdog/ezrachurch.jpg"
        alt="The confederate brigades of Lee, Thomas and Schfield
             surround the city of Atlanta."
        title="Map illustrating the location of the confederate brigades
              around Atlanta">

   <p>The confederate brigades of Lee, Thomas and Schfield  surround the
      city of Atlanta.</p>
   <p>2 miles from Atlanta, close to Ezra church, Logan's base camp was
      set up.</p>
   <p>Inside Atlanta were:</p>
   <ul>
     <li>....</li>
   </ul>
 

Alternatively, the image could be marked up within a <figure> using the title="" as the caption (<legend>).

(source: Lachlan Hunt, post to public-html 1 July 2007)

Thomas Broyer's Example of An Alternate to LONGDESC

 
<p><a href="#figure-4">Figure 4</a> shows the GridView after a number
of rows have been selected for deletion. <a href="#figure-5">Figure
5</a> shows the screen immediately after the "Delete Selected
Products" button has been clicked. Note that in Figure 5 the
<code>ProductID</code> values of the deleted records are displayed in
the <code>Label</code> beneath the <code>GridView</code> and those
rows are no longer in the <code>GridView</code>.</p>

<figure id="figure-4">
  <picture src="65fig04VBs.gif">
    <p>Checkboxes for the first, second, third, seventh, eighth and
tenth lines are checked.</p>
  </picture>
  <legend>Figure 4: The Selected Products Will Be Deleted (<a
href="65fig04VB.png">Click to view full-size image</a>)</legend>

<figure id="figure-5">
  <picture src="65fig05VBs.gif">
    <p>Products previously selected have disappeared from the grid and
the following text has been added below the grid:</p>
    <p><samp>ProductID 1 has been deleted<br>
      ProductID 2 has been deleted<br>
      ProductID 3 has been deleted<br>
      ProductID 7 has been deleted<br>
      ProductID 8 has been deleted<br>
      ProductID 10 has been deleted<br>
    </samp></p>
  </picture>
  <legend>Figure 5: The Deleted Products' ProductID Values are Listed
Beneath the GridView (<a href="65fig05VB.png">Click to view full-size
image</a>)</legend
</figure>
 

(source: Thomas Broyer, post to public-html, 1 July 2007)

James Graham

The problem is this:

    <object> works in most browsers except IE
    <picture> works in no browsers

A-priori then, since less effort is required to fix the bugs in one browser than to implement a new element in multiple browsers, it is better not to introduce the extra complexity of a new element. Indeed, <picture> itself may, if specced, still not have identical implementations in all browsers, so not improving the current situation at-all.

There are several ways that this argument could be countered:

  • If it were known that Microsoft had no intention of changing their broken <object> behavior, ever, but would implement a <picture> element. Regrettably, Microsoft have not been forthcoming with their viewpoints in this WG [Note 1].
  • If <picture> were defined with a better fallback mechanism than <object> so it would work very-nearly as-intended in existing UAs
  • If it were demonstrated that <picture> offered significant advantages over <object> to either authors or implementors in the simplicity of writing documents or UAs respectively so as to provide a trade-off for the extra language complexity of having multiple ways of achieving the same effect.
    [Note 1] With the notable exception their intention to tie the HTML 5 doctype to a specific set of rendering bugs.

(source: James Graham, post to public-html, 2 July 2007)

Martin Kliehm

I have used @longdesc several times for information on flyers for parties and political protests, either pointing to text on the same page (which could be handled by @aria-describedby), or on another page where the text was available anyways (for which there is no alternative attribute). The latter is extremely convenient, and I could imagine that's applicable for stock and other charts as well, where the information exists already on another page.