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

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





--- Comment #17 from Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>  2010-08-29 18:43:45 ---
> We don't want a link visually available, as I discussed in my earlier
> scenario.

You might not, but other developers might.

In particular, the "WAI Consensus Resolutions on Text alternatives in HTML 5"
expressly requests this facility, without specifying the link needed to be
invisible:

http://www.w3.org/2009/06/Text-Alternatives-in-HTML5

This technique has better backwards compatibility and discoverability than any
other approach other than including the long description on the same page.

> People would take it to be a longer caption, which it isn't.

Who are "people" here? End-users? They *might*. But I don't see why they should
misunderstand a link that says "Long description", but understand a context
menu item that also says "Long description". Is there evidence that people
think the description links suggested by WCAG 1.0 and WCAG 2.0 Techniques point
to longer captions?

http://www.w3.org/TR/WCAG10/#q16

http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G190

> The HTML5 specification would have to specifically provide an expected
> behavior for this unique use of RDFa, which could be a bit strange in the
> document.

Wouldn't it be inappropriate for anyone other than Dublin Core to mandate how
their vocabulary should be consumed? It would be appropriate for UAAG 2.0
Techniques to make some suggestions, but probably out of place in HTML5+RDFa or
HTML5.

> A Dublin Core description is a text-based content description of the image.
Typically, these have been more captions, but I suppose it could also be
defined as an exact text description of the image, suitable for the visually
impaired. It isn't defined to this level of exactitude, which does concern me
about its use in this regard.

[snip]

> And if people have been using RDFa with images, as I have, you could also be
> "breaking" backwards compatibility.

If DC's "description" is so mismatched with the concept of long description
that treating it as a long description would cause backward incompatibilities,
then we need to use a different vocabulary. Fortunately, if one doesn't already
exist, anyone is free to create one. Trying to reuse AccessForAll in some form
might make sense:

http://www.imsglobal.org/accessibility/

> How do AT devices work with aside now?

I assume by "AT devices", you're thinking of AT software like JAWS or Dragon
Naturally Speaking or ZoomText (they're not what I'd call a "device")?

I've not tested; I suspect they don't treat it differently to "div" at the
moment.

What's the import of your question? A lot of AT still does nothing at all with
"longdesc", and obviously no AT does anything with the proposed "describedby"
attribute. Long descriptions are a perfectly legitimate need, but they're
hardly top of the accessibility priority list so I wouldn't be surprised if
implementation dragged years behind the potential offered by (draft!)
specifications.

For evidence of low prioritisation, see:

   * http://www.nvda-project.org/ticket/392
   * http://www.nvda-project.org/ticket/809

> User agent behavior and requirements are also included in HTML5. 

UA behaviour and requirements yes, UI requirements generally not.

> If you want consistent behavior among all the agents, then the behaviors,
appearance, et al do need to defined in the document

I want consistent behaviour for things like parsing, DOM APIs, form submission,
error handling, script execution, and semantic interpretation.

I don't want consistent UI or appearance enforced by the HTML specification.

The HTML WG is in no position to design the ideal UI for all user agents of our
semantic markup - or even imagine all the possible platforms, devices, and user
agents that we'd need to cover! User agents, like users, vary, and that's a
good thing.

Or as Mark Birkbeck put it in the email you cite in the context of RDFa: "we
don't define *any* behaviour … If a browser wanted to make it clickable that
would be up to them, i.e., we don't say 'this attribute must never be
clickable', because we have no right to."

(This is not to deny that convention plays a role in good design, or even that
UI standards are a bad thing: I just don't think they should be conflated with
document format/metadata standards.)

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

http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#the-progress-element

http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-progress-element-0

http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#the-noscript-element

http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#display-types

> If the user agents wish to comply with standards, as they all fall all over
> each other to assure people they do, the specifying a standard UI should be
> enough to "force" the user agents to comply.

I think if HTML started mandating UI, then the costs of full compliance
(suboptimal user experiences) would quickly outweigh the benefits (marketing to
developers).

-- 
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 Sunday, 29 August 2010 18:43:49 UTC