You need to
before you can comment on or make changes to this bug.
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?
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.
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.
(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
(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.
How to describe things like that:
The alternative equivalent is important in wcag1.0 and wcag2.0.
(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.
* 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
* 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.
* 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
* If the user hovers above such a visual longdesc hotspot, then
the status bar etc, should display the URL.
* *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.
* 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:
*** Bug 98021 has been marked as a duplicate of this bug. ***
(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
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:
Please fix this bug. Thank you.
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