Re: ISSUE-30 counter-proposal

On Mon, 15 Feb 2010 23:40:33 +0100, Sam Ruby <rubys@intertwingly.net>  
wrote:

> Maciej Stachowiak wrote:
>>  On Feb 15, 2010, at 9:09 AM, Sam Ruby wrote:
>>> Ian Hickson wrote:
>>>> Here's a counter-proposal for ISSUE-30:
>>> Potential next steps:
>>>
>>> 0. Amicable Resolution
>>> 3. Discussion
>>> 4. Call for Consensus
>>> 6. Poll or Vote
>>  Even though it's a day past the deadline, I'd like to request an extra  
>> week to write up a third alternate proposal. My alternative would  
>> propose making the longdesc attribute conforming, but with a mandatory  
>> validator warning.

> I've updated issue-status to reflect that the next step is on you, with  
> a date of 22 Feb.

In which case I will not consider entering seriously into 3. discussion  
until I have seen Maciej's proposal. First because the proposal may lead  
to 0. Amicable Resolution, which is my preferred outcome, and second  
because I don't have time to reply immediately, or in the same day, and  
often not in the same week, to the threads on this mailing list I consider  
relevant to me (due in part to the overhead of tracking the threads in the  
first place ;( ).

In the meantime, some notes which may help clarify things for people  
waiting for me to reply, or Maciej to better understand what motivates my  
proposal (I don't claim they necessarily will help, or even be interesting  
to Maciej, but offer them on the off-chance and because others have been  
asking me what I think about this thread so far).

There seems to be no disagreement so far that there must be *some* method  
for providing a detailed description of a complex image. I assume (as an  
educated guess) that Maciej's proposal will not attempt to counter that  
assertion. If that is indeed a point of consensus, it means we are  
starting from common ground, which is comforting.

And I note that Ian's quote from Josh O'Connor's video, referenced in his  
counter proposal seems to me to misrepresent the video as a whole. I just  
watched it again all the way through, and it seems to me that the very  
clear thrust is that the functionality is important, and that the current  
approach using longdesc is a good (but not perfect) one. (If someone  
really needs captions and there are none available I can probably do the  
transcript in a couple of days and get JohnF to run his magic on them to  
make them available. Let me know. But if I really get into discussion and  
the video is somehow a key reference I think it needs substantial further  
discussion - although maybe we don't need to go there anyway).

For now my proposal stands in the face of Ian's counter proposal, on the  
basis that:

I consider his proposed alternatives either longdesc by another name  
(aria-describedBy), or problematic (explicit text or link in the content)  
both for accessibility (which has to serve a variety of needs - what's  
good for blind people can often be bad for people who have problems  
reading, and although the numbers game is odious there are probably many  
more of the latter) and because it requires certain things of page authors  
that they have shown themselves unwilling to do.

In regards to this topic, Leif Halvard's message  
http://www.w3.org/mid/20100215191057511660.0e34ebf9@xn--mlform-iua.no (and  
his similar message last year) shows some of the reasoning that leads me  
to seriously question the interpretation of the WebAIM's survey results in  
regard to alternatives - points also raised by the video Ian claims as  
supporting his proposal.

The argument on usage numbers isn't particularly compelling to me. It is  
clear that in many cases there are preferable altenatives, and in many of  
the remaining cases longdesc is very rarely used, and in many of those it  
is very rarely done right. Whether this means 1 in 10000 images have  
useful longdescs today (Hixie's numbers, if I remember them right), or an  
order of magnitude either way seems to me unclear for many reasons, but of  
secondary importance to *why* it is the case, and what it really means for  
authors, software, and users, and therefore to those few of us involved in  
specifying HTML 5.

I consider the argument about "invisible metadata" compelling in  
explaining the problem. There are (partial) mitigation strategies  
available. But I consider longdesc is most useful in the cases where  
invisible metadata is *already* a requirement, or in the case where active  
management of metadata is a requirement and that metadata has been  
separated from the content it describes, and that such use cases often  
exist in the real world. I suspect it is relevant that many such cases  
exist outside the world of globally available content, and many of them  
also don't offer an incentive for Search Engine Optimisation (another  
motivation to abuse or misuse "invisible" content).

I therefore consider longdesc an existing, if not well-known, cowpath  
(essentially the one that aria-describedBy treads) for a set of real-world  
use cases where a real alternative has not been offered, that it does  
little damage and some real good, and that the cost of removing it is  
higher than the cost of retaining it in HTML 5.

If we specify longdesc it is useful to describe when it is very valuable,  
when it is not very valuable (such as where an image can be described in a  
couple of lines and already has a useful alt attribute - in that case its  
major value would actually be to image management and thereby indirectly  
to authors, rather than directly to readers), and when it is a bad idea  
(IMHO, in some of the cases where it is used wrongly, and when  
aria-describedBy has been clearly specified and is a practical replacement  
- something that will take some years in all likelihood).

I also think that my proposal needs to be updated to describe some  
handling for common error cases - the mitigation strategies I mentioned  
above. The simplest mitigation is to make the value of the attribute  
available in the case where it is not a valid URL reference, since a  
number of the cases where it is used incorrectly are actually descriptions  
of the image - i.e. the information the user is looking for is actually  
there, albeit badly encoded. This needs to take account of the results of  
such implementation and not promote mechanisms that merely perpetuate the  
problem.

For now, I look forward to seeing what Maciej comes up with.

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 Tuesday, 16 February 2010 01:48:11 UTC