LongdescRetention

From HTML WG Wiki
Revision as of 17:32, 24 August 2010 by Lcarlson (Talk | contribs)

Jump to: navigation, search


Contents

HTML 5 Issue: Image Equivalent Content

Requirement

In situations where images are not available to the user (because of disability, choice, or UA limitation) there is a need for a mechanism that presents equivalent content to the user, either as an alternative to the image or in a side-by-side exposition. Equivalent content is not, nor should it be, and either/or proposition, and its method of exposition should be subject to user control, as some user groups may need both the image and its detailed description in order to make sense of the image or — in the case of a user with an extremely small viewport — to follow the image's flow.

Status

Recommendation and Polls


LONGDESC Issues & Change Proposals


Use Cases

The following consumer groups are amongst those who have a need for semantically rich, structured and often lengthy descriptions of images whenever these images are not decorative or simply icons Note that even for icons some text equivalent is necessary for such users to understand the document. However, the text equivalent in the case of an icon, may be satisfied with a short and not necessarily structured phrase.

For the case of non-decorative images, the users in these groups cannot comprehend the meaning of the document through the typical visual interpretation of the images. Instead, when a user within these groups wants to comprehend the images and their role in the document, an alternate text or audible mechanism is needed to be able to read or listen to the content.

Blind Users

Blind users are unable to view the original image so need enough fallback content to replace the entire function of the image within the page. Providing a short summary of the image in cases where its overall content is complex may allow them to choose to read a more detailed description if the image is of interest.

Legally Blind Users

The term "legally blind" is ascribed to individuals with a visual acuity of 20/200 or less. This means that there is a wide spectrum of users, with a wide spectrum of visual acuity less than 20/200, covered by the term "legally blind"; from those who can perceive only the starkest of contrasts (white upon black), those who inhabit a grey shadow world, to those to whom the world is a whirl of mostly indistinct objects and colors. Some users classified as legally blind will be able to use and interact with some portions of a document instance's graphical layout, mostly through the use of screen-magnification software and keyboard input. The term "legally blind" also covers what is commonly known as "tunnel" or "straw" vision, meaning that the individual can only receive visual stimuli through an extremely restricted viewport; hence the name, "straw vision", for it has been described as having one's perception of the visual world limited to a viewport the size of the circumference of a drinking straw. The term also covers those who have no useable vision except for peripheral vision. Some "legally blind" users will rely on screen-magnification alone, others either need or prefer supplemental speech-synthesis.

Low Vision Users

Low Vision Users are a distinct class of users. They include those whose eyesight is deteriorating or has deteriorated, but whose visual acuity remains higher than 20/200. This means that a low vision user can sometimes discern the graphical layout and composition of a page, but who either cannot use a mouse effectively for navigation and interaction, or who finds it less painful to use a version of a document instance that does not rely on graphics. This can vary from graphic to graphic, and according to various external circumstances (lighting, time of day, etc). Despite its lack of general acknowledgement, "low vision user" is a term which contains a very broad spectrum of users.

Users on low bandwidth / high cost connections

Users who wish to conserve bandwidth may turn images off. The page should remain intelligible and should provide enough information about any missing images that they are able to decide whether to download a particular image.

Users with non-graphical UAs

Users with non graphical UAs should still be able to understand the contents of a page.

Users of data-mining tools

Users of data mining tools such as search engines are not only interested in understanding the meaning of a single page that has meaningful content conveyed visually through images, but instead wants to perform queries, selections and other operations on many documents. Often they may be interested in operating on documents containing one or many images based on many properties not easily determined by machine processing such as: subject matter, context, content and composition. While machine processing may be capable of processing images based on technical properties — colors, gamma, aspect ratio, bit density and depth, etc — processing image content based on subject matter is still not possible.

