W3C home > Mailing lists > Public > public-html@w3.org > June 2011

Re: ISSUE-30 longdesc - Chairs Solicit Alternate Proposals or Counter-Proposals

From: Charles McCathieNevile <chaals@opera.com>
Date: Thu, 16 Jun 2011 18:56:04 +0200
To: public-html@w3.org, "Matthew Turvey" <mcturvey@gmail.com>
Message-ID: <op.vw6hbqocwxe0ny@widsith.eng.oslo.osa>
On Thu, 16 Jun 2011 17:54:07 +0200, Matthew Turvey <mcturvey@gmail.com>  
wrote:

> This is why the RNIB's Surf Right standard explicitly recommends *not*
> using longdesc, and WebAIM recommends using a duplicate link if using
> longdesc. Longdesc is not available to all users, so you cannot rely
> on it to deliver a "a reliable and effective user experience."

I understand the recommendation for a duplicate link. This has an analogy  
in the "skip to content" links that have been necessary until HTML5's new  
elements for improved page structure is reflected in a better navigation  
interface in browsers.

But that analogy goes a little further. Right now those elements are  
basically useless in terms of delivering a "a reliable and effective user  
experience." I don't see any possible justification for assuming that one  
therefore shouldn't use them.

> My understanding is PFWG members support obsoleting longdesc, but some
> members believe we need more time to properly deprecate it. Is that
> correct?

I am a person who supports, in the long term, deprecating longdesc. I  
don't speak for the PFWG as a whole.

> Could you answer the questions from Sam's email?
>
> 1) WHO needs more time?

Tool developers (CMS, plugins, extensions, authoring systems, …) whose  
tools generate or consume longdesc.

Content authors who rely on documentation that includes longdesc.

Content producers whose workflow currently includes generating longdesc,  
whether manually or because of their toolchain.

Teachers, Documentation specialists and "regulators" (people setting  
organisational or corporate policies as well as governments) who rely on  
finished standards.

> 2) How much time would they LIKE?

Hard to say, but I would guess (based on the apparent time it takes to  
deprecate a feature from the Web) 5-10 years, assuming that a functional  
replacement is agreed within the next 3 years.

> 3) How much time could they LIVE WITH?

They could live with it being deprecated tomorrow. It has little likely  
practical impact on their workflows, if the ubiquity of non-conformant  
content is aything to go by.

> 4) What would be the IMPACT in terms of negative effects if they were
> not provided that time?

If they are not provided the time to make an adjustment, the most likely  
impact will be a continued disregard for conformance to the specification,  
as irrelevant to the real world. It seems unlikely that many  
implementations that offer the functionality will bother to remove it any  
time soon (i.e. faster than the time they would have changed over as  
described above) just because the spec changes, unless there is some  
reason to believe that most of the user agents that support it now will  
stop doing so.

In addition, it is likely that without an agreed way to provide the  
functionality of longdesc, there will be a continued fragmentation in the  
solutions tried, resulting in a drop in overall inefficacy of the web in  
providing necessary information to people who need it, or can make  
productive use of it.

> http://lists.w3.org/Archives/Public/public-html-a11y/2011Apr/0181.html

Cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com
Received on Thursday, 16 June 2011 16:56:34 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:25 UTC