- From: Sam Ruby <rubys@intertwingly.net>
- Date: Mon, 17 Sep 2012 19:54:40 -0400
- 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