Re: example spec text for longdesc

Hi Henri,

Thank you very much for your reply.

On 3/30/11, Henri Sivonen <hsivonen@iki.fi> wrote:
> On Fri, 2011-03-25 at 07:48 -0500, Laura Carlson wrote:
>> >> And
>> >> how difficult would it be for conformance checkers to issue errors if
>> >> the longdesc URL has certain file suffixes, such as .gif, .jpeg, .png
>> >> etc.)?
>> >
>> > Easy though bogus as far as the theory of URLs go. (In theory, you
>> > should deference the URL and check the content type, but that would make
>> > conformance dependent on external resources, which is kinda
>> > undesirable.)
>>
>> Do you think that it would be a good idea for the spec to have
>> language for conformance checking tools to do such checks if longdesc
>> is reinstated into HTML?
>
> I think making machine-checkable conformance a property of the HTML file
> (and the protocol headers it was supplied with) makes the concept more
> tractable than making machine-checkable conformance depend on the
> external resources the HTML file refers to.

How is it more tractable? Could you explain this further?

> That's why if longdesc were
> reinstated, I wouldn't want to make its machine-checkable conformance
> depend on external resources However, if we find a that other features
> have extremely compelling reasons to have their machine-checkable
> conformance depend on external resources, then we might as well make
> the machine-checkable conformance of longdesc depend on external
> resources, too.

Are you saying that machine checking wouldn't help authors improve
their chances of getting longdesc right?

>> Use cases are at:
>> http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc#Use_Cases
>>
>> What are appropriate way to solve the formal use cases?
>> http://www.d.umn.edu/~lcarlson/research/ld.html#uc
>
> I get the feeling from the stated use cases that they are reverse use
> cases that are made to fit longdesc rather than a list of use cases
> identified as blind users having.

They are author use cases based on several months of investigation.
Indeed they were written after the chairs said in their decision that
that no use cases were supplied. Some are based on current examples in
the wild. Some are based on future growth like the etext use case.
Some are from my own experiences. They reflect sincere and genuine
needs.

> In particular, merely "reinstating" longdesc would presumably allow it
> on <img> but not on <svg>.

We certainly could consider adding longdesc to other elements.

> SVG graphic that's inline in a HTML document is appropriate and
> sufficient, what reason is there to insist on a mechanism that's
> designed to point to external description resources other than
> rationalizing the design that was already in HTML4?

There are quite a few reasons.
http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc#Conclusion:_longdesc_Should_be_Included_in_HTML5

> Note that the generality of being able to refer to external descriptions
> poses problems: If longdesc is implemented as a link that navigates to a
> different page, reading the long description becomes as disruptive to
> the flow of reading the page as following a link.

Screen readers users can to control how they interact with the
longdesc. They can choose to follow the link or not.

> On the other hand,
> implementing support in-reading-flow external descriptions would involve
> the problems of dealing with the situations such as accessibility APIs
> expecting more-or-less synchronous availability of the description but
> the description not yet having been fetched from the network. (Regarding
> your other question about using longdesc with a fragment identifier:
> That scenario also has this problem.)

Do you mean that activating a link might take too long?

> Furthermore, if the summary attribute is considered sufficient (I'm
> again referring to what JF replied to Jonas) for describing tables, why
> is even flattening to a plain string considered a problem?

I disagree with John here. The summary attribute is for a short
description not a long description. For more info visit:
http://juicystudio.com/article/purpose-of-the-summary-attribute.php

A long description could conceivably be provided by longdesc. It could
also be used on other elements if deemed appropriate.

> Also, it's worthwhile to consider if use cases such as long descriptions
> for logos are worth addressing, because when site development resources
> are limited (and they always are), the time the site author uses to
> write a description about a logo could instead be used for accessibility
> enhancing tasks that have a higher impact on accessibility.

Some sites are conscientious enough to provide them and some users do
appreciate them. I have an art and photography background and some of
my friends have and my first photography teacher did become blind. I
consider it an important use case.

Thanks for your insights and sharing your expertise, Henri. I
appreciate it very much.

Best Regards,
Laura

-- 
Laura L. Carlson

Received on Wednesday, 30 March 2011 16:59:58 UTC