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

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





--- Comment #56 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>  2010-08-31 16:23:20 ---
(In reply to comment #55)
> (In reply to comment #54)
> > (In reply to comment #52)

> Sorry, misplaced scare quotes. Consider them removed. 

Removed.

> > > The solutions I'm seeing about object and imagemap and so on are, sorry,
> > > bordering on the arcane.
> > 
> > Please note that it is rel="longdesc" that is the solution. Image maps (linked
> > to <img> of <object> - or <canvas>) is just a possible way to implement the
> > solution.
> > 
> > > And they don't meet HTML5's underlying semantic  criteria. 
> > 
> > What is "HTML5's underlying semantic criteria" ? 
> 
> It's the criteria used to justify adding 30+ elements and attributes. 

Still not sure what you mean.  I only know that you disagree with the addition
of many of those elements and attributes. Thus you should be happy that
rel="longdesc" only adds a @rel value, and nothing. (Well, there is probably
something to add, somewhere about what you call expecations.)

> > I myself am inspired by HTML4, which says that the <map> element may contain
> > anchor elements that renders outside the MAP for the purpose of accessibility -
> > and HTML5 allows the same thing:
> > 
> > ]]
> > Block-level content. This content should include A elements that specify the
> > geometric regions of the image map and the link associated with each region.
> > Note that the user agent should render block-level content of a MAP element.
> > Authors should use this method to create more accessible documents.
> > [[ http://www.w3.org/TR/html4/struct/objects#edef-MAP
> 
> Above you said all that would be needed is rel=longdesc. But here you're
> talking about using map. If map is part of the implementation, than more than
> rel="longdesc" is needed. 

I wanted to hear if you would describe HTML4's suggestion about how to use
<map> as against (some) HTML principle.

It goes without saying that rel="longdesc" needs more - it needs a link
element. @usemap is only a way to programmatically associate an IMG and a such
a link. (Btw, I could have provided simpler image map examples. But had they
been too simple then I perhaps would have gotten to hear that they don't work
... The more image map bugs user agents have, the more complicated must one
make the example ... )  Nevertheless, in Comment #45 I showed an example which
is quite simple and legal in HTML4/XHTML1 - that it is illegal in HTML5 cannot
be used agaisnt it, I mean @longdesc is illegal as well ... (Caveat: unlike my
tests as http://malform.no/testing/longdesc/, I have only tested it in one
screen reader - VoiceOver)

If @longdesc's only justification is technical, namely those times when the IMG
is already wrapped in an anchor element, then it goes without saying that
@longdesc isn't going to be much used. I don't think, however, that any of the
"examples in the wild" that Laura has documented, has any example of such a use
case. If the users don't get used to them, then they only get confused from
them - that to me seems logical, and Joshue has also shown a video, that we all
know,  and which shows that such confusion can occur in practise.

@longdesc i more than 10 years old. Perhaps we should try to bring to live
something which is only 7 years old, the The CSS 'Reader' Media Type: 
http://www.w3.org/TR/css3-reader/  That way we would be able to hide links from
all users other than screenreaders. That way authors would more easily meet
WCAG 2 requirements: rel="longdesc" anchor elements could be hidden from those
media that don't need them - see Comment #51. 

> Where would this usage be defined, in such a way that we could set expectations
> about what the UAs do?

FIrst: this bug report has digged up many holes in @longdesc. No wonder, of
course, as @longdesc has never really been discussed in public-html - it has
only been "shouted". (Only once the change proposal was voted over, did anyone
actually file @longdesc related bug reports.) One of the holes in @longdesc is:
what happens to the @longdesc if the @alt is empty? But of course, this could
be described in HTML5. And, since I don't support removal of @longdesc, I
suggest that they be described.

Second: One of the change proposals - initiated by you even - is removal of a
section in HTML5 which describes how to solve some usecase, including, as I
remember, dialogs. (I don't want that section myself.) But I guess that some
document would need to describe how to solve the technial problem that
@longdesc is able to solve, without @longdesc. Steve's spec is a good place for
such advice.

That said, HTML5 also defines image maps, so cleary some of this belongs there. 

Also, such a thing as <a href="*" rel="longdesc"><img src=diagram
alt=description ></a> requires that we take a look at the "how to write @alt
texts" section again. It also requires, I guess,  a look at the anchor/area
elements.

> In the meantime, these bug messages are showing up in the ally email list, but
> they're showing up unthreaded, which makes them difficult to follow on that
> list. That's why I wondered if this wouldn't be better as an email discussion.
> An email discussion would seem to be more suited to what's happening.
> 
> But, that's just a suggestion. Feel free to ignore.

I have some minor mail problems in the moment. But feel free to respond via
public-a11y next time.

-- 
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 16:23:27 UTC