Re: My case for the obsoletion of longdesc (Was: 48-Hour Consensus Call: InstateLongdesc CP Update)

On Sat, 15 Sep 2012 11:29:48 +0200, James Craig <jcraig@apple.com> wrote:

> I realize this is a heated topic [...liberal snipping throughout. I hope  
> I have not changed the context, but feel free to replace anything I  
> removed if you think it was important]

yes. (Note the following is all "in my opinion" etc).

> On Sep 13, 2012, at 10:10 AM, Janina Sajka wrote:
>
>> The HTML-A11Y Task Force has twice resolved support for the  
>> InstateLongdesc Change Proposal on Issue-30 Longdesc reconsideration,  
>> most recently as logged at:
>>
>> http://lists.w3.org/Archives/Public/public-html-a11y/2011May/0399.html
>> http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc

> Despite the importance I place on accessibility, I am hereby voicing my  
> opposition to inclusion of the longdesc attribute in HTML 5. I believe  
> longdesc should only be reinstated in HTML 5 with the caveat that it be  
> denoted as obsolete or deprecated.

As it stands (in particular, only being available on the image element)
longdesc is insufficient for the future. That said, I think it solves
otherwise unmet needs, and while there is no clear replacement I think it
is premature to mark it obsolete or deprecated.

(That was the TL:DR; version. The rest is explanation).

> Those reasons are as >follows:
>
> 1. *There are existing, valid alternatives to longdesc in HTML 5, some  
> of which work in implementations today.*
>
> Here are several: http://cookiecrook.com/longdesc/

As you note, SVG accessibility today is still early-stage experimental. I
suggest it is not likely to solve a lot of real-world problems in the next
3 years (unfortunately - I have been involved in SVG accessibility since
1999, and I would love to have seen more of its potential realised a
decade ago). That said, for the sake of your document...

I suggest you look at the "Accessibility Features of SVG" - I realise that
it is out of date (among other things we wrote it in 200/2001 when ARIA
was a couple of proposals in development from IBM and Ubaccess) but it
still contains relevant information. (If you're interested, it would be
great to update that for the modern world).

There was also work done by the SWAD-E project to prototype using SVG to
support accessibility for photographs - again a little digging is required
to find out where we were in 2002-4 but
<http://www.w3.org/2001/sw/Europe/reports/dev_workshop_report_1/#sec-references-toolshttp://www.w3.org/2001/sw/Europe/reports/dev_workshop_report_1/#sec-references-tools>
and
<http://www.w3.org/2001/sw/Europe/reports/dev_workshop_report_5/#sec-references-toolshttp://www.w3.org/2001/sw/Europe/reports/dev_workshop_report_5/#sec-references-tools>
may be worth a few minutes of your time.

