Re: Drop longdesc, get aria-describedat?

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] http://www.w3.org/TR/wai-aria/complete#img
> -- 
> leif halvard silli

-- 

Janina Sajka,	Phone:	+1.443.300.2200
		sip:janina@asterisk.rednote.net

Chair, Open Accessibility	janina@a11y.org	
Linux Foundation		http://a11y.org

Chair, Protocols & Formats
Web Accessibility Initiative	http://www.w3.org/wai/pf
World Wide Web Consortium (W3C)

Received on Tuesday, 13 March 2012 22:48:03 UTC