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

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





--- Comment #19 from Shelley Powers <shelleyp@burningbird.net>  2010-08-29 19:24:12 ---
(In reply to comment #17)
> > We don't want a link visually available, as I discussed in my earlier
> > scenario.
> 
> You might not, but other developers might.

And they have an element ready to hand, with the link <a>. But there is nothing
comparable for those of us who don't want a visual link. 

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

But you see, I'm only talking about what I want, not what is in some spec or
another. 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).

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

What is there about the term, long description, that is specific to visual
impairment?

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

Hard to say. It could be ugly. Could get tricky. Would have to require a great
deal of effort across groups.


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

Could be. I mainly focused on dublin core's description because that's what was
used in the example. 

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

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. 

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

But we do specify behavior and appearance in HTML5. I'm not talking about RDFa,
I'm talking about HTML5. 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.


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

http://dev.w3.org/html5/spec/rendering.html#the-progress-element-0

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. 

If it would be better, we can re-coach the requirements for behavior associated
with this item using EXPECTED. 

(And I never point to WhatWG documents within the W3C bugzilla database -- we
have no control over WhatWG, this database is for the W3C documents. There is
no guarantee the documents are the same.)

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

Again, when I see EXPECTED, I _expect_ it to be treated as MUST. 

HTML isn't a compiler language. Rules of use are just as important as rules of
parsing.

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

And yet the NOSCRIPT section was updated, just because user agents did not
implement the same behaviors for this element. 

I think we're also conflating all aspects of behavior, expectations, and
presentation into the term UI.

-- 
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 19:24:14 UTC