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

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

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"?  In a previous posting [1] I noted that authors need
multiple solutions so that they can choose which solution is best: it can be
argued that having many solutions is actually a more efficient, thus less
costly scenario - you don't need to figure out how to shoe-horn a solution
against a problem using inappropriate tools.  The current proposal
surrounding @alt finally got to this point; many ways of providing
alternative text, and having any one present ensures conformance.  This is
good design - taking way choice is IMHO bad design.

As well, while "next best" might be more cost effective for the author, it
shifts the burden to the consumer, who must expend more effort (cost) to
compensate for the fact that it is not the "best" but rather the "next
best".  Given that HTML 5 is supposed to be driven by the needs of users
first, then authors, how can this be a usable defense?

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* longdesc is useless or near-useless in the context of the Web and
> the foregone other accessibility improvement would have been useful,
> people relying on Web publication/application being accessible are
> worse off if HTML5 lures some authors to put their finite effort into
> longdesc and away from something more useful. 

Well, that *if* has not been proven so far.  The only proof we currently
have is that to date the attribute has been poorly used and often misused,
and history confirms that user-agent support for the attribute has been
almost non-existent over these years: drawing a direct relationship between
these 2 facts is pretty straight forward.  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.  So again, I ask: why limit choice, especially
when emergent support is getting better, not worse for this attribute?

> 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?  It
is not clear how removing support for a late-blooming accessibility
enhancement will make things "better" for the target users - it makes it
worse.  So using your statement, removing @longdesc is bad (as it makes
things worse for users) and thus harmful to HTML 5.

 
> Aside: I agree that Lachlan's research setup has the problem you
> described. However, longdesc has been in one of those W3C specs that
> software implementors actually paid attention to and yet after a
> *decade* it has the problems you describe.

And yet, software developers have not given up, and are actually making
progress here.[2] User-agent support for this specialty attribute has been a
low priority for browser manufacturers as the ROI was not the same as, say,
striving to meet Acid2 CSS requirements.  So it was prioritized as such.  It
is not fair however to say that because there were (and remain) other larger
implementation issues for UA developers to deal with that they have given up
on @longdesc, especially when the evidence shows that in fact they are
returning to this issue and working on improving support.


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

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

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; the "fallback" of <object> *might*
provide an equivalency, but that has yet to be proven - and given the desire
for provable test-cases in HTML 5 it falls to the advocates of that solution
to provide such. I am also concerned that given the low-priority of
@longdesc today, that even though there has been progress made lately that
if you scrap @longdesc and put forth another solution that currently has
little to no support, the severity of the new implementation will be treated
with the same low-priority status that @longdesc is currently saddled with -
it may indeed be a backward step.

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].  I have seen
alternates, but not equivalents - and there is a world of difference there.
(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)

JF


[1] http://lists.w3.org/Archives/Public/public-html/2008Sep/0223.html
[2] http://lists.w3.org/Archives/Public/public-html/2008Sep/0222.html
[3] http://lists.w3.org/Archives/Public/public-html/2008Sep/0182.html
[4] http://lists.w3.org/Archives/Public/wai-xtech/2008Sep/0085.html

Received on Sunday, 7 September 2008 17:59:14 UTC