While often data mining tools may be able to process text around an image to guess at its content and composition, this is a poor substitute for text descriptions aimed explicitly at describing an image and its place in a document. For example, an image of an eagle may be used in a document describing wildlife that makes no explicit mention of an eagle or even birds in general. The data mining analysis would have to expand its parameters to include wildlife to find this image of an eagle. However, such a expansion of the parameters would lead to a unnecessarily large set of data and hinder the goals of the user. So for this group, users want to perform standard mining of data relevant to images contained in HTML documents that yields desirable results to queries and selections and sorting based on the subject matter and the context of the images.

Authors trying to target users in any of these groups

Users, in a role as HTML authors, may want to produce content that can be consumed by any user in the above groups.


Proposed and Existing Soulutions

<img alt="">

Advantages:

  • Widely supported by UAs
  • Widely used by authors
  • Authoring "best practice" favours the use of @alt to provide equivalent content that can be included inline.
  • Provides potentially easy UA and user access to a brief summary description of embedded content
  • Widely implemented in policy requirements for accessibility

Disadvantages:

  • No rich markup, so it is only suitable for a single paragraph or idea to describe an image
  • By convention only used for a short summary - not sutiable where more detail is needed
  • Often misunderstood/misused by authors
  • Wrong, unuseful and inconsistent implementations across UAs make @alt less useful for users and contribute to confusion amongst authors. See test case and recommendation

It will be assumed that other mechanisms can be combined with @alt to provide a short summary/long description pair

based on test case showing a.o. non-interoperability of @alt implementations and discussion

Proposal for Improving ALT

Add the following to the spec's definition of alt:

  • Authors must use no more than n characters (or words) as the value of the alt attribute. For longer alternatives authors may use longdesc.
  • UAs must make at least the first n characters (or words), of the alt attribute easily discoverable and available to users when the image is, for whatever reason, not presented. (For example, UAs may present the alt text in place of the image; or through a tooltip or in a status bar on hovering the indicator of the missing image; etc.)
  • UAs must make at least the first n characters (or words), of the alt attribute easily discoverable and available to users when the image is, for whatever reason, not presented. (For example, UAs may present the alt text in place of the image; or through a tooltip or in a status bar on hovering the indicator of the missing image; etc.)
Counter Argument in Favor of Unlimited ALT Text

While there is a need for brevity in ALT text, it must also be remembered that (a) the limit on the number of characters in a tooltip is potentially very high; and (b) that requiring user agents to ignore the part of the ALT text that exceeds a smaller limit, is potentially a problem. Yes, the goal in using ALT is to provide a quick alternative to, for example, a graphically defined link, but it isn't the graphic that the user is most interested in, but the functionality it represents; forcing user agents to discard ALT text longer than n characters would compromise the purpose of ALT text. (GregoryRosmaita:)


<img longdesc="">

Advantages:

  • Provides a mechanism for using either an external resource or part of the existing page as a description
  • Already supported by some UAs
  • Internal content is visible-by-default in image-supporting UAs (moved this from con to pro. People have generally described the ability to do this as a feature. ChaalsMc)

Disadvantages:

  • Little correct use in practice despite being standard
  • External content adds a maintainance burden (likely to get out of sync)

<object>

Advantages:

  • Fallback to rich child content
  • Included in single document but not-visible to image-supporting UAs
  • Some browser support
  • Support in the most recent browsers is reaching feature complete

Disadvantages:

  • Browser interoperability is poor
  • Authoring may be more difficult than using an IMG element

<picture>

Advantages:

  • Potentially the same fallback mechanism as <object>
  • May be more intuitive for authors

Disadvantages:

  • No existing implementations
  • Hard to make backward-compatible will not easily degrade gracefully.

<a href="fallback.html"><img></a>

Advantages:

  • Fallback accessible in all UAs

Disadvantages:

  • Not suitable for images that are also links
  • May confuse users not expecting the image to link to a description of itself
  • May discourage authors from using this technique due to not wanting to confuse users

<img>fallback</img> in XML serialization

For XML serialization we have the opportunity to specify UA conformance in advance.

