- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Sat, 14 Aug 2010 17:46:19 +0200
- To: Shane McCarron <shane@aptest.com>
- Cc: Ivan Herman <ivan@w3.org>, public-rdfa-wg@w3.org
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. -- leif halvard silli
Received on Saturday, 14 August 2010 15:47:08 UTC