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

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





--- Comment #24 from Shelley Powers <shelleyp@burningbird.net>  2010-08-30 12:56:46 ---
(In reply to comment #23)
> (In reply to comment #19)
> > If I were going to provide a separate page with a long, complex description
> > of an image that's specifically for the visually impaired, I would like to be
> > able to do so in a way that only the blind see it (unless people
> > know it's purpose and it is exposed as a specific type of link).
> 
> [snip]
> 
> > What is there about the term, long description, that is specific to visual
> > impairment?

I meant, what is there about "long description" that implies this item is going
to be an exact text equivalent of the image, and not a longer caption?

There's nothing to the term that provides an unequivocal understanding of
exactly what the person will find if they click the link. 

If an attribute is provided, and user agents implement something for people to
access it, the definition of the attribute would provide this meaning.

For all of the talk about the importance of "semantics" in HTML5, and having
semantic equivalents for this and that, why on earth would we then remove an
attribute that does have a specific "semantic" meaning? 

It's a heck of a lot more useful than something like hidden. 

> 
> Text equivalents aren't only for the visually impaired. If a user does not
> understand your image, the text equivalent is useful to them, hence the need
> for universal access. 
> 
> See also:
> 
> "Provide text alternatives for any non-text content so that it can be changed
> into other forms people need, such as large print, braille, speech, /symbols or
> simpler language/." (my emphasis)
> 
> http://www.w3.org/TR/WCAG20/#text-equiv
> 
> "Text alternatives may help some people who have difficulty understanding the
> meaning of photographs, drawings, and other images (e.g., line drawings,
> graphic designs, paintings, three-dimensional representations), graphs, charts,
> animations, etc. … Additionally, text alternatives support the ability to
> search for non-text content and to repurpose content in a variety of ways."
> 
> http://www.w3.org/TR/UNDERSTANDING-WCAG20/text-equiv-all.html
> 
> As such it would be inappropriate to designate long descriptions as "specific
> to visual impairment".
> 

And I believe that's why Laura asked that the contents pointed to in
described-by should be accessible to all people.

> > Hard to say. It could be ugly. Could get tricky. Would have to require a great
> > deal of effort across groups.
> 
> Yeah, that's one of the catchs with distributed extensibility.
>

This has nothing to do with distributed extensibility. That's one of the
catches with semantics. 


> > > > On the contrary, the HTML5 document has mandated behavior and appearance
> > > > for many elements and attributes. For reference see progress, noscript,
> > > > and others.
> > > 
> > > Sorry - where are the MUST-level "appearance" requirements for "progress"
> > > and "noscript"? I see only SHOULD- or MAY-level suggestions.
> > 
> > So how do we define EXPECTED?
> 
> [snip]
> 
> > I see EXPECTED as equivalent to MUST. Perhaps the use of the word EXPECTED is
> > incorrect, and too vague for use in a spec, but that's what we have. 
> 
> Did you miss the definition provided by the spec itself?
> 
> "User agents are not required to present HTML documents in any particular way.
> However, this section provides a set of suggestions for rendering HTML
> documents that, if followed, are likely to lead to a user experience that
> closely resembles the experience intended by the documents' authors. So as to
> avoid confusion regarding the normativity of this section, RFC2119 terms have
> not been used. Instead, the term "expected" is used to indicate behavior that
> will lead to this experience."
> 
> http://dev.w3.org/html5/spec/rendering.html#rendering
> 
> It's clear to me this means that user agents can freely ignore the entire
> section.
>

Expected means "likely to happen". I expect the UAs to implement the renderings
in the section.

So, the the same type of expectation can be provided for described-by.  


> > If it would be better, we can re-coach the requirements for behavior associated
> > with this item using EXPECTED. 
> 
> I would prefer it, since then the UI "requirements" would be suggestions not
> mandates and user agents like Firefox, NVDA, and Google Search would be free
> to disregard them in service of their users.
>
> > And yet the NOSCRIPT section was updated, just because user agents did not
> > implement the same behaviors for this element. 
> 
> I don't know what differing behaviors or what update you're referring to, or
> how this is relevant.
> 
> > I think we're also conflating all aspects of behavior, expectations, and
> > presentation into the term UI.
> 
> Maybe. I'm basically saying HTML5 should tell user agents how to construct a
> DOM and the semantics of that DOM, not mandate what interface to expose on top
> of that DOM to end-users. I think it's good for HTML5 to make interface
> suggestions, though suggestions for semantics defined in other specs like ARIA
> and Dublin Core are likely misplaced.


People are going to see EXPECT, and their expectations are going to be set. I
would expect that most UAs would understand this, and act accordingly. UAs
should have enough sense to know that when customer expectations are set, they
better meet them.

So, the same expectations for described-by should be sufficient.

-- 
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 Monday, 30 August 2010 12:56:49 UTC