W3C home > Mailing lists > Public > public-html-a11y@w3.org > April 2011

Re: longdesc (was Re: minutes: HTML Accessibility Task Force Weekly Call 2011-03-31 [draft])

From: Laura Carlson <laura.lee.carlson@gmail.com>
Date: Tue, 5 Apr 2011 16:14:46 -0500
Message-ID: <BANLkTi=oJLDonYrz1XmcgSPkDLF_L0s_Uw@mail.gmail.com>
To: Steve Faulkner <faulkner.steve@gmail.com>, Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>, Janina Sajka <janina@rednote.net>, Sam Ruby <rubys@intertwingly.net>, Paul Cotton <Paul.Cotton@microsoft.com>, Maciej Stachowiak <mjs@apple.com>
Cc: HTML Accessibility Task Force <public-html-a11y@w3.org>, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Hi Steve and all,

Thank you very much for your reply.

> my understanding and thoughts:
> 1.the html task force seek to have an agreed position on longdesc in a
> short time frame

That would be good.

I think we will have until sometime in May before the Chairs call for
counter proposals. Sam, Paul or Maciej Is this correct? When is the
soonest that the Chairs will call for Issue 30 counter proposals?

But if we could come to consensus with the full working group before
that, it would be great.

Leif's reply to you, Steve, seemed to say that Task Force
Recommendations did not seem to make a difference in the outcome of
the table summary decision. This is also true in the previous longdesc
decision. But it can't hurt to have a Task Force endorsement. It would
be a good thing.

> 2. continuing to refine/change/update the extremely detailed change proposal
> Laura has developed means that it is difficult to achieve agreement as
> nobody is sure what they are agreeing to

Spec text, Steve. Spec text.

When all is said and done, what will go into the spec, is what people
agree to or don't agree to.

However, that spec text requires rationale.

> 3. What the HTML wg chairs require when they reconsider this issue is [1]:

Actually the Chairs said, "This issue can be REOPENED if new
information come up". This has already happened. The issue has been
REOPENED based on the use cases we supplied.

> 4. due to the requirements above any change proposal should concentrate on
> providing such evidence.

Yes. That is what we have tried to do. How would you propose to
condense the evidence? We could simply link to much of the info as it
is on the research page, such as:

Guidelines, Laws, Policy, and Standards

Tools (Browsers, Assistive Technology, Authoring Tools, Other Tools
Supporting Longdesc)

Would that help? Most of the links were taken from the research page.

The chairs decision also pointed out that longdesc is:

* relevant only to a fraction of images
* use, even among those pages, is relatively limited
* current usage often contains bogus values
* more work is needed to make longdesc useful
* alternatives exists (explicit links, aria-describedby, figure captions)
* external content adds a maintenance burden (likely to get out of sync)

Janina in particular said that we need clear rebuttals for existing
alternatives such as figure and aria-describedby. Janina, have you
changed your mind on that? Since you pointed this out quite a few
other drop-in replacements have been proposed. That is why we have the
extensive, "Suggested Alternatives Are Not Viable Solutions" section
in the Change Propsal.

HTML working group members such as Ted and Jonas are under the false
impression that longdesc is not required because of aria-describedby
and other mechanisms.

Today's table summary decision reinforces this type thinking. The
Chairs said, "we infer that aria-describedby is more general purpose.
Lacking use cases that clearly require the more specialized purpose
[@summary] described here, or an explanation of the operational
problems that adopting a more general purpose element would cause, we
find this objection not to be strong."

>From that it seems that in the Chairs judgment, general-purpose
attributes such as aria-describedby are preferred over specialized
attributes unless there are extenuating circumstances. Sam, Paul, and
Maciej, is that a correct interpretation?

> the proposal should be succinct as is possible so
> as not to drown out the new evidence.

That do you propose making it more succinct? We could remove the
references and link to all of that info. The research page is the
source for all of that.

Related Articles and Blog Posts

Other Studies

HTML5 Issue (Tracker Issue, Bugs, Requirements, Recommendations,
Proposals, Working Group Poll and Chairs' Decision, Meeting Minutes,
Formal Objections

> 5. we should not seek at this time to expand the scope of what is required

Steve, I think "at this time" is key here. We should not *prohibit*
future possibilities either. The title and heading of the copy/fork
sure seems to do that.

> which is i believe:
> A feature that provides an explicit and unambiguous method of associating an
> image with a description of the image.

Let us think this through carefully and all it implies. Again, ruling
out longdesc on other elements could be detrimental per the Chairs
decision today. If it possible longdesc could help other elements why
lock that door?

> 6. From discussions at the San Diego face 2 face we should attempt to
> achieve consensus on it NOT being a requirement that  longdesc only be
> available to users of AT. In discussions with the developers of NVDA, what
> they do not want is to implement an AT only method of access, they want the
> browsers to provide the functionality.

That would be terrific.

> 7. in regards to the above i would suggest that recommending browsers to
> implement longdesc in a way that can be available to any user will solve
> many of the problems that are perceived as being part of longdesc, while not
> taking away the essential capability of longdesc to be an "unambiguous
> method of associating an image with a description of the image"

An very important designer requirement is to respect a web page's
visual design and have no *forced* visual encumbrance. This can be
achieved with implementations like tellmemore. I think this could be
worked out with some combination of our two spec text examples.

> If we can agree on the points above I think a change proposal that
> encapsulates the above could be produced in short order.

Working together we should be able to condense the document. I eagerly
await specific advice.

Steve, are you opposed to Leif's idea of having in the spec text that
encourages tools to inspect the URL and issue a warning if they
suspect that the description resource is unlikely to contain a
description of the image? It could help address the points brought
forth in the "longdesc lottery".
Do you think it would help make longdesc less error prone? I don't
know of a tool that checks longdesc.  Henri said it would be trivial
to incorporate some checks into his validator.

Benjamin, you mentioned link checkers on public-html.
I use http://validator.w3.org/checklink regularly. I have never gotten
it to check longdesc links. Does it do that? Do you know of tools that
checks longdesc links? What do you think is the best way to go about

Thanks, everyone.

Best Regards,

Laura L. Carlson
Received on Tuesday, 5 April 2011 21:15:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:54 UTC