Re: 48-Hour Consensus Call: ARIA-DescribedAT & Longdesc

On 1 April 2012 14:53, Geoff Freed <geoff_freed@wgbh.org> wrote:
>> - Support for longdesc in browsers and AT is poor and has been so for
>>many years.
>
> GF:
> True, but there *is* support, and it isn't new-- it has been available for
> years.  Ask anyone who uses JAWS (anecdotally speaking, the most popular
> screen reader in use today) in combination with IE or Firefox (anecdotally
> speaking, the two most popular browsers in use today).  Better yet, try it
> yourself.  It works, and it works every time.

I don't think that's entirely accurate. There's at least some evidence
that even JAWS users sometimes have difficulty accessing longdesc
links. See:
http://www.w3.org/html/wg/wiki/ChangeProposals/LongdescZeroEdit#Problems_with_Longdesc

Regardless, we want long descriptions to be available to all SR users,
and everyone else who needs them. It's been 15 years.

>> - Adding a longdesc without an alternative method of access to the
>>long description results in many users with disabilities being unable
>>to access the content or even being aware that the content is there.
>
>
> GF:
> No argument here, but it that reason to remove it from the spec before
> replacing it with something better?  Does the W3C intend to punish
> screen-reader users, who have easy access to long descriptions, because
> non-screen-reader users do *not* have equal access to long descriptions?

Since longdesc is not supported in Orca, VoiceOver or NVDA, a normal
link is the best way to make long descriptions accessible to all SR
users. So let's drop the silly hyperbole about punishing users.

>>as previously noted by Steve Faulkner on this list:
>>http://lists.w3.org/Archives/Public/public-html-a11y/2012Mar/0063.html
>>
>>Also note RNIB and WebAIM already recommend using a normal link
>>instead of longdesc and have done so for many years, and authoring
>>reference sites like SitePoint and W3Schools already advise authors to
>>use a normal link instead of longdesc and have done so for many years.
>>See:
>>
>>http://www.w3.org/html/wg/wiki/ChangeProposals/LongdescZeroEdit#Problems_w
>>ith_Longdesc
>>
>>So I don't see any benefits in the W3C delaying officially obsoleting
>>longdesc any longer. Most of the web sector has already obsoleted
>>longdesc and moved on years ago anyway.
>
> GF:
> I disagree.  Removing longdesc from the spec before it has been replaced
> with something more useful gives authors no reasonable, simple option for
> conveying long descriptions in a manner that doesn't force a visual
> encumbrance on everyone.

Using a normal link on the image is the reasonable, simple option and
it doesn't force a "visual encumbrance" on anyone. A normal link is
more useful because it actually works, right now, for everyone
regardless of browser or AT and can be progressively enhanced for
programmatic determinability if required.

> Not only that, but from an outsider's view (and
> even from an insider's viewŠ) it appears that the W3C is torpedoing a
> primary rule in its own accessibility philosophy.  The solution is simple,
> and everyone eventually gets what he or she wants:  just put longdesc back
> in the spec now, then remove it when describedat (or whatever it's going
> to be called) replaces it.  Then everyone in the industry can make the
> slow transition from old to new.

Longdesc and aria-describedat certainly torpedo WCAG2's "Perceivable"
and "Robust" principles. One of the things we want is for long
descriptions to be available to everyone who needs them, not
"eventually", now. It's been 15 years.

> I don't know who or where "most of the Web sector" is, but I can tell you
> that in NCAM's sector, there are still plenty of reasons to use longdesc.

I cited advice from the RNIB, WebAIM, SitePoint and W3Schools because
I think they (roughly) represent most of the web sector. They all
advise using a normal link and have done for years.

> I recently spent two days with a major international textbook publisher,
> training developers and authors there in Web-accessibility techniques.  At
> least half of each session I conducted was consumed with approaches to
> describing complex STEM images.  This publisher, and many others in the
> industry, wants to convey image descriptions to users that need them (also
> see https://www.w3.org/Bugs/Public/show_bug.cgi?id=13461).  Believe it or
> not, visual design still matters and so using visible links and/or using
> visible descriptions are not options.  longdesc *is* the only option at
> this point, and it's a workable option (see above) even though it's
> unevenly supported and targets a single, specific audience.  At least,
> it's workable until a better solution comes along.

Longdesc is obviously not the only option at this point, or even the
best option. Using a normal link on the image doesn't affect the
visual design in any way and is a far better solution because it works
for everyone right now, without requiring browser add-ons, software
upgrades, user training etc.

It's unclear why any publisher would even consider using an
"accessibility" technique that makes the long description completely
inaccessible to most users including at least some SR users, when a
simpler, POUR technique that makes the long description accessible to
everyone is available. Whatever happens with HTML5, longdesc is not a
viable option at the current time: it completely locks out most users.

-Matt

Received on Monday, 2 April 2012 01:34:26 UTC