Re: Alternate proposal for ISSUE-30 longdesc

Consolidating some replies...

On Feb 22, 2010, at 6:12 AM, Charles McCathieNevile wrote:

> On Mon, 22 Feb 2010 13:44:37 +0100, Maciej Stachowiak  
> <mjs@apple.com> wrote:
>
>>>> http://www.w3.org/html/wg/wiki/ChangeProposals/LongdescConformingWithWarning
>
>> 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.
>
> Unlike Hixie's proposal, I think that this proposal can turn into  
> something I can support.

Do you think changes are needed for you to feel comfortable supporting  
it?

>
> I don't think the statement in the Wiki that longdesc must refer to  
> an external page is accurate, and I would in any case change my  
> change proposal to explicitly allow for longdesc references to be  
> within the page (my understanding is that this is already allowed).  
> I do consider that in the long term longdesc should be phased out in  
> favour of a more generalised solution to the problem it solves -  
> something like aria-describedBy, but with a better way of handling  
> descriptions that *are* external references.

Will current assistive technologies correctly handle a longdesc value  
that is just a reference to a fragment on the existing page? Is it  
actually used that way in content? (I don't recall any examples of  
this being cited in any of the surveys done.)

I suspect it's better to encourage authors to use aria- 
describedby="foo" instead of longdesc="#foo".

>
>>> 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.
>
> It is not axiomatic that laws, regulations and organisational  
> policies are wrong. Many things done for accessibility begin as one  
> of those things.

I think Jonas's point was that they are not necessarily right.


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

> On Mon, Feb 22, 2010 at 4:44 AM, Maciej Stachowiak <mjs@apple.com>  
> wrote:
>>
>> 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 argument brought forward in the change proposal was "sites are
> using it". However we know that sites use a lot of other attributes
> that are marked as non-conforming. Such as many presentational
> attributes. However it doesn't seem like this WG has elsewhere
> considered this to be a strong enough argument to keep a feature in
> the spec.

The argument I am trying to make, but which I perhaps phrased poorly:  
Some sites  may be using this attribute for a valid purpose and in a  
valid way. Thus, we should transition them more gently to a better  
solution.

> My feelings as an implementor with many users is that existing usage
> of a feature is an argument to allow, or even require, implementations
> to implement a feature. However it does not seem like an argument to
> keep the usage conforming.
>
> It seems like you are here additionally arguing that making a feature
> non-conforming, without first publishing one version of HTML where the
> feature is deprecated, is bad. If you are indeed making this argument
> then it might be worth putting in the change proposal.

I did not intend to make that particular argument. I just reviewed the  
record on bgcolor, as a point of comparison. It does seem like many  
features dropped in various HTML versions were first put in an  
intermediate state. I do not think it is mandatory to do that or bad  
to fail to do it.


> 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. 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.


Regards,
Maciej