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

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





--- Comment #66 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>  2010-09-02 00:40:28 ---
(In reply to comment #65)
(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.

OK.

> > 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?

You don't show any examples where the @rel appears inside an anchor/area
element ...  So I guess that's a diff between your and mine idea: You want
screenreaders to treat some RDFa code the same way that they treat @longdesc -
simply put, you want screenreaders to support "dark links"  in RDFa.

Whereas I suggest to link a behaviour to @rel="longdesc", only when used in <a>
or <area>.

Please note that in Charles's change proposal, then <img> would become defined
as an interactive element. It seems like you operate with another understanding
of "interactive" than he does ... 

But back to my question: are our ideas compatible, or not?  

Let us say that we agree about a definition of rel="longdesc" - whenever there
is no RDFa in use. This would allow authors to become creative in using <area>
and <a> to create longdesc link solutions.  I am quite sure that many would
come up with solutions.

Then, also take in your idea: In addition user agents could implement support
for a specific subset of RDFa - such as you showed in comment #50. The would
the use the same rel="longdesc". Except that they would not need to use it
inside an <a> or <area> element.

> > 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.

OK?

> > 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.

Yup. It would also be a drawback to the RDFa solution you suggest, though -
unless you apply the RDFa to a "real" link element.

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

Well, it should probably be optional, yes.

> > 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?

Enough to make Jaws create a filter for the issue - according to what you say
below. ;-)

> 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.

Sure. So if a user cannot access the longdesc resource simply because his/her
UA doesn't support @longdesc ... We have an accesibility issue ... Has anyone
created javascript library that adds suppport for @longdesc, somehow?

But it is *then* that one must start asking if it isn't necessary to add
something to HTML which, by the right authoring choices, can be made to work in
all user agents. I don't ask for removal of @longdesc, I just ask for the
opportunity to create something that works for all. Adding some kind of RDFa
microformat will not help (unless, of course, it is used inside a/area). Only a
link based solution can be truly acessible her and now.

Btw, w.r.t. to RDFa, you did see comment #15? There is a Issue in the RDFa
Working Group (requested by yours truly) to define an RDFa mapping for
@longdesc. You should perhaps see that threed - the working group seemed to be
in favour of some kind of "hard coded" semantics for @longdesc. And I just
wondered if rel="longdesc" etc should/can be "hardcoded" as well. (Probably
best to discuss it "over there".

> > 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.

But if that link had rel="longdesc", then it would have reason to trust that it
could filter it out.

> > 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

Thanks for the info!

> 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 Thursday, 2 September 2010 00:40:35 UTC