W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > September 2010

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

From: <bugzilla@jessica.w3.org>
Date: Wed, 01 Sep 2010 21:46:01 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1Oqv85-000731-NT@jessica.w3.org>

--- Comment #61 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>  2010-09-01 21:45:58 ---
(In reply to comment #59)
> (In reply to comment #52)

> > Benjamin, do you have a solution as to how expected behavior can be defined
> > for the uses of RDFa?
>     1. Pick or create a vocabulary that expresses the semantic relationship we
>        want.
>     2. Spec out the behavior you'd like and put it at some permanent URL.

A page at microformats.org? 

> I doubt the set of people able and willing to provide long descriptions
> significantly differs from the set of people able and willing to use HTML+RDFa
> (or authoring tools that use HTML+RDFa), assuming it ever gets standardized.

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

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?

Regarding 2., then is it ever any good to duplicate a @longdesc URL in an
anchor element?   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": A user agent supporting @longdesc
should have a method for ignoring a link that is used for the same purpose, no?
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.

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. Is JAWS, for instance,
able to ignore a D-link that points to the same places as a @longdesc link
pionts? Anyone knows? 

Of course, I must mention that @rel="longdesc"/rel="d-link" could play a role
for the progressive enhancement: when @longdesc is present, then the ua could
ignore an <a rel="longdese" href=*></a> link that points to the same resource.

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Wednesday, 1 September 2010 21:46:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:23 UTC