Re: FW: [NVDA] #809: Support for longdesc in web browsers

On Fri, Nov 9, 2012 at 9:57 AM, John Foliot <john@foliot.ca> wrote:

> Hi Silvia,
>
> Silvia Pfeiffer wrote:
> >
> > It is good to see more support for long description
> > type features in screenreaders.
>
> But let's be specific here Silvia - support for @longdesc. Not some
> un-named, un-specified mechanism, but rather an existing, valid
> HTML4/XHTML1
> attribute. If nothing it strengthens the case that if HTML5 is supposed to
> be backward compatible then it is time to recognize @longdesc as a valid
> attribute in the markup language.
>
> >
> > That actually supports the argument made in [1] that we
> > need a screen-reader only long description attribute (such
> > as the proposed @aria-describedat) and should mark
> > @longdesc deprecated for HTML5 and obsolete when
> > @aria-describedat has arrived.
>
>
> I personally (and I think others) are not fans of making crystal ball
> predictions on what may happen sometime in the future.
>
> There is no justifiable reason to make @longdesc deprecated now or into the
> immediate future, as even if/when a future "better technique" emerges it
> will take a number of years to see wide-spread adoption and take-up by end
> users (just ask all those IE 8 users out there...). The Accessibility Task
> Force are moving forward with proceeding on Chaals' Extension Specification
> (
> http://dvcs.w3.org/hg/html-proposals/raw-file/b63325998cc1/longdesc1/longde
> sc.html), and it is my understanding that once it reaches FPWD status that
> this will remove the ambiguity around @longdesc's fate in HTML5.
>
> With due respect to Mr. Mazzoni, @longdesc is NOT a feature for "web
> developers", @longdesc is a feature for web consumers. I read his opinion
> when you first posted it, and again just now, and I respectfully suggest
> that he's missing a critical point in this debate, and is looking at this
> issue strictly from a developer's perspective.
>
> With commercial content creators (for example Pearson Publishing) and US
> Federally funded initiatives (NCAM's Diagram Project -
> http://ncam.wgbh.org/experience_learn/educational_media/diagram) producing
> effective and valuable long text descriptions delivered via @longdesc
> today,
> and, as evidenced by yesterday's NVDA announcement, more and more practical
> support in screen reading tools, it strikes me as counter-productive to be
> saying in HTML5 that we're gonna toss this baby out as soon as the new
> bathwater is ready, which will be soon, but we don't know when. I would
> prefer to see a much more orderly transition with some real overlap, and I
> think that until we have a proposed solution (likely aria-describedat),
> along with some implementation examples and experience with the new
> attribute, that it is way too early to be discussing deprecation.
>

The discussion about adding the feature to HTML5 will need to be had around
the extension spec so I don't want to go into this.



> I think that instead, we should be looking to encourage those browsers and
> OS stacks that currently do not provide good support to @longdesc (as JF
> glances towards Cupertino) to give it a second look - as NVDA did - and
> seek
> instead to deliver a better user-experience for all users moving forward
> today. Why wait? I have long argued that it is not the markup attribute
> that
> needs work, it's the support from the user-agents. The screen readers are
> (for the most part, and increasingly) doing their part, now we need the
> browsers to do something useful here too.
>

That last argument is the one that browsers don't buy into: screen reader
support for this feature makes a lot of sense. But browser support less so,
because if the author wants users to be aware of a document that has a long
description, they will author that into the visible part of their Web page.
If they don't they won't author it in. So why should browsers overrule a
Web developer's intention? It goes against what browsers do and it seems to
me that spending more time on pushing such functionality is futile. Let's
solve the real problem which is accessibility.

Regards,
Silvia.