- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Wed, 14 Mar 2012 00:28:03 +0100
- To: Janina Sajka <janina@rednote.net>
- Cc: Charles McCathieNevile <chaals@opera.com>, Richard Schwerdtfeger <schwer@us.ibm.com>, W3C WAI-XTECH <wai-xtech@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>
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] 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 23:28:37 UTC