- From: <bugzilla@jessica.w3.org>
- Date: Sun, 29 Aug 2010 14:06:15 +0000
- To: public-html-a11y@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10455
--- Comment #13 from Shelley Powers <shelleyp@burningbird.net> 2010-08-29 14:06:14 ---
(In reply to comment #12)
> When *combined* with sister technologies like ARIA and HTML+RDFa, doesn't HTML5
> already meet Requirements 1 and 6?
>
> > 1. A programmatic mechanism to reference a specific a structured
> > description, internal or external to the document.
>
> We can reference descriptions internal to the document:
>
> <img src="foo.jpg" alt="{Short alternative}" aria-describedby="long">
> <p id="long">{Long description}</p>
>
> We can transclude long descriptions:
>
> <img src="foo.jpg" alt="{Short alternative}" aria-describedby="long">
> <iframe id="#long" href="long-description.html" seamless></iframe>
>
> We can indicate a link points to a long description for an image:
>
> <img src="foo.jpg" id="image" alt="{Short alternative}"
> resource="long-description.html">
> <p>
> <a xmlns:dc="http://purl.org/dc/elements/1.1/" about="#image"
> href="long-description.html"
> rel="http://purl.org/dc/elements/1.1/description">
> Long description
> </a>
> </p>
>
We don't want a link visually available, as I discussed in my earlier scenario.
People would take it to be a longer caption, which it isn't.
> We can reference an external resource as the long description with invisible
> metadata:
>
> <img id="image"
> src="foo.jpg"
> xmlns:dc="http://purl.org/dc/elements/1.1/"
> alt="{Short alternative}"
> about="#image"
> rel="dc:description"
> resource="long-description.html">
>
I have a question to the RDFa community about this, especially in light of
previous discussions about XForms[1]. The @resource isn't intended to be
clickable, but as Mark pointed out in the XForms discussion, user agents can go
above and beyond the intended RDFa purpose.
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.
This would mean, then, that user agents such as browsers would have to provide
some way to "click through" to the longer description. AT devices would then
have to provide audio cues and a way of "clicking through" to the description.
All the requirements John and Laura provided would have to be met--this doesn't
bypass these requirements.
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. It
could be tricky to implement--probably a lot trickier than just creating an
attribute that provided the URI.
And if people have been using RDFa with images, as I have, you could also be
"breaking" backwards compatibility.
Seems a lot of ifs, ands, or buts, associated with this. I wouldn't mind
hearing what some of the RDFa experts think on this suggestion.
Interesting idea, though.
> > 6. A method to reference a longer description of an image, without including
> > the content in the main flow of a page.
>
> "aside" designates content that is not part of the "main flow". This could be
> combined with "aria-describedby" like so:
>
> <img alt="Short alternative" aria-describedby="long">
> <aside id="#long">Long alternative</aside>
>
How do AT devices work with aside now?
> Requirements 2-5 look like UI requirements, rather than requiring additional
> language features.
>
User agent behavior and requirements are also included in HTML5.
> I may be mistaken, but I think ARIA, HTML5, and HTML-RDFa technologies allow
> user agents to adopt the UI behaviour detailed in Requirements 2-5 in relation
> to "dc:description", "aria-describedby" and "aside". (If someone believes they
> do not, could they please cite where the drafts forbid which behaviour
> described?)
>
If you want consistent behavior among all the agents, then the behaviors,
appearance, et al do need to defined in the document.
Why would you have normative references for UI for some elements and objects,
but not others?
> I've no objection to including non-normative suggestions for UI in these
> drafts, or other documents such as the ARIA User Agent Implementation Guide 1.0
> or UAAG 2.0 Techniques. But, in general, ARIA, HTML5, and HTML-RDFa do not
> *mandate* any particular UI, and I don't think that they should make an
> exception for long descriptions.
On the contrary, the HTML5 document has mandated behavior and appearance for
many elements and attributes. For reference see progress, noscript, and others.
I've no particular reason to think user agents
> *will* adopt the described behaviour, but I've little confidence in the magic
> power of the spec to force them too either, or any reason to believe such ex
> cathedra mandates would be ideal for all users in all circumstances.
>
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've elaborated how I think HTML5 could meet Requirements 1 and 6, and be have
> conforming implementations meeting Requirements 2-5, when used together with
> these other technologies.
>
> However, I've argued elsewhere that HTML5 should maintain a *native* facility
> for designating long alternatives for "img" elements, and that on balance
> keeping "longdesc" is the best choice:
>
> http://www.w3.org/2002/09/wbs/40318/issue-30-objection-poll/results
>
Agree. And well argued objection.
> If we do mint a new feature and it differs significantly from
> "aria-describedby" (for example, by taking a URI as a value rather than an
> IDREF), then it should be called something *other* than "describedby" to reduce
> confusion on the part of authors (e.g. a "longdescriptionhref" attribute or a
> "longdescription" element).
>
> But if we mint a new feature because "aria-describedby" is *not* sufficient for
> image long descriptions - for example, if being able to reference external
> documents as long descriptions is critical - then we should also be trying to
> fix ARIA (the generic level).
>
> Looking at the above, the key reason proposed for minting a new attribute
> differing from "aria-describedby" is in order to designate external documents
> as long descriptions. Why do users need this? Why hasn't PFWG expressed this
> requirement in ARIA?
--
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 Sunday, 29 August 2010 14:06:17 UTC