W3C home > Mailing lists > Public > public-html-a11y@w3.org > September 2012

Re: 48-Hour Consensus Call: InstateLongdesc CP Update

From: Sam Ruby <rubys@intertwingly.net>
Date: Mon, 17 Sep 2012 19:54:40 -0400
Message-ID: <5057B840.60009@intertwingly.net>
To: public-html-a11y@w3.org
On 09/17/2012 07:32 PM, John Foliot wrote:
> Maciej Stachowiak wrote:
>>> If that were only true Josh.  We've had a "solution" for this issue
>> for over
>>> a decade in the previous Specification, and have not seen any
>> implementation
>>> in browsers worth noting.
>> Browser vendors generally make implementation decisions based on
>> whether a feature seems likely to benefit end-users and content
>> authors, not based on what is in what spec. Vendors are open to
>> persuasion, of course.
> Yep. See my response to Silvia.
>>> It comes down to 2 paths forward as I see it: one is that we mandate
>>> something that browsers will continue ignore, or we actively engage
>> them in
>>> crafting the solution, one that meets all of the user requirements.
>>> I think it's fairly obvious which I hope will be chosen - the "which
>> group
>>> dictates to the other" approach is not working. (I will also note in
>> passing
>>> that active listening is a requirement on BOTH parts)
>> I think you are right about that. Unfortunately, the conversation still
>> seems to be on mandate-or-no-mandate rather than engagement in crafting
>> a solution.
> I will be so bold as to suggest that the sticking point is over the
> obsolescence of @longdesc. Remove the threat of that, and then the
> discussion can turn to getting the real work done - members of the larger
> accessibility community are both trying and appear open to that effort. In
> my opinion however, until that irritant is addressed the dialog remains
> strained.
> To end a stare-down, somebody has to blink, it's that simple. If the
> engineers truly want to work on a "better" solution, leave the "less better"
> one in place until you have the better one solved.

I will suggest that the word "you" in this sentence is a bit unfortunate.

> This has been the core of
> the argument since day one.

If that's the case, this sounds to me like a classic XY-problem.[1]

IMHO, The core of the argument should instead be that we collectively 
want a solution to the long description problem that browser vendors are 
willing to implement.

If we were to look at it that way, we've made tremendous progress: we've 
clearly established not only that there is a use case for long 
descriptions, but also that some ability to include richer markup than 
simply flattened plain text is highly desirable. What the precise 
limitations on this markup needs to be, whether this should be limited 
to out-of-band or inline solutions, and whether this should be via a 
HTML attribute or a part of ARIA remain legitimate points of technical 
disagreement at this point.

I also think that we would likely come to rapid agreement that this is 
needed for more things than images.

> JF

[1] http://www.perlmonks.org/?node_id=542341
Received on Monday, 17 September 2012 23:55:08 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:30 UTC