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

Re: example spec text for longdesc

From: Henri Sivonen <hsivonen@iki.fi>
Date: Wed, 30 Mar 2011 12:34:03 +0300
To: HTMLWG WG <public-html@w3.org>
Message-ID: <1301477643.2514.200.camel@shuttle>
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. 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,

> > In any case, approaching longdesc from the point of view of ease of
> > conformance checker implementation is the wrong way to approach it.
> > Frankly, all this seems to presume that longdesc must axiomatically be
> > preserved and then rationalizations are sought to justify the
> > conclusion.
> >
> > The right way is to consider what problems users face and what are
> > appropriate ways to solve those problems--not to focus on the
> > preservation of something that has been labeled as an accessibility
> > feature.
> 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. Kinda like writing a job posting or
the requirements for a purchase with a certain person or product in mind
in order to hack around corporate or government hiring or procurement
rules. (Consider
http://www.robweir.com/blog/2007/01/how-to-hire-guillaume-portes.html )

In particular, merely "reinstating" longdesc would presumably allow it
on <img> but not on <svg>. Yet, we should except inline SVG to be used
more and more for logos, cartoons, charts, illustrations and
(eventually) email banners. John Foliot mentioned <desc> in another
(http://lists.w3.org/Archives/Public/public-html/2011Mar/0626.html), but
if we agree that including a description inline inside <desc> inside an
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?

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. 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.)

OTOH, if <desc> is good for SVG, logically aria-describedby pointing to
an in-page description (possibly hidden from visual presentation) should
be good for bitmaps. (At least if aria-describedby is changed not to
flatten what it points to into a string when the UA/AT combination
manages to handle <desc> without flatting it.)

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?

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.

Henri Sivonen
Received on Wednesday, 30 March 2011 09:34:44 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:34 UTC