> To the best of my knowledge, one of these approaches (the iframe example  
> listed at http://cookiecrook.com/longdesc/iframe/) works in all major  
> implementations today, which is to say that it is much better supported  
> than longdesc itself.

There are several issues that this approach does not solve.
1. It fails to improve on the "separate but equal" aspect of longdesc.
2. It is actually available to fewer people - in particular, users who
have some residual vision, and benefit from at least looking at the
image, have no means to access the description.
Try magnifying your example by 500% and turning on high-contrast.
3. It requires starting from scratch to teach a new technique to authors,
educators, users, software developers.

> 2. *The separate-but-equal approach always falls short of being truly  
> equal, and using this approach for accessibility is no exception.*

Always? Illustrating with a couple of examples is insufficient to prove
the general proposition.

I agree that in general it is not as good to have a separate solution, but  
that is a very different statement, and one that doesn't need to be  
demonstrated for the sake of the case under discussion.

In particular, one of the requirements for supplementary description is  
that people are able to *choose* whether to read it, and are not forced to  
do so.

And finally, I am not clear in what way longdesc is "separate-but-equal".  
I recently demonstrated [1] that the description can be on the same page  
and visible to all (per spec and how real implementations work) as well as  
being out of band to meet a common authoring goal.

> I am in favor of the general idea of providing structured accessible  
> content, but I believe the best way to do that is to make the content  
> itself accessible rather than linking to a separate alternative.

Certainly. I also believe that a real, but imperfect solution is almost
infinitely better than a perfect solution that is not actually available
in practice, at least until such time as the better solution includes the
important feature of existing in the real world.

> ... No one is clamoring for longdesc support of MathML, because it is  
> defined in an accessible manner,

This is incorrect. People do request alternatives be provided for MathML.
A common approach for mathematical content today is to use images
representing it - and a sound HTML4 method to provide accessibility in
that case is to link, via a longdesc, to MathML...

> despite the fact that support for MathML accessibility is varied in  
> implementations today.

Right.

> I would even support a recommendation to include a structured long  
> description alternative in the embedded metadata of raster image  
> filetypes, such as PNG. Some of you may recall that Fireworks used to  
> store its layer and path editing information in PNG metadata in much the  
> same way.

As you can see from the links I posted in the discussion of SVG above, I
have supported such ideas for many years. I still do.

Unfortunately this approach is not implemented on the Web today. (It makes
longdesc look like a very well-supported and effective approach to
providing accessibility).

> 3. *The longdesc attribute will never be removed from HTML 4.*
>
> Web authors or publishers can still use a valid HTML 4 doctype for their  
> creations, and those documents will always be conforming. Likewise,  
> rendering engines and assistive technologies are allowed and encouraged  
> to provide the best support possible, even in the case of non-conforming  
> documents. The comparatively few implementations with existing support  
> of longdesc are not required to drop support for it, and no one has  
> suggested that they should.

That is incorrect. It has been suggested that Opera drop its support for
longdesc, and according to a whatwg IRC discussion a bug was raised for
this. (I think that would be a mistake)

Further, this would deny authors the ability to combine longdesc, the
enhanced accessibility support of HTML5, and producing valid code.
Assuming a real proportion of authors who do use longdesc have a valid use
case, this seems an undesirable restriction to impose.

> 4. *Progress is a goal we all share.*

> My belief is that this drawn-out, years-long debate over longdesc  
> tarnished the reputation of web accessibility opinion within the web  
> standards and technology communities, because longdesc itself was not  
> worth the effort that many of you expended to save it.

This argument is circular. And can be reversed (either on the premise that  
removing longdesc is not worth the effort expended, or on the premise that  
removing longdesc casuses harm in excess of the value of removing it) to  
explain why the reputation of people proposing to remove it has been  
tarnished among those who want the Web to be accessible. That helps  
clarify the current political situation, but is not a technical argument.

I have spent more effort trying to save longdesc than it took to  
effectively
implement it (naturally that included providing test cases, checking for,
finding, and fixing bugs). But I have spent far less effort than many of  
the
people involved in this discussion.

It is unedifying to see an argument consume (on both sides) far more
resources than the subject of the argument.

> As one of my managers likes to say, "I can fight for this if you need me  
> to, but I only have so many silver bullets." Let's not waste any more of  
> our collective silver bullets on longdesc, when there are much more  
> important accessibility decisions to be made, and so many more amazing  
> new technologies waiting to be made accessible.

As one of the few managers to actually just implement, my experience is  
that the cost is far less than that of the argument, the results are  
valuable in proportion to that cost, it is far simpler than implementing  
the alternatives proposed, and there is no significant downside.

> Let's move the Web forward as we are chartered to do. Let's work  
> together to make the Web as accessible as it can be, instead of worrying  
> so much about hanging on to the mediocre technologies of the past that  
> we jeopardize forward progress towards better accessibility for everyone.

s/worrying so much about hanging on to the mediocre technologies of the  
past/fighting so hard for wishful thinking and hand-waving proposals/ and  
you may understand why I find this to be a nice rhetorical flourish, but  
immaterial to the discussion and unworthy of the concrete technical  
arguments you started with.

(For completeness in your alternatives, you should list the idea of  
longdesc pointing to a link on the page and doing the magic to follow  
that. I suggest that such a technique needs to include a discussion of  
maintaining content which relies on that pattern, which is where the major  
difficulties arise).

[1]  
http://lists.w3.org/Archives/Public/public-html-a11y/2012Aug/att-0192/internalLongdescTest.html

cheers

Chaals

-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
           chaals@yandex-team.ru         Find more at http://yandex.com

Received on Saturday, 15 September 2012 14:54:26 UTC