- From: <bugzilla@jessica.w3.org>
- Date: Wed, 01 Sep 2010 22:50:56 +0000
- To: public-html-bugzilla@w3.org
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 the QA contact for the bug.
Received on Wednesday, 1 September 2010 22:50:58 UTC