W3C home > Mailing lists > Public > public-html@w3.org > October 2009

Re: ISSUE-30 (Longdesc) Change Proposal

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Thu, 29 Oct 2009 02:19:10 +0100
Message-ID: <4AE8ED8E.5080706@xn--mlform-iua.no>
To: Jonas Sicking <jonas@sicking.cc>
CC: Charles McCathieNevile <chaals@opera.com>, "public-html@w3.org" <public-html@w3.org>
Jonas Sicking On 09-10-29 00.57:

> On Wed, Oct 28, 2009 at 7:59 AM, Leif Halvard Silli:
>> Jonas Sicking On 09-10-27 20.15:
>>> On Tue, Oct 27, 2009 at 7:09 AM, Leif Halvard Silli:
>>
>>>>> I agree that @longdesc and @aria-describedby aren't exactly the same.
>>>>> However they are very similar.
>>>> Everything with a link is "similar". But normally, if one element can
>>>> take
>>>> IDREFS only and another can take a single, complete URI, only, then we
>>>> don't
>>>> consider them similar.
>>> If two features are designed to solve the same problem, then I think
>>> they are similar enough that having both is a loss for all involved
>>> parties.
>> I think you should try to put in words what the "same problem" is. It sounds
>> to me as if the only sameness you have in mind is "accessibility". That is a
>> MUCH too wide sameness.
>>
>> Fact is: @alt and @aria-labelledby are somewhat related [*]. Why don't you
>> propose to remove the one or the other?
> 
> If @alt was used as little as @longdesc is then I would definitely
> propose to remove @alt as well.
> 
> Removing @alt at this point would break a lot of existing content out
> there.


It would not break anything: "removing" as per HTML 5 means that 
authors should not use the feature anymore, but that user agents 
continue to implement it.

> That's the only reason why I think we should not let
> @aria-describedby replace @alt.

Ahem ... Either you did not notice that I spoke about 
aria-LABELLEDBY.  Or, you are saying that you would like 
aria-DESCRIBEDBY to replace aria-LABELLEDBY ... Aria-describedby 
is not a solution to everything ...

For the record, "@aria-label" (not @aria-labelledby) is what is 
equal to @alt. But since HTML has @alt, we don't use aria-label 
(on IMG at least).

>>>>> Also, syntactically @aria-describedby has a larger syntax if the
>>>>> description is in an external document.
>>>> In addition to require a much more verbose *markup*, there are also
>>>> "expected effect" differences. See John's message [1] (and my reply).
>>>>
>>>> [1] http://www.w3.org/mid/009901ca566c$a296a9c0$e7c3fd40$@edu
>>> I don't agree there's an expected difference.
>> Comparision table:
>>
>>>>>>>>>>>>>> describedby= | longdesc=
>> Is fallback:           no | yes
>>    Is link:           no | yes
>> Moves you
>> away from
>> img itself:           yes | no
> 
> Is there specs to back this up? Or is this your opinion?

Ian asks for implementation proof. You ask for specs. And call it 
"opinion" if I cite implementations.

Please keep in mind that we are not discussing the typical use of 
aria-describedby (which is to link to describing elements *inside* 
the document),  but are in stead discussing how to link to a 
description outside the document.

	1st claim: Fallback content.
   In HTML 4, @longdesc represent fallback: [1] "This attribute 
specifies a link to a long description of the image. This 
description should supplement the short description provided using 
the alt attribute. "
   In WAI-ARIA, aria-describedby: [2] "A label should provide the 
user with the essence of what the object does, whereas a 
description is intended to provide detail that some users might 
need."  [3] "An accessible description may be computed by 
concatenating the text equivalents for nodes pointed to by an 
aria-describedby attribute on the current node."

The long description in the document that @longdesc links to is 
not a "text equivalent node". If aria-describedby points to an 
anchor element, then the "Text Equivalent Computation" only gives 
you the text of that link, and not the content of the linked 
resource. (And, btw, I don't know if what ARIA calls "an 
accessible description" contains any info about whether 
description includes a link.)

An "accessible description" is not the same thing as fallback. 
Fallback is in principle not an accessibility specific thing.


	2nd claim: Is it a link?
   In HTML 4 longdesc is described as a link: [1] "Since an IMG 
element may be within the content of an A element, the user 
agent's mechanism in the user interface for accessing the 
"longdesc" resource of the former must be different than the 
mechanism for accessing the href resource of the latter."
  In WAI-ARIA, aria-describedby is used to create "an accessible 
description" [3]. See quote above.

   The answer is given. Though I don't rule out that the AT may 
provide means to navigate to the elements that aria-describedby 
links to. Perhaps Steve knows more about this.


	3rd claim: Moves away from the IMG itself?
   HTML 4 (per Ian's definition - that is: as implemented): I can 
only repeat that the implementations of @longdesc that I am aware 
of [excluding Firefox extensions - I forgot how they work], opens 
the link in a new window. When you close the window, you will then 
be back at the same window that you left, and the insertion 
point/cursor will thus be located at the same spot that you left. 
Thus you can proceed down the page. The resource could in 
principle be on the same page, though. It it the new window/tab 
effect that matters.
  WAI-ARIA: Even if an aria-describedby attribute is (only?) used 
to create "an accessible description", I still imagine that the 
aria-describedby IDREF or IDREFS could be used by the AT user to 
navigate those resources. Thus it could be used to move to the 
link. Already this represents a move away from the IMG to that 
anchor element - which may be placed in arbitrary locations on the 
page. A second move away from the IMG is the activation of the 
said anchor link.

[1] http://www.w3.org/TR/html401/struct/objects#adef-longdesc-IMG
[2] http://www.w3.org/TR/wai-aria/#aria-describedby
[3] http://www.w3.org/TR/wai-aria/#descriptioncomputation
-- 
leif halvard silli
Received on Thursday, 29 October 2009 01:19:50 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:09 UTC