[Bug 10455] Mint a describedby attribute for the img element

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10455





--- Comment #65 from Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>  2010-09-01 23:47:50 ---
(In reply to comment #61)
> Like Shelley, I don't think we can expect Jaws to handle RDFa. I also think
> that A11Y people should not have to learn RDFa in order to make accessible
> pages.

Covered both issues in my reply to Shelley in comment #64.

> But couldn't a rel="d-link"/rel="longdesc" be compatible with your RDFa
> idea? Shouldn't they work together? Via RDFa on can be more exact about the
> relationship, I should think  - not?

Did you see my comment #50?

> Meanwhile, I don't believe a theory and/or principle based discussion of
> @longdesc can ever "reach home" unless we are also solve the fundamental
> practical problem that @longdesc raises:
> 
> 1. @longdesc's relationship to @alt, especially to empty @alt
>      (since empty @alt makes the img ignored).
> 2. What to do when/while there is lack of user agent support? 
>      Duplicate the @longdesc in a link?

If you want your text alternative to be available to users of all user agents,
include it in-page or use a visible link, since these methods work in every
user agent and make the alternative discoverable by every user.

> Regarding 2., then is it ever any good to duplicate a @longdesc URL in an
> anchor element?

Yes, it can do *some* good.

> Does the programmatic relationship of @longdesc generally outweigh the
> confusion that can be had when someone with Jaws get both a @longdesc
> announcement as well as a link to the same page? 
> 
> In other words: a main problem with @longdesc, as I see it, is that it does not
> offer "progressive enhancement/fallback"

I agree that's a drawback of "longdesc" and, more relevantly to *this* bug, the
proposed new attribute.

> A user agent supporting @longdesc should have a method for ignoring a link
> that is used for the same purpose, no?

If it wants.

> Jaws does announce "visited link" if the link has already been visited. Fine.
> But the user may not understand that the visited link is in fact equal to
> @longdesc’s link.

Duplicate links like the following are a common antipattern on the web:

    <a href="somewhere.html">
        <img src="somepic.jpg" alt="{Article title}">
    </a>
    <a href="somewhere.html">{Article title}</a> 

How much does this antipattern confuse real users?

I've known screen reader users to complain about clutter on web pages, but
inability to access a text alternative arguably constitutes a greater
accessibility barrier than the clutter of a duplicate link.

> If the UA were able to understand that a link is used in the same role as
> @longdesc, then they could possibly ignore the link.

They could, though it's not without risk.

If a UA ignored the long description annotation when the user reads the "img",
the user might never reach the long description link. But if it ignored the
long description link, the user might miss out on any additional JS behavior
the author attached to that control.

> Is JAWS, for instance, able to ignore a D-link that points to the same places
> as a @longdesc link pionts?

JAWS 11 apparently includes a feature for automatically filtering out all
duplicate links:

http://www.freedomscientific.com/downloads/jaws/JAWS-whats-new.asp

I don't know if it applies this behavior to "longdesc".

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Wednesday, 1 September 2010 23:47:52 UTC