- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Wed, 30 Mar 2011 12:34:03 +0300
- To: HTMLWG WG <public-html@w3.org>
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, too. > > 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 message (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 hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Wednesday, 30 March 2011 09:34:44 UTC