non-conforming authoring tools: the backplane of portals, networking & photo sites

aloha, lachlan, ian, et. al.

the point of my pointing the WG to my.opera photo album, was NOT
to display the world's most accessible photo portal site, but to 
underscore 2 points:

1) it is not as difficult to describe complex images, as it has often 
been 
argued on this list and cited as a reason why alt should no longer be 
required nor longdescriptions except in certain cases

2) the problem with all photo album sites, YouTube and the rest lies
not with the author, but with the underlying tools which prevent the 
association of ALT or LONGDESC (or their successors) 

any such tool MUST be defined by HTML5 as non-conforming authoring 
tools...

i pointed james graham to http://my.opera.com/oedipus/albums not 
to illustrate an accessible interface, but to counter the argument 
that providing long descriptions is beyond the ken of most users,
and to bolster my contention that a moment of reflection results 
in some pretty perceptive perspectives on each photograph -- it 
is the tool's fault that it reuses the tags associated with the 
photo as pseudo-alt text, not the user's -- each photograph that 
has been described does have a brief alt-type description 
associated with it, but i cannot get the interface to use that 
terse description as alt text without inserting it into the "tags" 
field, which would break the indexing of the images on the server...  
what i defined as alt text appears below the actual photograph in a 
case of implicit visual binding, rather than an explicit programmatic 
binding between the brief descriptor text and the photograph being 
described.  the field label for "description" is intended to allow a 
user to place a default description of the photograph beneath the 
photograph, so as to provide context for the photograph -- again, 
i'd prefer that such a description be programmatically bound to the 
image it describes and that it be accessed easily and expeditiously 
exposed the interested visitor.

so, PLEASE stop using my.opera album as a whipping boy for not 
practicing what i and others preach -- the point is, if the tool does
not offer the author the option to describe briefly and, if that user
so wishes, at greater length his or her photographs or videos...

if anything, it is a compelling argument for stronger authoring tool
conformance standards, NOT a reason do depracate a long description
mechanism...

the strategy cited in CSS2.1 for providing a long description is merely 
the adaptation of a kludge that was deprecated when WCAG 1.0 became
a technical recommendation -- use LONGDESC instead of an ambiguous
"D" link, and have it programmatically bound to the object it describes 
via markup, as we are dealing with content, not presentation, and the 
CSS2.1 model is not only a step backwards, but leaves CSS incapable 
user agents and their users nowhere

this is why i object to the framing of the issue as it has been reframed 
on

http://esw.w3.org/topic/LongdescRetention

the use cases should come first -- the page, after all, is dedicated to 
mechanisms capable of providing a brief textual description of a 
binary object and mechanisms capable of providing a longer, more 
comprehensive description -- what was added by lachlan hunt to 
the front matter belongs not under Use Cases -- which should 
remain the first item on the page so as to frame the discussion --
but in the "Research" "Further Reasearch" and "Suggested Solutions" 
sections...

the prose has been moved, but NOT edited or editorialized in any 
manner,

gregory.
--------------------------------------------------------------
CRITIC, n.  A person who boasts himself hard to please because
nobody tries to please him.
                     -- Ambrose Bierce, The Devil's Dictionary
--------------------------------------------------------------
Gregory J. Rosmaita: oedipus@hicom.net
   Oedipus' Online Complex: http://my.opera.com/oedipus/
      Camera Obscura: http://www.hicom.net/~oedipus/index.html
--------------------------------------------------------------

Received on Thursday, 23 August 2007 17:22:31 UTC