RE: example spec text for longdesc

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

As Jonas Sicking noted, this is software, we can do anything 
(http://lists.w3.org/Archives/Public/public-html/2011Mar/0627.html). I 
personally would not be opposed to allowing @longdesc to be a valid 
attribute of <svg> - unless there were real *technical* (as opposed to 
philosophical) reasons not to.

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

Is not one of the stated goals of HTML5 to retain backward compatibility? 
How many times/articles/presentations/instances have we been told that 
moving towards HTML5 is as easy as changing your doctype from:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 
Strict//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

...to:

<!DOCTYPE html>

...and voila you are authoring HTML5? (I can do that research if you really 
want <grin>)

The fact is, @longdesc today is a perfectly valid if under-used attribute in 
both HTML 4.01 and XHTML 1.1, so it would seem that any validator that was 
created to validate *all* web content would already be checking for and 
validating instances of @longdesc, else that tool be incomplete.

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

Henri, who has stated that this is a problem? Using this line of reasoning, 
we should not insert hyperlinks on words or phrases mid-sentence, for fear 
that users will miss out on the complete sentence, or that their 
user-experience will be compromised. This is (frankly) ridiculous.

The ability to (mentally and literally) pause, step outside of the page flow 
to get a description of a complex image (because you cannot see it) and then 
return to the content flow AT EXACTLY THE SAME PLACE YOU LEFT OFF is a 
design feature, not a flaw. The key point about @longdesc (for screen 
readers) is that they are given a *choice* as to whether or not they want to 
hear what some might consider extraneous data or not - it is the difference 
between glancing at a sophisticated pie chart (for example) versus studying 
it. You, as a sighted user, have that choice (to glance or study), yet 
insisting that the full-on textual description be inserted into the content 
flow because the user is blind is tantamount to me holding your head in a 
fixed position and insisting that you explain aloud to me that pie chart 
before I allow you to continue reading the rest of the page.

@longdesc is about user-choice!


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

Flawed assumption results in a flawed conclusion.

That said, I have listened (carefully) and heard that for some *sighted* 
users (who might want to have access to those longer textual descriptions, 
for whatever their reason), this jumping from one 'page' (tab/window/etc.) 
to another *might* degrade their user experience.

OK, fair enough. So I asked a buddy of mine to help me address that 
'problem', and, using jQuery *today*, and some XHR you can load the content 
of the longdesc.html document into the bounding box of the complex image. 
(Unless XHR is also evil and delivers a poor user experience, which would be 
a new assertion to me). See: 
http://blog.ginader.de/dev/jquery/longdesc/examples/webaim/index.php

Is this perfect? I don’t know, but those who have seen it agree that it is 
kind of clever, and illustrates a real way that GUI based user-agents could 
deal with this "problem". Something like this could be a native feature of 
the browser, with a global user-setting to toggle this kind of functionality 
on or off. Why not? "This is software, we can do anything."

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

Huh? (That last parenthesized sentence makes no sense to me).

So what you are suggesting is that we re-open the ARIA CR Spec. and change 
aria-describedby to become essentially @longdesc by another name (except 
that it cannot point to an external URI, only in-page content inside a div 
{position:absolute; left:-999px; top:-999px;} because, uhm XHR is evil?), 
just so that we can abandon @longdesc?  In my "Rant" over the weekend, I 
noted the following, which I will repeat now:

 "ARIA is intended to only affect accessibility API mappings (and
thus ATs). Features such as alt="", however, are relevant far beyond AT
users, for example to text browsers. It would be wrong, therefore, to make
solutions that exclusively affect accessibility APIs be a suitable
alternative for solutions that are necessary for UAs that do not use
accessibility APIs."
- Ian Hickson
http://lists.w3.org/Archives/Public/www-archive/2010Mar/0029.html

Yet one of the complaints we've repeatedly heard is that the text contained 
in the page pointed to by @longdesc might be useful for sighted users as 
well, that longer descriptions benefit more than just those who are blind 
and using screen readers (AT), but that because there is no visual 
indication that @longdesc content exists, it fails those users. It also 
perpetuates the "black data" argument, because sighted authors won't see 
their <strike>longdesc</strike> <ins>aria-described*</ins> efforts.

My question then becomes, which is it?

What do those who feel @longdesc is fatally flawed want? If you accept that 
the need *does* exist (does anyone want to argue that the need doesn't 
exist?), then what is the solution? If @longdesc content is exclusive to AT 
users, then sure, we can go through the painful exercise of completely 
redefining @longdesc as an aria attribute (which will do EXACTLY THE SAME 
THING that @longdesc does today, with the BONUS of breaking backward 
compatibility), but then we can't keep hearing from detractors that this 
type of content is useful for non-AT users as well.  If, conversely, this 
type of content *is* of use to users beyond AT-users, then we should not be 
pushing it to ARIA to solve - it should be, as Ian states, more robust; thus 
we retain @longdesc and fix browser implementations of that attribute. You 
can't suck and blow at the same time friends.


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

Because the intent of @summary is to explain textual data and basic 
structure succinctly before diving into it - you have experienced table 
navigation with screen reader technology right? It isn’t pretty.

@longdesc does something different, it describes, in text, what sighted 
users see as a graphical image. The two functions are significantly 
different.

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

Sorry Henri, I'm going to call Bovine Excrement on that one.

In a tangentially related but private email yesterday, I wrote a "longdesc" 
for the following poster image:
http://popculturefan.com/a-clockwork-orange-poster.jpg

The long description was:

The film's protagonist, Alex (played by Malcolm McDowell) is brandishing a 
knife while peering through a cutout of a stylized "A" or inverted "V". An 
eyeball appears floating at his wrist. The poster also reads "Being the 
adventures of a young man whose principle interests are rape, ultra-violence 
and Beethoven", as well as bold psychedelic type below the image which reads 
"Stanley Kubrick's Clockwork Orange".

Footer text reads "A Stanley Kubrick Production - A Clockwork Orange 
starring Malcolm McDowell, Patrick Magee, Adrienne Corri and Miriam Karlin. 
Screenplay by Stanley Kubrick. Based on the novel by Anthony Burgess. 
Produced and Directed by Stanley Kubrick"

Total time to write that? 2 minutes. It will take you about as long (or 
longer) just to reply to this email (should you choose to reply to this 
email), so that argument holds absolutely no water what so ever.

JF

Received on Wednesday, 30 March 2011 16:28:34 UTC