Bug 10448 - Support Longdesc atribute at img element
: Support Longdesc atribute at img element
Status: NEW
: WebKit
WebKit Misc.
: 420+
: Macintosh Mac OS X 10.4
: P4 Enhancement
Assigned To:
: http://pt914086236.googlepages.com/ex...
:
:
:
  Show dependency treegraph
 
Reported: 2006-08-16 15:23 PST by
Modified: 2013-03-25 08:54 PST (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2006-08-16 15:23:50 PST
<img longdesc="xxx.htm"...>

Why we don't have any browser support this atribute? It is refered at WCAG 1.0 of W3C dated from May 5, 1999, but 7 years after we don't have browsers that support it?

It is possible put it at SAFARI?
------- Comment #1 From 2007-07-02 06:21:56 PST -------
Please describe what kind of support for LONGDESC you would like to see, and why. Some implementation options could be:
- adding a link to context menu;
- implementing a property inspector for end users, similar to Firefox one;
- displaying a link in addition to ALT text if image loading is disabled;
- never displaying it, but using it in VoiceOver.

Many people think that this attribute does not really help accessibility, and it may be even removed from future versions of HTML altogether. So, we need very specific use cases to handle this issue with high priority.
------- Comment #2 From 2008-02-25 23:40:10 PST -------
My idea is to handle the longdesc in some way simmilar to the "media control" by overlaying the image with an info button- instead of an play button - when the mouse enters. When pressing the button a "legend" - with the contents of the longdesc - should become visible below the image.
------- Comment #3 From 2008-02-26 13:51:10 PST -------
(In reply to comment #2)
> My idea is to handle the longdesc in some way simmilar to the "media control"
> by overlaying the image with an info button- instead of an play button - when
> the mouse enters. When pressing the button a "legend" - with the contents of
> the longdesc - should become visible below the image.
> 

Hi. I just remember that the content of longdesc is an html file. Maybe you could opt to do something that we use in accessibility to serve the browsers that don't support the longdesc attribute. We use the redundant link - D. Take a look at the logos and link D at www.umic.pt
------- Comment #4 From 2008-02-26 13:54:03 PST -------
(In reply to comment #3)
> (In reply to comment #2)
> > My idea is to handle the longdesc in some way simmilar to the "media control"
> > by overlaying the image with an info button- instead of an play button - when
> > the mouse enters. When pressing the button a "legend" - with the contents of
> > the longdesc - should become visible below the image.
> > 
> 
> Hi. I just remember that the content of longdesc is an html file. Maybe you
> could opt to do something that we use in accessibility to serve the browsers
> that don't support the longdesc attribute. We use the redundant link - D. Take
> a look at the logos and link D at www.umic.pt
> 

Sorry. My idea is: maybe you could put the browser doing the link D automatically from the longdesc.
------- Comment #5 From 2008-02-26 14:05:08 PST -------
How to describe things like that:
http://www.acesso.umic.pt/estudos/acess2003.htm .

The alternative equivalent is important in wcag1.0 and wcag2.0. 
------- Comment #6 From 2012-03-12 22:14:21 PST -------
(In reply to comment #1)
> Please describe what kind of support for LONGDESC you would like to see, and why.

Chrome features and basic link behaviour - iCab-inspired:

* On control-click: Be available in context-menu.
* On hover: Display cursor that indicates presence of description link.
  [ If wrapped inside a link or if @title is non-empty, then the long
    description cursor must become more intricate or be suppressed by
    the the link or non-empty-title cursor. ]
* On activation: Open URL, as if target=_blank was specified, in new
  window/tab/context, so that the user can just close the longdesc
  context  in order to be back at the same location on the page,
  where he/she was when the link was activated.

CSS features:

* Except when image loading is disabled, the longdesc link is only
  rendered in the chrome - and not in the page.
* When not visually rendered, the image must thus be activated via
  VoiceOver or via contextual menu.
* When rendered visually, the link could be rendered as a symbol or
  image and should behave as a focusable link. [To VoiceOver users
  the behavior should probably not be affected by whether the link has
  visual rendering or not.]
* Generated content could be used to render the link [Idea taken from
  Steve Faulkner.] 
* When image loading is disabled:
  # Display as a link, before ALT text. Perhaps use the fallback image
    as a link, and just change its shape and color to indicate this?
* When image loading is enabled: 
  # No visible indicator is shown by default. However, authors and
    browser users can use CSS or preferences to enable a clickable
    indicator that occurs outside or above the image.

Keyboard accessibility:

* For VoiceOver users, see next section, below.
* For GUI users:  The longdesc link should be keyboard accessible
  - focusable - but this should rely on the generated content
  version of the link being visible.
  Hence, focusability should automatically step in if the image *isn't*
  loaded. Or if the link is specifically made visible via CSS.
  This is just like how focusability/tabbing general works: If the
  element isn't displayed, then it can't take focus.
* Tabbing order: it should be the same as for the <img>, if it has
   one, but actually take place just *before* the <img>.
* If one tries the contextual menu on such a longdesc hot-spot,
   then the user should probably get the <img>'s usual context
   menu.
* If the user hovers above such a visual longdesc hotspot, then
  the status bar etc, should display the URL.

VoiceOver features:

* *before* reading the @alt text: Announce that it is an image, and
  that it has a description link. Example announcement: ''Described
  image. Press [some key  e.g. Tab] to treat it as a link.''
  # Then proceed to read the image's alt text as normal.
  # If reader presses the key, then switch to presenting the alt text
    as a link  and allow the user to follow the link in the 'normal' way,
    when and if the users wants. 
* if the user chose to open the longdesc context, then, when closing
  the context, VoiceOver should probably behave as if the alt text of
  the image had been presented - even if actually did not read
  everything because the user pressed the link early - and move to
  present next element.

  NOTE: Why announce the description link before reading the alt text? Well, in JAWS, the longdesc opportunity is announced *after* the alt text has been read. But this comes as a surprise to the user, when he has listened to all the alt text - with possible negative attitude as result. It seems better to make the user aware of it from the start. Also, in case the user wants to primarily read the long description, then it is probably not satisfying to have to wait for the entire alt text to be read before being given this opportunity.

Features when image is wrapped inside link:

* Code example: <a href=l><img longdesc=d src=s alt=a></a>
* When longdesc URL and link URL are DIFFERENT:
  # VoiceOver to say:'Link with described image.Press [key] for image.'
    - Then VoiceOver reads link as normal.
    - If key gets pressed: Treat image as 'described image', see above.
  # GUI implementation - when image is not loaded: 
    - the fallback image becomes an extra link, outside and before 
      the textual link.
  # GUI implementation - when image is loaded and CSS to make it
    display is *not* enabled: Nothing special happens.
  # GUI implementation - when image is loaded and CSS to make it
    display *is* enabled: a clickable link outside and above image.
    NOTE: for GUI, this happens regardless of whether the two URLs are
          identical or not.
* When longdesc URL and link URL are THE SAME: 
  # In this case, the link URL is probably meant as a long description
  link. Hence, unless the image ha a non-img @role, then VoiceOver
  should treat the image as a image with a longdesc and not as a link.
  While GUI Webkit should make no difference.
  # ADVANTAGE to VoiceOver users: Longdesc becomes a signal of the
    link's role - it 'demotes' role of the link from link to
    description link. Currently it is a problem, in VoiceOver, that
    linked images are treated as links - the user doesn't get to know
    that it is an image.

Use cases:

* The EPUB usecase: http://diagramcenter.org/development/epubdescribedat.html
   E-pub readers seem to be starting to get longdesc support - possibly under another name on the attribute: <http://lists.w3.org/Archives/Public/public-html-a11y/2012Mar/0090>. Relevant in that regard, is that  EPUB3 is just HTML5 with some extra 'stuff', and that there are services, such as ibisreader.com, that allows you to read your EPUB books as Web pages. Unless there is a HTML feature, then this functionality can't be expressed.

* Laura Carlsson's use cases:
  http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc#Use_Cases
------- Comment #7 From 2012-11-27 12:02:13 PST -------
*** Bug 98021 has been marked as a duplicate of this bug. ***
------- Comment #8 From 2013-03-25 07:49:10 PST -------
(In reply to comment #1)
> Please describe what kind of support for LONGDESC you would like to see, and why. Some implementation options could be:
> - adding a link to context menu;
> - implementing a property inspector for end users, similar to Firefox one;
> - displaying a link in addition to ALT text if image loading is disabled;
> - never displaying it, but using it in VoiceOver.
> 
> Many people think that this attribute does not really help accessibility, and it may be even removed from future versions of HTML altogether. So, we need 
> very specific use cases to handle this issue with high priority.

longdesc is a valid HTML5 attribute.

HTML Image Description Extension Draft Published 
http://www.w3.org/News/2013.html#entry-9756

The W3C validator http://validator.w3.org was updated last week to support the longdesc attribute as specified in http://www.w3.org/TR/html-longdesc/

As for support innovative browser vendors and developers provide ways that make longdesc discoverable:
http://www.d.umn.edu/~lcarlson/research/ld-ua.html

Please fix this bug. Thank you.
------- Comment #9 From 2013-03-25 08:54:55 PST -------
From the spec:

"
User agents should make the link available to all users through the regular user interface.

User agents should expose the link to relevant APIs, especially accessibility-oriented APIs.

User agents should enable users to discover when images in a page contain a long description.
"

3. The longdesc attribute
http://www.w3.org/TR/2013/WD-html-longdesc-20130312/#longdesc