Re: Is longdesc a good solution? (was: Acessibility of <audio> and <video>)

On Sep 7, 2008, at 20:58, John Foliot wrote:

> Henri Sivonen wrote:
>>
>> Authoring a long description and pointing to it using longdesc has an
>> opportunity cost.
>>
>> The potential effort available for making a Web publication/
>> application accessible is not infinite for a given publication/
>> application. The effort expended towards using longdesc (properly) is
>> away from what would have been the next best accessibility  
>> improvement
>> the author could make had the effort not been put into longdesc.
>
> Henri, your statement surrounding cost is valid.
>
> All effort has cost associated to it.  Sometimes individual authors  
> chose
> not to invest the extra effort (cost) to ensure "best", and that's  
> between
> them and their audience.  Other times authors either personally  
> care, or are
> mandated to ensure, that all effort is expended to ensure access:  
> cost is
> secondary to results.  It "costs more" to have a sign-language  
> interpreter
> on a stage when someone is giving a press conference, so very often  
> we do
> not have signers present (especially in the private sector). But if a
> government official is making a critical announcement (public  
> policy, public
> safety, etc.) the cost of having the signer there is not even  
> considered -
> it is a requirement - period.  This line of argument then is not a  
> valid
> excuse for the removal of a useful attribute that has no replacement  
> to date
> (and whose cost is simply borne by those who need or want to assume  
> that
> cost).

Every activity--including government activity--has an opportunity  
cost. When a sign-language interpreter is hired, those resources  
aren't used for something else.

> I also pose the question of why does the disabled community need to  
> accept
> "next best", when a current (non-mandatory) mechanism exists today  
> that
> might deliver "better"?

You are reading too much into "next best". The words "next best" are  
part of the common definition of opportunity cost:  Opportunity cost  
is the value of the next best choice foregone. Or formulated without  
"next best": Opportunity cost is the value of the highest-value  
alternative foregone.

When assessing the opportunity cost of a given activity, you, by  
definition, don't consider the value of the activity whose opportunity  
cost you are assessing but the value of the best *other* thing (i.e.  
"next best") that could be done if the activity whose opportunity cost  
you are assessing weren't chosen.

*If* the opportunity cost of an activity turns out to be higher than  
the value of the activity, it is not rational to pursue the activity.

> In a previous posting [1] I noted that authors need
> multiple solutions so that they can choose which solution is best:

That assumes that the authors are properly informed about the utility  
functions of the users.

I posit that J. Random Author is not competent to allocate resources  
in a way that maximizes the utility function(s) of the usrs who need  
accessibility given the resources J. Random Author has available.

If we give authors the choice of writing longdesc, some of them might  
write it at semirandom. *If* that activity is roughly useless (in the  
context of existing longdesc poisoning, see http://blog.whatwg.org/the-longdesc-lottery 
; see also http://lists.w3.org/Archives/Public/public-html/2007Sep/0350.html) 
  and authors would improve actual accessibility more by doing  
something else (not necessarily even image-related!), we'd end up  
improving overall accessibility more if we steered authors away from  
sinking their limited resources in the roughly useless activity.

> Finally, it still is not clear to me why the spec is removing an  
> attribute
> that will be (should be ?) grandfathered into the user-agents  
> anyway: does
> it not make sense to instead support the attribute and ensure that  
> proper
> guidance on it's use is provided?

*If* there's as much noise in longdesc as http://blog.whatwg.org/the-longdesc-lottery 
  says, it would probably be better not to grandfather it.

> We also know that recent
> developments from user-agent developers towards improving the  
> usability of
> this useful attribute has finally started to emerge: the latest  
> versions of
> the 2 mainstream screen readers now support @longdesc, and recent  
> betas of
> JAWS and IE8 are actually going one step further and making the
> discoverability of @longdesc a default behaviour of the tool(s),  
> rather than
> a toggled on requirement.

It would be very interesting to know how users will react to the new  
JAWS beta in this case--given the existing longdesc poisoning in the  
wild.

What exactly does IE8 really do? (As in, what's the verified behavior-- 
not just the whitepaper statement?)

>> Making people worse off
>> like that would be bad and, therefore, "harmful to HTML5".
>
> Which "people" are you referring to?  The authors or the end  
> consumers?

Users who need accessibility more than the presumed 'general  
population'.

>> So out in the real world--
>> the ultimate lab that tests if chicken and egg problems are
>> surmountable and UI design workable--longdesc has had a decade-long
>> test run and is failing.
>
> I disagree with this statement.  Despite the clear benefits of  
> separating
> design from structure, and the continued improvement for CSS  
> support, many
> software tools today still use circa 1990's development practices and
> output.  Does this mean then that CSS is a failure?  Or does it just  
> meant
> that the marketplace has yet to completely catch up to the current
> best-practices and best solutions?

CSS doesn't need to fully replace what came before it in order to be a  
success. Users can keep CSS enabled even if circa 1990s development  
practices also persist.

However, if the user needs to take an action when the UA indicates  
that longdesc is available and the user learns that taking this action  
virtually always leads to junk, why would the user expect non-junk the  
next time?

>> How long a test window should a feature have
>> before cutting our losses and trying something else?
>
> Why can we not try something else and yet still support the current  
> best?
> Why must you kill off one before proving that another is better?  To
> eliminate any competition?  Surely no?

To eliminate the old failed thing from competing for allocation of  
finite authoring resources, yes.

> Henri Sivonen also wrote:
>> "something else" in the last sentence could be:
>>  * Merely juxtaposed text that restates whatever it is the image
>> illustrates.
>>  * Juxtaposed text associated with aria-describedby.
>>  * Link to a different page phrased as a "more information" link for
>> all audiences as opposed to a [D]-link.
>>  * <object> element with HTML fallback content.
>
> Henri, none of these "solutions" provide what @longdesc provides  
> now: yes,
> they are alternative ways of providing the required information, but  
> none of
> them deliver the same functionality;

Well, *if* the exact functionality of longdesc is a failure, surely it  
doesn't make sense to retry the *same* thing (except perhaps to break  
free of the existing poisoned longdescs if there were a plausible plan  
to avoid the new exact equivalent from getting poisoned in the exact  
same way as longdesc did).

> The needs (I believe) have been clearly defined, but so far all we  
> have seen
> is work-arounds that do not solve the problem as described [3].

Does longdesc *as practiced* actually solve anything, either?

http://blog.whatwg.org/the-longdesc-lottery
and
http://lists.w3.org/Archives/Public/public-html/2007Sep/0350.html
sure suggest it doesn't.

> (Funny enough there is another current thread[4] surrounding the  
> @headers/id
> issue, where a proposed solution was to re-write the table to  
> support @scope
> even though the table layout was what the end users needed and  
> wanted.  It
> sort of feels that a similar type of answer is emerging here:  make  
> the
> problem fit the tools rather than fit the tools to the problem)

I think it's not prima facie unreasonable to improve accessibility by  
changing a design more broadly than by just bolting on more explicit  
programmatic connections for AT.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Monday, 8 September 2008 07:59:46 UTC