Re: Alternate proposal for ISSUE-30 longdesc

On Feb 22, 2010, at 4:22 AM, Jonas Sicking wrote:

> On Mon, Feb 22, 2010 at 3:58 AM, Maciej Stachowiak <mjs@apple.com>  
> wrote:
>>
>> Summary: Make the longdesc attribute on img elements conforming,  
>> but with a
>> required validator warning. (Open issue: should longdesc be  
>> considered
>> "obsolete but conforming" or just conforming to a warning? I'm  
>> willing to go
>> with whatever the WG most prefers, the best option may be to  
>> ultimately make
>> it consistent with the summary attribute.)
>>
>> http://www.w3.org/html/wg/wiki/ChangeProposals/LongdescConformingWithWarning
>
> As far as I can see, this change proposal only contains two
> "pro-longdesc" arguments:

I personally do not think the case for longdesc is terribly  
compelling. I wanted to write this proposal so we have a middle-ground  
position on the table, that is a compromise between fully  
noncomforming and fully conforming. We can examine whether that middle  
ground satisfies more people than either of the extremes. If it cannot  
draw more support than either of the previous proposals then I will  
likely withdraw it.

As for my own view, I would be satisfied to make longdesc completely  
noconforming, I think conforming with a mandatory warning should be  
sufficient to address the problems, without being overly disruptive of  
past attempts to make content accessible. I think it would also allow  
us to make it fully noncomforming in a future version of HTML, once  
authors migrate to aria-describedby or similar techniques.

>
> The first one is
>
> "A handful of sites (organizations for the disabled, government
> entities, nonprofits, etc) go far beyond the norm in trying to provide
> a good accessibility experience. They may be relying on longdesc to
> improve the experience, and it would be disruptive to immediately make
> such content nonconforming."
>
> This seems to me to be an argument to allow implementations to
> implement it, but as far as I can see is not an argument to keep it
> valid. Compare for example to the bgcolor attribute, many sites use
> it, and implementations are allowed to implement it, but it is still
> specced as non-conforming and I don't hear anyone argue that it
> shouldn't be.

bgcolor was deprecated in HTML4.01, "Deprecated" being the closest  
status HTML4.01 had to HTML5's "Obsolete but conforming". So my  
proposal would actually treat longdesc the exact same way we have  
treated bgcolor, just one spec cycle behind.

I do believe that other presentational attributes from HTML4.01 are  
nonconforming in HTML5, even though they were not previously marked  
Deprecated. An example would be the "height" and "width" attributes on  
the <img> element. I would distinguish that case because  
presentational attributes in general have been discouraged for a long  
time. Furthermore, it is generally considered that even the intent of  
presentational attributes is, in retrospect, a bad one. In general,  
there isn't a valid reason to use them instead of using a stylesheet,  
even in pre-HTML5 content. But longdesc had a beneficial intent, even  
if the outcome was often poor due to the design details in the  
feature. So it's possible someone may be using img@longdesc well, but  
we would not consider any use of img@height to be using it well.

>
> The second argument in the change proposal is:
>
> "Some laws, regulations and organizational policies may refer to
> longdesc by name."
>
> Using this as argument for keeping any feature seems very sad to me.
> The idealist in me strongly prefers to add accessibility features
> based on what helps people with accessibility needs, rather than what
> local laws say. I realize that we need to be practical and not just
> idealist, however I think the argument needs to be stronger than "laws
> may exist".

I concede this is a pretty weak argument by itself.

> So this seems to leave us with the a

Looks like this sentence got cut off.

Regards,
Maciej

Received on Monday, 22 February 2010 12:45:11 UTC