- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Tue, 31 Jan 2012 03:18:12 +0100
- To: Matthew Turvey <mcturvey@gmail.com>
- Cc: John Foliot <john@foliot.ca>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Laura Carlson <laura.lee.carlson@gmail.com>, Sam Ruby <rubys@intertwingly.net>, Paul Cotton <Paul.Cotton@microsoft.com>, Maciej Stachowiak <mjs@apple.com>, HTML WG <public-html@w3.org>
Matthew Turvey, Mon, 30 Jan 2012 19:28:51 +0000: > On 29 January 2012 22:30, Leif Halvard Silli wrote: >> Matthew Turvey, Sun, 29 Jan 2012 18:15:35 +0000: >>> It seems there are parts of WAI-ARIA 1.0 where no one can agree on >>> what it actually specifies, or whether what it does apparently specify >>> is actually possible or even desirable. >> >> Which are the sections of ARIA 1.0 that you have in mind? > > See, for example, brief discussion in > http://www.w3.org/2011/06/15-html-a11y-minutes.html > > Specifically "aria-label or aria-describedby is not sufficiently > specified in the WAI-ARIA spec to include or exclude markup" and "Defs > are ambiguous so that's why we have different behavior in different > browsers." Still a bit vague. But yes, aria-describedby needs more specification if what it points to is going to be presented as mark-up rather than as plain text. >>> This simple solution meets all the requirements: >>> >>> <a href=foo><img src=pic alt="*the purpose of the link*"></a> >> >> Most or all AT present the above as a link and not as an image. > > Jaws 12/IE7/XP with default settings announces "*alt text*, linked > graphic". AT can present this information in whichever way is most > effective for users. So this is irrelevant. Sounds like Jaws 12 in this detail is better than VoiceOver, then. Nevertheless, with @longdesc, the role of the image isn't affected, and hence the @alt can be authored to describe the image rather than being authored to describe the link. And it works in Jaws, too ... >>> If users need to be able to determine programmatically that the link >>> is a long description of the image, or authors want to put two links >>> on one image: >>> >>> <a href=foo rel=longdesc><img src=pic alt="*a programmatically >>> determinable long description link*"></a> >> >> No UA/AT support rel=longdesc. Hence: same problems as described above. > > I can't see any problems here. None of the purported use cases > actually require UA/AT's to do anything special with a longdesc link, > other than expose it as a link. All UA/AT's currently support user > access to the linked long description. So this is irrelevant. > > *If* any future use cases require a programmatically determinable long > description link, this _robust_ progressive enhancement technique > satisifes that requirement. But obviously, unless users actually need > this, it's just accessibility theatre. I have added many words in favor of @rel=longdesc. But @longdesc appears cleaner in the sense that it doesn't affect the @role of the <img>. If only it would have worked in AT, an anchor link as child of <object data=image > could be a similar solution. The only way to not affect the role of the img, would be to change the role of the link - e.g. <a role=presenation href=link>, but this also removes the clickability of the link for teh AT user. >> In Safari+VoiceOver, the @alt text of the <img> in this image map, is >> not presented to the user at all. Only the alt text of the <area> >> elements is presented. Last I checked, there were similar problems in >> other AT as well. > > AT doesn't need to do anything with the alt text on the image in this > context, it just needs to present the alt text of the area elements; I > only included it for completeness. So this is irrelevant. I thought you to mentioned image maps precisely because it allows us to discern between an img@alt - with a description of the entire image - and area@alt, which allows use to offer link descriptions. I don't agree that it ain't necessary: If that were the case, then HTML5 should restrict use of img@alt on img@usemap elements. >>> This universal design approach works for everyone, right now, >> >> Given what I described above, I fail to see how img@longdesc can >> currently be replicated with your above mentioned techniques. > > Irrelevant quibbling aside, the approach I suggested meets all the > requirements and works for everyone, right now. I don't think this is > difficult to understand. On the level that anchor links works everywhere, then yes: easy to understand. > The only "problems" with this approach are: it doesn’t require changes > to accessibility APIs, software upgrades, browser add-ons, user > training, author training, or employing the services of an > accessibility specialist. In case I wasn't clear before, I see this as > a benefit. > >> None of the above has any thing to do with ARIA. > > Indeed. The consensus is, otherwise, that 'something' is needed. Such as @longdesc. Such as @aria-*. -- Leif H Silli
Received on Tuesday, 31 January 2012 02:19:02 UTC