RE: Is longdesc a good solution?

Lachlan Hunt wrote:
> John Foliot wrote:
>> First off, many users of AT today do not query for longdesc as it is
>> rarely
>> if ever provided - a chicken and egg problem accelerated by the fact
>> that most (all?) browsers today still do not natively support this
>> element, 
> 
> This is not a flaw in the study.  It's is precisely one of the
> problems I designed the study to reveal.  But if you're just going to
> concede that this is indeed the case, then we can conclude that
> longdesc is not a well designed solution, and that it doesn't meet
> the needs of users, and move on. 

This is *NOT* what I said, and to read that into my statement is simply
wrong.  There is absolutely no proof that the design of @longdesc is poor or
flawed as it has never really been given a chance to flourish.  Is that the
fault of the design or of the browser developers who chose (for whatever
reason) to not provide a simple means of exposing this useful concept to end
users? Setting out to prove that most users today do not know about or use
@longdesc is a sucker bet, and adds no real value to the discussion, as
Hixie's stats have already proven that.

> Although having the quantifiable
> data from the proposed study to verify this would still be useful.

How, exactly?

> 
> Of course, it would be unfair to include a user in the group expected
> to use the longdesc attribute if their tool was incapable of it.

...and so, if we remove users of the latest version of JAWS and WindowEyes,
and maybe find enough users of iCab and Firefox with Patrick Lauke's
Longdesc Plugin [http://www.splintered.co.uk/experiments/55/] we can have a
balanced evaluation?  C'mon Lachlan, let's try and be realistic for a bit
shall we?  How can you prove the usefulness of an attribute when user-agent
support is one nano-slice above zero?

> 
> Assuiming you meant "potential beneficiaries of *long descriptions*",
> rather than just the attribute, then agreed. And so hiding the link to
> that information in the longdesc attribute where it is rarely, if
> ever, revealed to anyone but AT users, and even then only when the
> user explicitly queries for it, is clearly not a good solution.

And so where is a better solution?  Until such time as a workable
alternative exists, flawed as it may be to some it is the best we have.  The
phrase "throwing the baby out with the bath water" comes to mind here...  It
is very easy to slash and burn and dump attributes that *you* might never
use, with the justification that you don't use them because nobody else uses
them, but I have yet to hear (from you or anyone else) a *BETTER* solution
than the one we have now.  If there is enough justification to remove an
attribute that delivers a unique function then there *must* be an
alternative, "better" solution put forth.  Suggesting that "in the clear"
links to the more robust textual explanations is the ultimate solution is
simply pie-in-the-sky thinking - oh sure, it might be done *sometimes*, but
we know that more often than not, it won't be.

> 
>> This is also presumably the main reason why mainstream developers
>> under-use or simply do not use the element [hypothesis].
> 
> I assume you're referring to the longdesc attribute, rather than an
> element.

Typo - it was late, I was tired.  I know the difference.

> But there are many possible reasons why authors don't use it,
> none of which were intended to be revealed by the proposed study.

Then what exactly are you trying to prove?  That today @longdesc has
problems? Conceded.  Find a way to fix it or replace it, don't just dump it;
your study does not prove that a mechanism such as @longdesc is not needed,
and until you can prove that point there is nothing further to discuss.

 
> Regardless of whether or not that is the case and regardless any other
> possible solutions, the question still remains as to whether the
> longdesc attribute itself is a good solution.
> 
>> Until such time as a better, unobtrusive alternative to @longdesc can
>> be
>> presented I suggest that removing it from the spec is premature and
>> not fully defended.
> 
> No, why should we include an ineffective solution in the spec at all?

Lachlan, then let's go back to the beginning:

Need: Complex images require robust textual equivalents to ensure that they
can be perceived by users who cannot visualize a graphic.  Users in this
user-group are generally the visually impaired, but also included users of
text only terminals, or users who have disabled images (for whatever
reason).  SEO benefits can also be obtained through better descriptions of
images.

Need: Due to some (visual) design demands, links to longer tracks of text
that provide robust descriptions often need to be unobtrusive, yet easily
discoverable.  While using scripting or CSS techniques may provide partial
solutions, we cannot always rely on these solutions to be supported by
end-users/user-agents. (the phrase "progressive enhancement" comes to mind)

Need: A direct, programmatic link between the visual asset and the
description must exist (DOM), so that accessibility APIs can interact with
this link (see discoverable above). This is essentially the same problem
that was faced with @alt, except that in this case, the volume of
information that is contained in the alternative description is
significantly more extensive than the intent of the information supplied by
@alt

Statement of Fact: To date, the best solution proposed to address these
needs is @longdesc.  Currently however, User-agent support for this
attribute (with rare exception) has been poor to non-existent, an
acknowledged problem.  Because of this poor support, many developers simply
do not avail themselves to the attribute, or mis-use it due to poor
education surround usage of the attribute.

Problem: find a way to promote better adoption and proper use of the current
solution, or provide a better solution. 

(Hand off to the Working Group)

If there is a better way, then I for one (and I'm sure other accessibility
advocates) are willing to work with the Working Group to test and prove or
disprove this better way. One idea I have seen is to allow @alt to contain
either a text equivalent *or* a URI to textual information - I am not sure
however is this is optimum or even workable.  Walking away from the problem
however is no better a solution than maintaining the flawed yet workable
solution we have today.  I don't have a better solution, but apparently at
this time neither does anyone else.

JF

Received on Friday, 5 September 2008 17:07:03 UTC