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

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





--- Comment #23 from Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>  2010-08-30 12:09:14 ---
(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?

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

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

> The thing is, we need to define what different categories of user agents do
> with aside, so we also need to do the same with whatever ends up as Laura's
> described-by. 
> 
> If there isn't anything mandating behavior, we really couldn't blame
> described-by if it's use is sporadic, and maybe even incorrectly applied. 

Defining the semantics and providing example UI should be sufficient.

> But we do specify behavior and appearance in HTML5. I'm not talking about RDFa,
> I'm talking about HTML5.

We don't generally mandate appearance.

> If we want something in HTML5 to meet Laura's requirements and needs, then
> part of this requires some control over how UAs handle the item.

No, it requires someone to implement a UA that does what Laura wants with the
available semantics. For example, Patrick Lauke could update his "longdesc"
Firefox
add-on to handle "aria-describedby".

Since what Laura wants may not match what other users want, or be applicable to
all possible user agents on all possible platforms, it should not be mandated
in a specification for a semantic document/application description language.

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

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

-- 
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:09:19 UTC