W3C

List of comments on “HTML5 Image Description Extension (longdesc)” (dated 16 July 2013)

Quick access to

There are 5 comments (sorted by their types, and the section they are about).

question comments

Comment LC-2843
Commenter: Andrew Kirkpatrick <akirkpat@adobe.com> (archived message)
Context: 3.0.3 User Agents
Forwarding to HTML A11Y TF per Chaals's suggestion.

Thanks,
AWK

Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe Systems

akirkpat@adobe.com
http://twitter.com/awkawk

http://blogs.adobe.com/accessibility



-----Original Message-----
From: Charles McCathie Nevile [mailto:chaals@yandex-team.ru]
Sent: Thursday, August 22, 2013 6:00 AM
To: Andrew Kirkpatrick
Subject: Re: longdesc extension question

Hi Andrew

(this is a good question, and I would love to have it in public - feel free to forward my response...)

On Wed, 21 Aug 2013 00:57:54 +0500, Andrew Kirkpatrick <akirkpat@adobe.com> wrote:

> Hi Chaals,
> I'm looking at the longdesc extension and also a couple of the WCAG
> techniques and have a question. It seems that a key problem with the
> implementations of longdesc today (well, at least JAWS and NVDA) is
> that when you activate the longdesc feature for an image they load the
> page with the longdesc and start reading at the required place. As
> some people are advocating for same-page references or many longdesc
> descriptions on a single separate page this is a problem because JAWS
> and NVDA don't know where the longdesc stops, just where it starts. As
> a result, a user listening to the longdesc for all three images in the
> following example would hear information about "a" once, "b" twice,
> and "c" three times.
>
> So the question is: Is there anything in the spec that requires that
> user agents read only the content contained within the HTML object
> with the matching id reference?

No, but there is a "should" requirement on authors:

'Authors should put descriptions within an element which is the target of a fragment link (e.g. longdesc="example.html#description") if a description is only part of the target document.'

which is intended to allow for such behaviour.

In general the spec tries to go lightly on requirements for user agents - it was somewhat controversial to require that they actually make the longdesc available to users in the first place ;(

cheers

Chaals

> Sample.html
> <img alt="a" longdesc="descs.html#a">
> <img alt="b" longdesc="descs.html#b">
> <img alt="c" longdesc="descs.html#c">
>
> Descs.html
> <div id="a"><p>This is my longdesc for a</p></div> <div id="b"><p>This
> is my longdesc for b</p></div> <div id="c"><p>This is my longdesc for
> c</p></div>
>
> Thanks,
> AWK
>
> Andrew Kirkpatrick
> Group Product Manager, Accessibility
> Adobe Systems
>
> akirkpat@adobe.com<mailto:akirkpatrick@adobe.com>
> http://twitter.com/awkawk

> http://blogs.adobe.com/accessibility

>


--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
chaals@yandex-team.ru Find more at http://yandex.com
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

general comment comments

Comment LC-2787: JCraig-Examples where longdesc inappropriate
Commenter: James Craig <jcraig@apple.com> (archived message)
Context: 3.0 Implementation
I have an additional suggestion that I believe would help the acceptance of this document within the general working group. Add an informative section detailing several of the many cases where it is inappropriate to use @longdesc. For example…

1. @longdesc is inappropriate when an EPUB footnote is sufficient.
2. @longdesc is inappropriate for Math. Use MathML instead.
3. @longdesc is inappropriate for SVG graphics. Make the SVG DOM accessible instead.
4. @longdesc is inappropriate for graphics of tabular data. Use an accessible table instead.

More examples at http://cookiecrook.com/longdesc/

These should probably be added to the WCAG 2.0 Techniques documents as well.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2788: MTurvey-Additional example longdesc inappropriate
Commenter: Matthew Turvey <mcturvey@gmail.com> (archived message)
Context: 3.0 Implementation
I'd also add:

5. @longdesc is inappropriate when a normal link is sufficient. Example:

<a href="descrip"><img src="pic" alt="*the purpose of the link*"></a>

-Matt
<B6A6F56A-C7A3-4A59-860C-4276A33B2BCD@apple.com>
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

editorial comments

Comment LC-2789: Gmoreau-More cleary define "available" RE longdesc links
Commenter: Guy Moreau <gmyx@gpws.ca> (archived message)
Context: in
In my opinion, 3.0.3 User Agents (UAs) is deficient. While it requires
UAs to make the link available, it arguably does not require anything
more than access to the source code.



My rational is that access to the source code is a regular user
interface. Access to source code is provided in most if not all UAs. The
word 'available' does not specify what we can do with the link or how we
use it.



As a result of using the word 'available', I feel there is nothing in
3.0.3 that would compel UAs to make easy access to longdesc links
possible. I feel it needs to be more prescriptive to UAs that everyone
should benefit from longdescs.



I am suggesting a change or addition:

"If the longdesc value is valid, User agents must make the link
actionable or able to be activated to all users through the regular user
interface(s) similar to regular links."



Choose the wording the best describes how a regular link is activated.



A Non-normative example: Add to the context menu of the image a 'Go to
long description' menu item.



I hope my opinion is clear and my goal is entice UAs to make longdesc
readily available to all users. I also hope that you agree with me.


Thank you.
Guy Moreau
@gmyxgpws (twitter)
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2786: Jan-Editorial-ATAG
Commenter: Richards, Jan <jrichards@ocadu.ca> (archived message)
Context: 3.0 Implementation
Nice work. I just have a few suggestions:

1. Double-check the consistency of capitalization in "Requirements for an Image Description functionality". Some items have each word capitalized while others do not and then some have different capitalization in different places ("Simple Return" ). My preference is usually for less capitalization.

2. re: the section referencing ATAG 2.0 that is marked with " ISSUE: This doesn't seem a great reference - is there anything better? This is tracked in bug 21501 and its dependent bugs. Unless a proposal for improvement is made and accepted this bug will simply be closed after Last Call."

Right now it points to:
" Implementing PRINCIPLE B.3: Authors must be supported in improving the accessibility of existing content " (http://www.w3.org/TR/ATAG20-TECHS/#principle_b3)
...which is probably too general.

There are other anchors in "Implementing ATAG 2.0" that provide more specific information. This is probably the most specific:
http://www.w3.org/TR/ATAG20-TECHS/#prompt-long-description

Also, these two sections that explain how checking and repair can range from manual to fully-automated also include relevant descriptive text examples: http://www.w3.org/TR/ATAG20-TECHS/#checking-types
http://www.w3.org/TR/ATAG20-TECHS/#repair-types

Cheers,
Jan
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Add a comment.


Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: index.html,v 1.1 2017/08/11 06:46:48 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org