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: Fri, 30 Oct 2009 15:49:31 +0100
Message-ID: <4AEAFCFB.2060509@xn--mlform-iua.no>
To: Joshue O Connor <joshue.oconnor@cfit.ie>
CC: Jonas Sicking <jonas@sicking.cc>, John Foliot <jfoliot@stanford.edu>, Charles McCathieNevile <chaals@opera.com>, public-html@w3.org
Joshue O Connor On 09-10-30 15.04:

> Leif Halvard Silli wrote:
>> Leif Halvard Silli On 09-10-30 13.30:
>>
>>> Joshue O Connor On 09-10-30 12.24:
>>    [...]
>>
>>> The purpose of ARIA seems to me to be to let the UA "compute" the A11Y
>>> layer on behalf of the author and the user. Whereas @longdesc as well
>>> as "normal fallback" (such as @alt content and the fallback of
>>> <object>) are "real" fallback that relies on regular hyper text.
>>
>> Therefore it seems more logical to me to include @longdesc into ARIA
>> than to introduce aria-link.
>>
>> Introducing longdesc into ARIA *and* make longdesc do - in ARIA -
>> whatever you envision that ARIA-link could do, would a) increase the
>> take up of longdesc, and b) be backward compatible and un-confusing.
> 
> I don't really follow. As already @aria-describedby is a long
> descriptor, hampered only by its inability to ref a URI.

How is it aria-describedby hampered, then, by not being a link, in 
your view? What do you mean by "link"? I think what you primarely 
have in mind is that we can include content that exist in another 
page. So, you just want the ARIA enabled User Agent to be able to 
collect the long description URI and present the content as part 
of the ARIA text equivalent computation behaviour.

That is not my concern. When I say "link" then I mean something 
that the user can click on, like a normal link.

The key in my argument is: the longdesc URI = fallback. Fallback 
is low tech. Support fallback URI = support fallback.

Now, an IDREF is also, you could say, lowtech. But it is not a 
link. It requires advanced ARIA support - or some other kind of 
workaround, like JavaScript -  if you want to EITHER make it 
behave like a link OR if you want to include the linked resource 
into the ARIA based "description computation"/"text equivalent 
computation".

To illustrate more clearly what I mean, we can look at the ARIA 
Text Equivalent Computation algorithm. It starts like this: [1]

]]1. Skip hidden elements unless the author specifies to use them 
via an aria-labelledby or aria-describedby being used in the 
current computation.[[

The algorithm could be extended to say that even elements that are 
linked to via @longdesc should not be skipped either. Because, if 
we want to align @longdesc with ARIA, then I think we must 
definitely consider that longdesc may point to a place within the 
page. Of course, ARIA should use neutral language like "fallback 
URI" rather than @longdesc.


Step 2 in that algorithm [but I wonder why they don't mention 
aria-describedby any place in the algorithm, except for the 
non-skip thing - seems unclear]. I split the quote in two:

]]2.	For any non-skipped elements:
	A.	Elements may specify their text equivalent in DOM attributes, 
used in this order of preference:
	▪	The aria-labelledby attribute is used unless this computation 
is already occurring as the result of another aria-labelledby (in 
other words, aria-labelledby is not recursive, so it will not 
cause loops). The text equivalents for all the nodes pointed to 
will be concatenated, using this same set of rules. [[

NOTE: It seems to me that aria-describedby should be mentioned above?

]]	▪	The aria-label attribute, which is just a text string, is 
used next
	▪	Any non-tooltip native markup (such as an img element's alt 
attribute in HTML), or the subtree for a label pointing to this 
element (such as label element's for attribute in HTML) 
contributes according to rules defined by the appropriate 
specification for that markup.[[

It seems to me that this is where @longdesc fits in, in the 
non-tooltip native markup section. We know (I know at least, but 
Jonas so far disagrees) that the longdesc represent fallback. 
Being fallback, and if ARIA includes @longdesc into its 
algorithms, then it has the option to preload the longdesc URI and 
present the result to the user, at the appropriate place, as part 
of this algorithm.

Further, the algorithm can take in the possibility that the 
longdesc URI leads to a place inside the place itself, and thus 
prevent recursive references of aria-describedby and aria-longdesc 
linking to the same thing. Etc and so and so forth.

Possibly the ARIA algorithm could consider that @longdesc makes up 
a direct, long fallback for the resource. It is really of high 
value, IMHO, to know that a single resource is meant as direct 
fallback. Rather than being presented a computation of possibly 
several references.

[1] http://www.w3.org/TR/wai-aria/#textequivalentcomputation
-- 
leif halvard silli
Received on Friday, 30 October 2009 14:50:13 UTC

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