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

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





--- Comment #57 from Shelley Powers <shelleyp@burningbird.net>  2010-08-31 16:42:17 ---
(In reply to comment #56)
> > > 
> > > > 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 want consistency. 

If we're going to incorporate elements and attributes specifically because they
make a semantic unit, then we should apply the same reasoning for all elements
and attributes -- not cherry pick through the batch.

If we feel justified in adding a @hidden, we are more than justified in keeping
a @longdesc, or adding a @described-by. 

I do not see consistency in the decisions. I'm not talking about words
agreeing, I'm talking about the same principles guiding all decisions.

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

I would assume that longdesc acts the same way. Just because they're both
accessibility attributes doesn't mean they're joined at the hip.

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

Sorry, I don't think I wrote anything on dialog. I did write something on not
using dt/dd in figure and details, and that was a successful proposal.

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

It does?

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

I can't. I'm not a member. And I probably won't be continuing in this
discussion, either, because I'm not sure what's going to happen since Ian was
removed, and Paul and Sam added as asignees. And I'm not sure I'm adding
anything to the discussion.

-- 
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 16:42:19 UTC