Advantages:

  • Allows semantically rich and media rich fallback content
  • <img> is already familiar to authors
  • Works in existing visual XHTML UAs
  • Degrades gracefully in that visual UAs do not display the contents of the element.
  • Potentially compatible with authors authoring to XHTML2 conformance

Disadvantages:

  • "fallback" not displayed in any graphical UAs at present (just as with the current <img longdesc>)
  • XML and HTML serializations are forked for img fallback.
  • "Fallback" will be need to be translated when converting an HTML5 document serialized as XML to the HTML serialization.

CSS3 "content" property

CSS3 draft

Advantages

  • Allows semantically rich fallback content
  • Falls back gracefully in existing UAs that do no support images
  • Outside the scope of HTML specs, and can be used regardless of the status of HTML specifications

Disadvantages:

  • Does not work in most current graphical UAs
  • Hard to make backward compatible by degrading to <img> before degrading to rich content
  • Undermines the separation of concerns by including semantic data in the style sheet

CSS image replacement techniques

Using Background-Image to Replace Text

Pros:

  • Requires no changes to HTML or UAs
  • Proven to work

Cons:

  • Difficult to implement
  • May be inaccessible in some circumstances
  • Undermines the separation of concerns by including semantic data in the style sheet

<video> element for still image (single-frame video)

CSS3 draft

Pros:

  • Allows semantically rich fallback content
  • Works in any HTML5 conforming UA
  • All of the advantages of <video> when used for <video> (see WhatWG archives)

Cons:

  • Does not work in most current graphical UAs

Discussion

RATIONALE for PRESERVING LONGDESC in HTMLx

The purpose of LONGDESC is to describe the contents of the image as fully and completely as possible.

Gregory J. Rosmaita's Original Rationale for Retention

There are many compelling arguments for the retention of the LONGDESC attribute, as defined in HTML 4.01 Strict. A mainstream arguement for LONGDESC is that there is a moral and often legal need for it amongst academics, educational institutions, and government entities, as more and more course content migrates to the web or intranets, equal access demands that they provide a meaningful long description.

Academics constantly complain to me that if they are to teach students without vision or with very low vision, they need more than ALT or CAPTION -- they need to describe the subtleties of the image being presented as content for those who cannot see the content, and those who have found a longdescription helpful, as a key to the symbolism contained in the image; or as a means of expounding on a static image of a map (such as of a migration, a battlefield, a schematic of a subway system, etc.)

The following is an example of the difference between a caption for an image, and a long description of that image. The image in question is an image of the British flag; the occasion? As an illustration accompanying an article on the 200th anniversary of the formation of the United Kingdom. Such a caption might read:

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.

Now, compare that to the following LONGDESC:

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.

The flag of the United Kingdom is commonly known as the Union Flag, or Union Jack. It is the national flag of the United Kingdom of Great Britain and Northern Ireland. The flag's design dates from January 1, 1801, as a symbol of the Act of Union of 1800, which merged the Kingdom of Ireland and the Kingdom of Great Britain (until 1707, the United Kingdoms of England and Scotland), to form the United Kingdom of Great Britain and Ireland.

The flag symbolically uses the national flags of England, Scotland, and Ireland to form a single flag comprised of:

  • the flag of Scotland, which bears Saint Andrew's cross: a white X on a blue field; and
  • the flag of Ireland, which bears Saint Patrick's cross: a red X on a white field;
  • the flag of England, which bears Saint George's cross: a red cross on a white field;

The flag of Scotland forms the bottom layer of the Union Flag. Over Saint Andrew's white cross, the red cross of Saint Patrick is superimposed, on top of which is a white-bounded red cross of Saint George.

Now that is a world of difference. A caption pre-supposes that one can also perceive the object being captioned (that is, put into context); just as a TABLE without a summary pre-supposes that one can also perceive the data sets being table-ized.

