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

On Tue, Apr 3, 2012 at 1:29 PM, Charles McCathieNevile <chaals@opera.com> wrote:
> On Sat, 31 Mar 2012 11:38:44 +0200, Benjamin Hawkes-Lewis
> <bhawkeslewis@googlemail.com> wrote:

[snip]

>> So if we want to push to make @longdesc conforming, we should
>> arguably also be pushing to:
>>
>>   - Suggest in authoring guidance that authors make long descriptions
>> discoverable using visible webpage elements.
>
>
> Actually, we should be pushing user agents to make long descriptions
> discoverable. The best native browser implementation of this was the "not
> all that great" iCab version, which changed the cursor. JAWS on the other
> hand manages it perfectly well for its user interaction. I don't think that
> my effort on TellMeMore is especially brilliant (nor was it intended to be)
> but it at least gives some hints at ways forward. I think SIlvia had some
> more ideas too...
>
> I think we can confidently say that discoverability is something that
> longdesc needs to work well. Since I don't think we are in a good position
> to sput authoratively on how that discoverability should work, I don't think
> we should try to spec it much, instead looking for innovative
> implementations to show the way.

I think we're talking at cross-purposes.

You seem to be talking about W3C should recommend to user agent
developers (I agree we should not require any particular user
interface for user agent conformance.)

I'm talking about what W3C should suggest to authors trying to produce
long descriptions that are accessible to all end users who might need
them.

Until vendors widely implement @longdesc UI, it is harmful to suggest
such authors rely on the @longdesc attribute.

It's even harmful to suggest authors who merely wish to produce long
descriptions that are accessible to screenreader users rely on
@longdesc, since this in practice excludes VoiceOver and NVDA users.
(Note AAP, in their bug report asking for retention of @longdesc,
assume that long descriptions are for visually impaired users only, a
use case that does not match the PF's proposal to include @longdesc,
WCAG2's notion of a text alternative, or HTML4's spec for @longdesc.)

Requiring conformance checkers to report a validity error or warning
for @longdesc is not the only way to provide authoring guidance.

Reporting implementation status information for all features, perhaps
with a note about alternative techniques, would be better.

Such status information is closely related to the WCAG2 concept of
"accessibility supported":

    http://www.w3.org/TR/WCAG/#accessibility-supporteddef

>From a compliance perspective, I think it's questionable whether
relying on @longdesc to provide text alternatives is "accessibility
supported" today.

--
Benjamin Hawkes-Lewis

Received on Tuesday, 3 April 2012 16:36:15 UTC