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


--- Comment #51 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>  2010-08-31 12:18:41 ---
(In reply to comment #48)
> (In reply to comment #44)
> > (In reply to comment #40)
> > > (In reply to comment #30)
> > > > Thus it would be interesting to have your comment to rel="longdesc" in
> > > > combination with image maps: http://malform.no/testing/longdesc/
> > > 
> > > Two thoughts:
> > > 
> > >    * Testing in Chrome, opening the long description involved moving focus to a
> > > imperceptible link. I think that contravenes WCAG2's Visible Focus requirement.
> > 
> > Q1: You tested with VoiceOver? Or was it without screenreader? Which of the 5
> > test pages was it? 
> Without VoiceOver. Tried all of them, I think.

So your concern is the GUI browser user.

> > Q2: Please note that I have taken every step to hide the long description URLs
> > from GUI browsers (media="screen") - only AT and textual browsers are meant to
> > have access - I suppose this does not break WCAG.
> It breaks WCAG2 if a control has focus but focus is invisible or it is not
> clear what the control will do when activated.

So, since @longdesc causes authors to insert redundant anchor links to help
those that do not have @longdesc supporting UAs, @longdesc actually causes
authors to insert controls that break the WCAG guidelines. E.g. consider again
cssquirrel (http://www.cssquirrel.com/comic/?comic=72). 

So as I understand it if I were able to hide a control for all media, except
screen readers, then WCAG's recommendations are fulfilled.

> See Success Criteria 1.1.1,
> 2.4.7, 2.4.4/9, and Principles 1 and 3. The fact that I can tab to the
> "longdesc" link/area and activate it means the focus and purpose should be
> clear.

Purpose is clear, or can be made clear, when the link has rel="longdesc": UA
can implement support for rel="longdesc. And/Or author can make it visible via
CSS This would do the trick:

 a:link:focus, #map a:visited:focus { /* some CSS that makes it visible */ }

I may update my tests so this happens, as soon a I get the time to do it.

> Also note that text equivalents (of which "longdesc" is one)

@longdesc is not a text equivalent, only @alt is. @longdesc only *complements*
the @alt. For istance, in this example, the UA will not see the @longdesc,
since empty @alt = role="presentation":

<img longdesc="url" alt="" src="image" >

One problem with the above example is that for example my web browser, iCab -
which supports @longdesc - *does* present the longdesc URL (in a context menu,
as Laura suggests), even when the @alt  is empty, and thereby giving the false
impression that non-sighted users can benefit from that @longdesc ....

(Perhaps, btw, an <img> acting as image map should not be considered
presentational even if it has an empty @alt - after all, the <map> provides

>  are potentially
> appropriate for /any/ user, not just users of AT or textual browsers. Which is
> why Laura, although she describes "describedby" as for visual impairments,
> stresses it needs to be available to all users. See also the quotations from
> WCAG2 and supporting documentation in comment #23.

I do support that UA make @longdesc visible to all.

> >  Or,  is the correct way to
> > read your comment to assume that you would have said the same thing as you said
> > about (one of) those tests about @longdesc?
> No, since "longdesc" does not create a stop in the tab order and therefore
> never receives focus.

So, again, if we were able to completely hide (so that no "stop" happens) an
anchor for everyone, except for screenreader usres, then WCAG would be met?

What about this, which I saw in some of Laura's "examples in the wild": <a
class="redundant longdesc link" href="URL"><img width=1 height=1 alt="longdesc
link"></a>. To a sighted user, it is completely meaningles.

> > >    * Normally, "rel" specifies a relationship between the destination and the
> > > current document, not a relationship between the destination and a component of
> > > the current document. So I think you'd need to use some other attribute(s),
> > > like "resource" from RDFa (something like I suggested above) or "itemprop" from
> > > Microdata.
> > 
> > Do you have any backup info? I'll note that Julian Reschke of the link type
> > registry did not express any such reservations when I aired this (2-3 weeks ago
> > - public-html). Instead it sounded interesting to him, as I perceived it. Also,
> > when I filed a bug, then Ian accepted the proposal. Perhaps you disagree with
> > his resolution?
> It's an entirely reasonable link relationship; I'm just talking about the "rel"
> attribute.

Got it.

> I was saying you'd need to modify the referent of "rel" using additional
> attributes from RDFa.
> > Whereas HTML4 says
> HTML4 says the same thing about "rel" on "a":
> "This attribute describes the relationship from the current document to the
> anchor specified by the href attribute."
> http://www.w3.org/TR/html401/struct/links.html#adef-rel

My quotes were from HTML4 as well. I agree that HTML4 also says what you are

> The anchor specified by the "href" attribute, in this case, would be the long
> description URL.
> I guess one can work around this by arguing that "a rel='longdesc'" specifies
> one long description /belonging to/ the document, much as "a rel='cite'"
> specifies one citation belonging to the document, and then there's some magic
> processing to hook it up with a particular "img" element.


> > Likewise, the link registry [*] defines the 'alternate' link relation as
> > follows:  ]] Designates a substitute for the link's context. [[  So what is
> > the link's context? 'Context' is a least not wider than 'the current document'. 
> > [*] http://www.iana.org/assignments/link-relations/link-relations.txt
> rel="alternate" *does* refer to the current document

That's what HTML5 says. However, the link registry says that it refers to the
link's context.  Clearly, the document/page is the link's context. However, the
link element and its parent element also defines a context.

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 Tuesday, 31 August 2010 12:18:54 UTC