- From: Shane McCarron <shane@aptest.com>
- Date: Sat, 14 Aug 2010 11:00:53 -0500
- To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- CC: Ivan Herman <ivan@w3.org>, public-rdfa-wg@w3.org
Thanks for the clarification. And yes, I agree that (X)HTML+RDFa should support @longdesc and @cite. We had planned to add support for things like these in conjunction with XHTML 2 development. Obviously that has been overcome by events :-( Can we consider this a formal request for the addition of these features? I am sure Manu would be happy to add it to the issues list and debate it in the group in the coming weeks. On 8/14/2010 10:46 AM, Leif Halvard Silli wrote: > Shane McCarron, Sat, 14 Aug 2010 10:09:51 -0500: > >> (speaking with my PFWG member / liaison hat on) >> > snip > > >> It would be great to create triples based upon these >> clearly defined relationships. But such triples aren't a replacement >> for requiring that a user agent make the target of @longdesc >> navigable so that human users can find out what the heck an image is >> about. >> > Agreed. As should be obvious from my Appeal to the Team Contact: > > http://www.w3.org/mid/20100814035641214323.b7edba48@xn--mlform-iua.no > > My approach was - and is - that @longdesc represents a hyperlink quite > identical to anchor element hyperlinks. And thus my approach is further > that RDFa therefore should not forget/ignore @longdesc hyperlinks. > > I further think that to - as Ivan did - compare the @longdesc link with > the many attributes of e.g.<object> - many of which are also > fundamentally links - is not 100 percent fair. Longdesc should have > higher priority than most object attributes. Because it is my > perception that RDFa is primarily meant to identify, to computers, the > semantics that are available to humans. Whereas many of the attributes > of object, video, audio perhaps more should be seen as machine > instruction links - the computers and programs that needs access them, > are already able to do so. > > The closest parallel to @longdesc is the @cite attribute - used on the > <q> and<blockquote> attribute to point to a the source of a quote. > Does RDFa treat @cite URLs in any way? It would be logical to give the > same priority to @cite and @longdesc. > > @Cite has, by the way, also been suggested replaced by an explicit > anchor element, however the HTML5 editor, despite the obvious > similarity, decided to not treat them equally. > > >> From an accessibility perspective, support for the generation of >> additional triples isn't really that useful now, and I don't see it >> being that useful in the near term. Frankly, it is much easier to >> get the assistive technology vendors to support a long standing >> attribute with clear semantics (like @longdesc) than it would be to >> get them to add RDF processing to their tools. >> > I have not suggested that RDFa should support RDFa because it - > directly - could help A11Y users. My intention with suggesting this > rather is to contribute to the 'normalization' of @longdesc links - > just treat it like any other hyperlink. Such support would therefore > also, indirectly, help A11Y users. Because, the trouble with @longdesc > today is that it is not understood. There are many examples of authors > who believe it is a variant of @alt - that is: they fill it with text > instead of with a URI. > > So my motivation here is to contribute to the awareness of the fact > that @longdesc is a link - a link meant for human consumption. > > Makes sense? Thus, I do not necessarily think that native support for > @RDFa could open the 'flood gates', as Ivan said. @cite and @longdesc > really *could* have been solved via anchor elements. And since - the > way I perceive it - RDFa have native support for anchor elements, it > makes sense to me to treat these attributes on an equal footing, so to > speak. > -- Shane P. McCarron Phone: +1 763 786-8160 x120 Managing Director Fax: +1 763 786-8180 ApTest Minnesota Inet: shane@aptest.com
Received on Saturday, 14 August 2010 16:01:29 UTC