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

Re: example spec text for longdesc

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Wed, 30 Mar 2011 16:54:57 +0200
To: Henri Sivonen <hsivonen@iki.fi>
Cc: HTMLWG WG <public-html@w3.org>
Message-ID: <20110330165457244835.11c18b04@xn--mlform-iua.no>
Henri Sivonen, Wed, 30 Mar 2011 12:34:03 +0300:
> On Fri, 2011-03-25 at 07:48 -0500, Laura Carlson wrote:

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

> 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?

* SVG graphics can have two elements, <title> and <desc>. 
* SVG in XHTML permits elements in non-SVG namespaces, such as the 
XHTML namespace, inside <desc> - may be John did not consider that 
HTML5 does not allow this? Thus, in XHTML, one may even place an HTML 
anchor element inside <desc> - to link to a description. I don't know 
why you did not allow something like that in SVG.
* It is even possible to have an <a> inside the <svg> - and an <a> in 
HTML namespace around the SV. (But I guess this is just a bug in your 
validator ... don't think HTML5 permits this, as foreign content is 
considered interactive by HTML5)

Further more the SVG element itself belongs to another namespace - thus 
we cannot freely add @longdesc to it. There clearly is little need for 
@longdesc on <svg> in XML/XHTML. But, of course, HTML5 has become 
another cup of tea. 

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

As as been said many times before, most or all @longdesc 
implementations opens the link in a new window  - as if it had 
target="_blank. This minimizes the disruption as closing the window/tab 
takes you back to were you was.

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

The way @longdesc is implemented, it does not create the expectation 
that the description is on the same page. It creates the expectation 
that it is a link that must be actively opened by the user. Even when 
it *is* on same page.

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

Does "unflatten" also include opening it interactively, like @longdesc?

"If another working group change @aria-describedby completely" doesn't 
sound like something to build a spec on.

> 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?

We in this moment run/ran a Poll were a <summary> element is - 
literally - on the table.

But apart from that poll, why don't you ask the same about @alt? It too 
is "flat". 

Flat is both a feature and a limitation. There is not, I believe, very 
much need for a link as part of @summary/<summary>. But there is a need 
to link from a diagram image to a table etc.

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

@longdesc is simple to use. Doesn't take much resources - hardly a 
consideration. 

Leif Halvard Silli
Received on Wednesday, 30 March 2011 14:55:33 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:23 UTC