Re: Drop longdesc, get aria-describedat?

Thanks, Janina. Comment sent using this form:

But note that I do not, yet, see the comment online:

Leif H Silli

Janina Sajka, Tue, 13 Mar 2012 19:54:55 -0400:
> Leif Halvard Silli writes:
>> Where do we file bugs against ARIA? Is this the place:
> Please look at:
> Instructions - PFWG Public Comments
> Janina
>> ?
>> Leif H Silli
>> Janina Sajka, Tue, 13 Mar 2012 19:35:51 -0400:
>>> Well, there's certainly no reason you need to accept my word on any of
>>> this. File a bug if you think it's a bug. That's the responsible thing
>>> to do, no?
>>> Janina
>>> Leif Halvard Silli writes:
>>>> To look blindly at 'calculation' is also to miss a point: You have 
>>>> defined what an 'img' role is. You could have said that 'img' element 
>>>> might also have 'description links', but that you have not defined what 
>>>> a 'description links' precisely is and precisely how it is handled, in 
>>>> the current version of ARIA.
>>>> Leif Halvard Silli
>>>> Janina Sajka, Tue, 13 Mar 2012 18:47:12 -0400:
>>>>> You're missing my point.
>>>>> There's no calculation relating to longdesc because there's no need for
>>>>> it. As I keep reminding everyone, ARIA-DescribedAT does not exist.
>>>>> There's no need to define rules for what to use, because there's no
>>>>> competing ARIA markup that serves the use case of HTML's longdesc.
>>>>> In the future, when we have an ARIA-DescribedAT, we will undoubtedly
>>>>> need to say something here. But, that day has not dawned.
>>>>> Meanwhile, ARIA-LabeledBy, -DescribedBy, etc., etc., all figure in alt
>>>>> text. For this there is indeed the need to consider precedence, which
>>>>> our doc attempts to do at great detail--because this calculation is
>>>>> important.
>>>>> PS: This should actually serve as further evidence that ARIA-DescribedBy
>>>>> isn't about long text alternatives but rather about short text
>>>>> alternatives, about that attribute known as "alt text" in html.
>>>>> Janina
>>>>> Leif Halvard Silli writes:
>>>>>> Janina Sajka, Tue, 13 Mar 2012 15:15:24 -0400:
>>>>>>>> ARIA defines where @title and @alt fits in in ARIA: In the 
>>>>>>>> accessible 
>>>>>>>> name. But ARIA does not explain where the longdesc link - or if you 
>>>>>>>> wish: an image with a longdesc - fits in.
>>>>>>> So?
>>>>>>    [ snip ]
>>>>>>>> However, while, ARIA expects AT to say 'image' if the element has 
>>>>>>>> role=img, and expects the accessible name to be presented as the 
>>>>>>>> content of the image, it  does not explain when and where the mere 
>>>>>>>> presence of a longdesc should be conveyed to the user. ARIA is 
>>>>>>>> silent. 
>>>>>>>> And makes no implicit expectations.
>>>>>>> No reason we should. You still haven't made the case that we are
>>>>>>> obligated to do this, or that we have a reason to do it.
>>>>>> That compelling reason, is found in the description of the img 
>>>>>> role: [1]
>>>>>>    "An img can contain captions and descriptive text, as well as 
>>>>>> multiple image files that when viewed together give the 
>>>>>> impression of a 
>>>>>> single image." 
>>>>>> Further more the characteristics section links to IMG in HTML4 and 
>>>>>> IMGGROUP in DTB. The later consist of one or more IMG, and each 
>>>>>> IMG may 
>>>>>> contain longdesc.]
>>>>>> Hence, many in the readership of ARIA 1.0, will assume that 'img' here 
>>>>>> is linked to HTML, whose image element is named <img>. And thus, that 
>>>>>> 'img' is formulated after the model of <img>. And so I ask: Where is 
>>>>>> HTML4's @longdesc in that description?  And where is it said that one 
>>>>>> might actually also find a description link inside an 'img'? The 'img' 
>>>>>> model of ARIA simply looks incomplete. [I had similar input 
>>>>>> during your 
>>>>>> last call too, but ...]
>>>>>>> From the accessible name calculation section and from other places in 
>>>>>> ARIA 1.0, it is further clear that an role 'img' element, from an AT 
>>>>>> perspective, only contains 'author' provided content. Thus: No 
>>>>>> 'contents' content. [For other readers: 'Author' content refers to 
>>>>>> contend specified via attributes: alt, title, aria-label, 
>>>>>> aria-labbelledby, aria-describedby. The clue is that AT only presents 
>>>>>> to the user such content that is explicitly referred to - or contained 
>>>>>> - in the designated attributes. ]
>>>>>> And so I ask: Is @longdesc 'author' provided content or 'contents'? It 
>>>>>> is clearly author provided - it contains a 'human inserted' URL. And 
>>>>>> so, from that perspective, it fits right into ARIA's model of 'img'. 
>>>>>> The only - somewhat dull - issue, is that @longdesc does not 
>>>>>> contain an 
>>>>>> author provided 'link text'. Only an author provided URL. It is an 
>>>>>> on/off thing: It is the author who adds it, or not. And then 
>>>>>> there is a 
>>>>>> standard presentation of that link.
>>>>>> The description of the 'img' role, also says: 
>>>>>>    "In order for elements with a role of img be perceivable, authors 
>>>>>> SHOULD provide alternative text or a label determined by the 
>>>>>> accessible 
>>>>>> name calculation." 
>>>>>> Which makes me ask: What about a link to a longer description for the 
>>>>>> image? SHOULD or MAY authors provide that? Do some images need - 
>>>>>> or not 
>>>>>> - a long, independent description in order to be perceivable?
>>>>>> Apparently, the ARIA task force *did* think that one description links 
>>>>>> are sometimes needed, because one or two ARIA specs/guides tell/told 
>>>>>> how one can use @aria-describedBY plus an anchor element to do 
>>>>>> that ... 
>>>>>> However the very description of the 'img' role, does not mention it ...
>>>>>>>> An image with longdesc indicates 'complex data image'. Hence, 
>>>>>>>> it seems 
>>>>>>>> logical with an early announcement about the presence the longdesc.
>>>>>>> Complex data? Maybe. Maybe not. Maybe it's a painting by Raphael. I
>>>>>>> would not characterize a long description of a painting as data
>>>>>>> structure.
>>>>>> Right. I should have skipped 'data' and only said 'complex' - or said 
>>>>>> 'complex or data filled'.
>>>>>> My main point here, was *early announcement*, so the user can 
>>>>>> choose to 
>>>>>> go for the long description instead of having to listen to the short - 
>>>>>> but possibly still long - alternative text. Longdesc is binary thing: 
>>>>>> Either it exist, or it doesn't. And so, its presence says something 
>>>>>> about the 'nature' of the element. That is why I likened to a sort of 
>>>>>> role. And something to be announced early.
>>>>>> Also, I think it is correct to say that *the author* [remember: 
>>>>>> 'author' provided content] consider the 'img' to be complex. The 
>>>>>> author 
>>>>>> decides what the 'img' needs. May be the 'img' doesn't contain so much 
>>>>>> 'data'. But the author still considers that an independent description 
>>>>>> is warranted, in order to go deep enough into its complexity.
>>>>>> [1]
>>>>>> -- 
>>>>>> leif halvard silli
>>>>> -- 
>>>>> Janina Sajka,	Phone:	+1.443.300.2200
>>>>> Chair, Open Accessibility	
>>>>> Linux Foundation
>>>>> Chair, Protocols & Formats
>>>>> Web Accessibility Initiative
>>>>> World Wide Web Consortium (W3C)
>>> -- 
>>> Janina Sajka,	Phone:	+1.443.300.2200
>>> Chair, Open Accessibility	
>>> Linux Foundation
>>> Chair, Protocols & Formats
>>> Web Accessibility Initiative
>>> World Wide Web Consortium (W3C)
> -- 
> Janina Sajka,	Phone:	+1.443.300.2200
> Chair, Open Accessibility	
> Linux Foundation
> Chair, Protocols & Formats
> Web Accessibility Initiative
> World Wide Web Consortium (W3C)

Received on Wednesday, 14 March 2012 00:45:14 UTC