Just as the contents of the summary attribute can be reused to provide a visual rendering of the summary's contents, so too can a LONGDESC be yanked into an IFRAME (not my preference) or embedded as an OBJECT by the browser, so as to replace the image inline. (Note: the browser should offer at least the following choices: show images, show LONGDESC, show ALT text, but both ALT and LONGDESC should be available whether image loading is turned on or off, something over which, in a locked-down setting, the user may have no control)

LONGDESC, would, perhaps, have more mainstream support if the attribute used to point to a long description was HREF and not LONGDESC -- even HREFDESC would have been a more implemented iteration of LONGDESC as it is defined in HTML 4.01 (where hrefdesc is an attribute such as hreflang)

The unquestioning bending to the marketplace's will, by claiming that, since LONGDESC is not widely implemented, it should be deprecated, when it must be remembered that one of the major reasons it is not more widely supported by mainstream apps, is due to simple "market realities" -- there aren't enough of us who need LONGDESC and summary to market to, and therefore, any additional work that would inherently increase the accessibility of the product isn't needed or is assumed to be exclusively a third-party slash assisstive technology's responsibility.

Every day you age, your eyesight becomes a little less sharp than it once was, and if you survive to a ripe old age, you, too, may be dependent upon summaries for tables and long descriptions for graphical objects...

source: Gregory J. Rosmaita post to public-html, 24 June 2007

Usefulness of LONGDESC in the Digitization of Books & Historical Works

LONGDESC is indispensable for anyone attempting to perform serious academic work via the web. Increasingly, colleges and universities are incorporating online ciriccula into all aspects of learning -- on campus, off-campus, long-distance, etc. In many jurisdictions, this means ensuring equal access to all course content - consult: Policies Relating to Web Accessibility

What follows is an example drawn from real life:

When encountering a portrait of Lord Cornwallis, it isn't sufficient to simply caption the image "Portrait of Lord Cornwallis, ca. 1774" -- the student of the subject needs to know precisely how Lord Cornwallis is portrayed -- how old was he at the time of the portrait? what kind of hairstyle does he sport? What type of uniform? What do the buttons on the uniform signify? What is his rank, based on the eppalettes? What are the items that are included in the portrait, particularly those held by, or within reach of, the portrait's subject, for all such items have both symbolic and highly specific meanings, all of which the painter assumed would be understood by the viewer.

Any reference material worth its weight in bytes must include LONGDESC so that the specifics of the image can be conveyed as completely and as thuroughly as would a careful, informed study of the actual portrait.

source: Gregory J. Rosmaita, post to public-html (24 June 2007)

Monika Trebo

I think the fact that something potentially useful (in the case of the longdesc for people with special needs) is not widely used or not used properly, should not be a reason to abandon it. Validation is not used widely either, to my knowledge about 95% of html out there is invalid, and none of us would consider dropping it.

The longdesc may not be used because people don't know about it and it's proper use. Why don't we come up with a brief explanation eg. as part of the "Tips for Webmasters".

An HTML editor which is widely used at Stanford prompts users to enter alt and longdesc when inserting images etc. It is an accessibility issue.

Source: post to public-html 22 June 2007


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)


Implementations

Strategies for Exposing LONGDESC

The first thing a screen-reader, or other assisstive technology, must do when it discerns the presence of a longdesc target is: alert the user that it is there.

The second thing a screen-reader or other assisstive technology must do when it discerns the presence of a longdesc target is to allow the user to activate that target, if that is the user's wish, so as to expose the contents of the longdesc document. Ever since it began to support longdesc, JAWS for Windows alerts the user to the presence of a long description, and prompts the user (in basic mode) to hit ENTER, and the contents of the longdesc document associated with the image is displayed in a pop-up window (not the best solution when the default for a lot of programs these days is block all popups) and the User Agent Accessibility Guidelines (UAAG) strongly discourages the opening of new browser instances without warning the user that it is about to do so, and without the option of opening in a new tab or in the viewport of the original document.

The last thing that needs to be done is to provide a mechanism to return to the document in which the described image is embedded.

