Re: longdesc URLs and RDFa

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