Re: longdesc URLs and RDFa

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