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

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





--- Comment #64 from Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>  2010-09-01 22:50:53 ---
(In reply to comment #60)
> If some elements and attributes are added because they're semantically
> meaningful--rather than using alternatives--then that must be justification
> for adding another attribute for the same purpose.

No elements/attributes were added *purely* because someone proposed a meaning
for them and HTML5 is *not* produced by an automatic application of consistent,
appropriate principles. Discussing the lack of such principles may be
worthwhile,
but it is no more relevant to this bug than any other.

> > Why do you think it's a bad fit for UAAG Techniques?
> 
> It could be. But that's not RDFa+HTML5 or HTML5. Or are you suggesting that
> this be handled by another group? In which, this is definitely outside of the
> scope of a but for the HTML WG.

The bug tracker can express dependencies on bugs assigned to other WGs, if
necessary.

> > > Benjamin, do you have a solution as to how expected behavior can be
> > > defined for the uses of RDFa?
> > 
> >     1. Pick or create a vocabulary that expresses the semantic relationship
> > we want.
> >     2. Spec out the behavior you'd like and put it at some permanent URL.
> > 
> 
> And we define UA expectations...how?

Well, *one* possible approach would be as follows:

   1. Submit a new WCAG2 Technique demonstrating how to use RDFa to associate a
long text alternatives with an "img" element, comparable the existing
HTML4/XHTML1 "longdesc" technique [1], using the submission form provided [2].

   2. Reformulate Requirements 2-5 in terms of UAAG2 [3] success criteria
(3.1.1-3, 3.10.6, 3.11.7, 3.12.2, 3.13.2, 4.1.1 look relevant) as a series of
examples for inclusion in Implementing UAAG2 [4].

Another approach would be to publish a spec then try and implement it.

> > I doubt the set of people able and willing to provide long descriptions
> > significantly differs from the set of people able and willing to use
> > HTML+RDFa (or authoring tools that use HTML+RDFa), assuming it ever gets
> > standardized.
> 
> I would think that a simpler approach would have more adherents than a
> complex one.

You're right. I'll restrict myself to the hypothesis that there is more overlap
between the two groups than not. Please note by "use HTML+RDFa", I mean copying
and pasting HTML+RDFa markup, not understanding the intricacies of HTML+RDFa
parsing. Much like people copy and paste Facebook's HTML+RDFa [5] without even
realizing it's HTML+RDFa!

> I especially never thought about approaching say, JAWS, or the like and tell
> them they now have to incorporate support for RDFa, just so that we don't
> have to have something like described-by.

Ideally, we'd simply want UAs to give URLs designated as long descriptions
the same accessibility API mapping they give to "longdesc" today (e.g. IE puts
"longdesc" in the MSAA "accDescription" property), to avoid burdening AT with
implementing HTML+RDFa.

The risk is that HTML+RDFa might never be standardized or implemented by the
popular browsers with which popular AT is typically partnered.

I don't think anyone disagrees that simple, native features are preferable for
requirements HTML WG agrees to support.

[1] http://www.w3.org/WAI/GL/2010/WD-WCAG20-TECHS-20100708/H45.html
[2] http://www.w3.org/WAI/GL/WCAG20/TECHS-SUBMIT/
[3] http://www.w3.org/TR/UAAG20/
[4] http://www.w3.org/TR/IMPLEMENTING-UAAG20/
[5] http://developers.facebook.com/docs/opengraph

-- 
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 Wednesday, 1 September 2010 22:50:57 UTC