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

<he> lots of links lead to "junk".  There is a lot of "noise" and "poison" 
on the web.  Again, What is needed is a way to move forward.  Accessibility 
is unpopular at best so naturally, there will be more of this surrounding it 
but in order to clean it up, jumping around will only befuddle the process.

One example I see is tables on the web.  There is really only one use for a 
table and that is for data yet, we see it being used for layout all over the 
place.  Why?  because it looks pretty.  Now, if you want to do something 
good for accessibility in html5, how about eliminating the possibility that 
tables will be used for anything but data?

----- Original Message ----- 
From: "Henri Sivonen" <hsivonen@iki.fi>
To: "John Foliot" <foliot@wats.ca>
Cc: <public-html@w3.org>; "'W3C WAI-XTECH'" <wai-xtech@w3.org>
Sent: Monday, September 08, 2008 3:58 AM
Subject: 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 13:53:30 UTC