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

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





--- Comment #48 from Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>  2010-08-31 06:46:11 ---
(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.

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

Also note that text equivalents (of which "longdesc" is one) 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.

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

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

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

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, though use of "alternate"
for stylesheet links seems fairly incoherent. Even then, however, "rel" is
still designating a relationship between the current document and another
resource (the alternate stylesheet).

-- 
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 Tuesday, 31 August 2010 06:46:16 UTC