Obviously, Step 1 is the responsibility of the assisstive technology, but the under-the-hood mechanics of exposing descriptive content SHOULD be the user agent's responsibility; This issue is directly addressed in UAAG Guideline 2, Checkpoint 2.5 -- a Priority 1 checkpoint

What is needed, therefore, is a normative list of recommended/expected actions that allow multi-modal interaction with the long description.

Treating LONGDESC as HREF isn't the only means of exposing the content of the long description page; the contents -- or the main portion thereof -- could be rendered inline instead of the image or in an IFRAME (which has its own accessibility issues) or any other number of means of exposure.

The key is that the UA should support LONGDESC natively, and allow the user a set of choices about exposing LONGDESC:

  • expose in new browser instance
  • expose in new browser tab
  • expose inline (insert content as object)
  • expose inline through the use of IFrame
  • expose the contents of the longdesc document in a side-bar, aligned with the image it describes

and there are many other options, provided a user knows what to do when encountering a long description, then it matters not what assisstive technology she is using, for there is an expected action in the case of browser x for exposing LONGDESC

source: Gregory J. Rosmaita, post to public-html (24 June 2007)


Research

Existing Support for LONGDESC

Here is some actual data on the state of support for LONGDESC:

Further Reasearch

Possible places to look for additional use cases and examples:


Examples

Simple Longdesc Examples

  • Test Results for Sander's Test of UA Support for LONGDESC
    1. using JAWS8 (version number: 8.0.2107) and MSIE7 (version number: 7.0.5730.11) on a WinXP Pro SP2 box, the longdesc is identified as available ("press enter for long description"), but when activated, simply causes a new browser instance to be generated, containing the entire contents of the original page (JAWS' clunky mechanism for exposing the target of a longdesc) ; i had to use JAWS' "List of Graphics" to access the UK Flag icon's longdesc, as it was not included in the tab-order.
    2. using JAWS8 (version number: 8.0.2107) with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4, JAWS identified the graphic as having a longdesc ("press enter for long description"), but doing so results in NO change of viewport, nor the opening of a new browser instance (JAWS' clunky mechanism for exposing longdesc); i had to use JAWS' "List of Graphics" to access the UK Flag icon, as it was not included in the tab-order.
    3. using JAWS8 (version number 8.0.2107) with Lynx32 (release 2.8.6rel.1 libwww-FM/2.14FM SSL-MM/1.4.1 OpenSSL/0.9.8d) the UK flag was identified as a graphic; when "Show Images" is set to "as links", the link defined for the UK flag links directly to the raw icon (in GIF format) without either indicating, exposing, or enabling the exposure of LONGDESC

More Complex Longdesc Examples


Diagram Examples

The CSS 2.1 Specification provides long descriptions of the diagrams. The box dimensions diagram has an associated long description. The spec uses "[D]" links beside each image.


Photography Examples


Screenshot Examples

Example based on Hixie's Mini FAQ About the Alternate Text of Images:

  • Image: Screenshot of dialog box from Netscape Communicator 4.x
  • Alternate text: The proxy settings dialog box has 'proxy.i.edu' in the 'host' field and '3128' in the 'port' field for every protocol.
  • Title: Screenshot showing Communicator 4.x Proxy settings for Indianapolis campus.
  • Long description: The image depicts the Proxy Settings dialog box for the Communicator 4.x application as it is set for the Indianapolis campus. The dialog box has four rows of edit boxes, labelled HTTP, FTP, GOPHER and HTTPS. Each row has two edit boxes, aligned in two columns, with the labels 'host' and 'port' at the top. Each 'host' field has the content 'proxy.i.edu' and each 'port' field has the content '3128'.

Email

June 2007

Thread: Rationale for Preserving LONGDESC

Thread: Usefulness of LONGDESC & the Digitization of Books & Historical Works

Thread: Exposing LONGDESC

Thread: LONGDESC Wiki Page

Thread: LONGDESC: some current problems and a proposed solution added to the wiki

July 2007

Thread: LONGDESC: some current problems and a proposed solution added to the wiki


See also