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

On 6 April 2012 01:42, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
> Matthew Turvey, Thu, 5 Apr 2012 09:48:12 +0100:
>> On 5 April 2012 01:27, Leif Halvard Silli:
>
>>> The quote begins: "_the CP_ we have endorsed DOES provide".
>>
>> Clearly the CP itself is not used by users to access long descriptions :)
>
> Clearly they don't. Fortunately, that's another thing Janina didn't
> suggest.

	We believe an ARIA approach for providing long text descriptions of
	images will necessarily fall short on several key requirements today.
	[...]
	Inasmuch as ARIA is new technology not yet fully or consistently
	implemented by browsers or AT, how will you propose that your
	ARIA based long text description can serve users needs
	effectively and consistently, regardless of what particular
	browser or particular AT a user may employ? In asking this
	question we note that the CP we have endorsed DOES provide
	effective and consistent support for users regardless of browser
	and AT, and we believe they deserve that kind of support."

http://lists.w3.org/Archives/Public/public-html/2011Jun/0204.html

>>> With regard to the 'a link on the image' solution, then your CP does
>>> not solve the problem that users need to separate 'normal image links'
>>> from 'image with a link to a longer description'. [...]
>
>> rel=longdesc can provide a programmatic association where required,
>> but none of the purported use cases require UA/AT to do anything
>> special with a longdesc link other than expose it as a link.  So this
>> is irrelevant.
>
> If you see rel=longdesc as irrelevant, why list it in your CCP?
> Especially since it is a _Zero Edit_ proposal: It seems against the
> spirit of a zero edit proposal to present a *new* method, and that you
> don't even believe in it, doesn't make it any more sensible mention it.
>
>> As the Zero edit CP points out, there's no evidence that users are
>> aware of this theoretical distinction or would benefit in any way from
>> being made aware of it. [...]
>
> Indeed: Users don't need to know whether it is an anchor link or an
> onClick event either. But that doesn't mean that they don't need the
> effect that I would have thought rel=longdesc was supposed to have.
>
> For example: If the AT supports @longdesc, then users do perceive a
> difference between - on one side - an <img> with a @longdesc URL and -
> on the other side - an <a> with an image inside. E.g. in the latter
> case, imagine that the @alt text says "Click here" or "Link": It would
> then be near impossible for the user to guess that the link link lead
> to a pagee with description of the image itself - it would be more
> natural to guess that it lead to a page with another topic.
>
> So I would have thought that rel=longdesc would involve features that
> helped the user separate regular links from longdesc links. Personally,
> I consider the @longdesc link as a 'demoted' link: The 'link-i-ness' is
> kept in the background so that the image itself can stand in the
> foreground.
>
> But since you don't propose anything like that, then I understand where
> the point with mentioning it is.

"Using rel=longdesc seems to be a better option overall for the
majority of images which are not linked: it works for everyone now,
and AT can use the association to programmatically identify the link
as a long description for the image if this turns out to be a valid
requirement in future."

http://www.w3.org/html/wg/wiki/ChangeProposals/LongdescZeroEdit

-Matt

Received on Friday, 6 April 2012 01:15:50 UTC