Re: TF response to your comments on HTML5 Image Description Extension (longdesc)

On Sep 3, 2014, at 1:19 PM, John Foliot <john@foliot.ca> wrote:

> James Craig wrote:
>> 
>>> 
>>> YOUR COMMENT #1:
>>>> Proposed Additions to "3.0.2 Authors"
>>>> 
>>>> *  Authors MUST NOT rely solely on longdesc as the means to provide
>>>> access to information which is essential for the user.
>>> 
>>> DISPOSITION: Not accepted
>> 
>> I understand Joanie's comment on behalf of Igalia to be in line with
>> Principle 4 of the Web Content Accessibility Guidelines:
>> 
>> WCAG Principle 4: Robust - Content must be robust enough that it can be
>> interpreted reliably by a wide variety of user agents, including
>> assistive technologies.
> 
> As I understand it, the longdesc attribute *CAN* be reliably interpreted by
> a wide variety of user agents

The longdesc attribute is not content. The longdesc attribute is just one of many ways to associate two pieces of content. The more ways you associate or provide that content in a variety of formats, the more robust it will be.

>> WCAG Guideline 4.1 Compatible: Maximize compatibility with current and
>> future user agents, including assistive technologies.
> 
> Research has already proven that compatibility with current user-agents is
> itself robust, if not universal.

Robustness implies more than just support for one type of feature. For example, all modern email clients support HTML email, but email that doesn't include an plain text counterpart can't be considered robust. 

>>> Whether a longdesc is essential or nonessential will depend on
>>> circumstance. It will vary among users, and will even vary for the
>>> same user given different circumstances.
>> 
>> The original comment was about requiring AUTHORS to provide robust
>> content for the sake of these USERS. The HTML-A11Y group may have
>> overlooked this point. I assume this response was only discussed in a
>> conference call; I didn't see it discussed on the email list or I would
>> have pointed this out.
> 
> I am not clearly understanding your comment here. Are you suggesting that
> AUTHORS shouldn't provide "robust content" (my interpretation of that phrase
> = detailed longer descriptions when appropriate)?

I am suggesting that any and all W3C specs should encourage authors to provide robust content. Would you still oppose the proposed text if we removed the word "longdesc" and replaced it with something else? 

Modified:
>>>> Authors MUST NOT rely on *any* specific feature as the sole means to provide
>>>> access to information which is essential for the user.

I'm hopeful the modified text illustrates the point that I believe Joanie was trying to make. Her statement is clearly in line with the letter and spirit of WCAG Principle 4: "Content MUST be robust." 

Longdesc is known to not be supported for any users in Chrome and Safari, and only supported for assistive technology users in Internet Explorer. (No need to link to the polyfills again. I've seen them.) Regardless if we agree on longdesc being a *good* feature, it is just one not-particularly-well-supported way to associate content. Therefore, it's wise to recommend that "essential" content MUST or SHOULD be associated in a robust way in addition to longdesc.

>>> The point of the longdesc feature is to make it easy for the user to
>>> access that information, or to readily skip past it as their needs of
>>> the moment may dictate.
>> 
>> There are a number of ways to achieve this, including using a standard
>> link.
> 
> An extremely simplistic answer to a complex problem statement - personally
> it leads me to question if you even fully understand the problem statement.

It's a simplistic (but nonetheless true) answer because we've hashed and rehashed the detailed answers for over 7 years. I don't need or wish to spend any more time on it. You've repeatedly questioned our intelligence and integrity on this matter, but the objection is founded in a fundamental belief that the bolt-on "separate but equal" approach is bad for accessibility. Integrity demands we oppose it.

James

Received on Thursday, 4 September 2014 02:22:00 UTC