Re: Alternate proposal for ISSUE-30 longdesc

On Feb 22, 2010, at 6:48 AM, Jonas Sicking wrote:

> On Mon, Feb 22, 2010 at 6:30 AM, Maciej Stachowiak <mjs@apple.com>  
> wrote:
>> On Feb 22, 2010, at 6:06 AM, Jonas Sicking wrote:
>>> Personally I'm not a big fan of this argument either. I much  
>>> prefer to
>>> have a feature be conforming if there are technical reasons to do  
>>> so.
>>> In this case, if it helps accessibility.
>>
>> I think the specific situation here is that for sites using it,  
>> we'd like
>> them to thoughtfully review what they are doing, not just rip it  
>> out or
>> replace with a poor aria-describedby in a panic over losing their
>> conformance badge.
>
> Do you feel the same way about ripping out other attributes that are
> going from conforming to non-conforming? Such as the width/height
> attributes?

No, because (a) authors were wrong to use them in the first place, and  
(b) it's unlikely you'll make a subtle undetected mistake when  
changing from presentational attributes to CSS; if you screw it up, it  
will almost certainly be obvious even to casual inspection.

> Also, no one is forced to make any urgent changes. I would imagine
> that most people that care about conformance will transition to HTML5
> at a pace they see fit. After all, it unlikely that HTML5 will
> transition to REC any time soon given the the requirement of two
> interoperable implementations.

Indeed, but at least some people seem to find fully nonconforming  
status to be a problem, even at this early draft stage.

>> For the sites using it properly (granted, a tiny minority
>> of all sites using longdesc), we would be breaking their valid  
>> reliance on a
>> previously encouraged feature. It seems pretty much analogous to  
>> the summary
>> attribute, where we are also (in the current spec) discouraging it  
>> in favor
>> of arguably better solutions. I think this approach will be more  
>> likely to
>> help sites make the transition effectively. In that regard, I think
>> conforming-with-a-warning will likely improve accessibility over
>> nonconforming status.
>
> I don't understand how helping people out with the transition to using
> things other than longdesc is connected to longdesc being conformant
> or not. I.e. wherever we put such transition advice, be it in spec or
> in validators, seems like we could put it there either if longdesc is
> conforming or not?


I think the value of making longdesc be conforming with a warning  
(instead of nonconforming) is that thoughtful authors are more likely  
to heed the advice. Beating them with the nonconforming stick may make  
them feel jerked around ("I did what was recommended for  
accessibility, and now it's invalid?!?") and thus potentially less  
open to constructive persuasion. I concede I could be wrong.

Let me turn it around. What do you think is the value of making  
longdesc nonconforming instead of conforming with a warning? (I  
mentioned what I thought was the downside of conforming-with-a-warning  
compared to nonconforming in my Impact section, but I am curious what  
you think.)

Regards,
Maciej

Received on Monday, 22 February 2010 15:05:33 UTC