Re: Revert Request

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