RE: example spec text for longdesc

Jonas Sicking wrote:
> 
> And yet data shows that the vast majority of people get it wrong.

s/get/got

> 
> http://wiki.whatwg.org/wiki/Longdesc_usage
> http://blog.whatwg.org/the-longdesc-lottery
> 
> Do you have data showing otherwise?

Jonas, we've never seen that data. We have instead assertions from 2
Google employees who state that they looked at the data, and formed their
opinions (without the opportunity to question their agenda or bias).
Nobody has had the opportunity to review the data, the methodology or the
final outcome - we've been asked to accept it on faith. For a process that
places a great deal of stead on "proof" this is one area where the proof
is hard to discuss, as nobody but Ian and Mark have seen it.

> 
> A terrifyingly small percentage of the pages on the web pass a
> validator. The far vast majority of pages doesn't even nest their tags
> correctly. The sad truth is that while we can do what you suggest,
> it's not going to have a big effect because people simply doesn't
> consult validators to a large degree.

So, based upon this, we can continue to use @longdesc in HTML5, since it
still works in consuming user-agents today, and the only 'issue' is that
the pages will not be conformant? Since by your statement above this
really doesn't matter - that validation alone has little impact - what are
we arguing about exactly? What is the point of making @longdesc obsolete
if the majority of authors don't care whether their documents are
conformant or not? What exactly does making @longdesc obsolete achieve?

> 
> So far I have seen no reason to believe that longdesc is going to be
> used in a much better way the next 10 years than it has the past 10
> years.

Given the time-stamp on your email, I will assume that you did not read my
previous email on this point. Are you prepared to accept that if
professional publishing companies and governmentally funded programs are
interested and ready to use @longdesc that they will most very likely use
it correctly, and that 10 years from now @longdesc *will* be in a better
way? Or are you ready to state that they will likely mess things up the
same way that uninformed hand-coders did in the early days of HTML4 -
problems that polluted the secretive Google data?

 
> Indeed. I'm not saying that the use case doesn't exist. I'm saying
> that it's not the majority case. We should optimize for the majority
> case while making the minority case possible.

Supporting or failing to support @longdesc has no impact on the majority;
providing support for @longdesc makes the minority case possible. You are
now arguing for the support of @longdesc. :-)

> 
> First off I'm not proposing aria-describedat. I'm suggesting fixing a
> problem in aria-describedby.

Aria-describedat is in fact the high-level idea I referenced in my
previous email, and is a possible addition to ARIA once ARIA clears
Candidate Recommendation (and we can start working on a dot release).
Essentially it walks like the duck, quacks like the duck, swims like the
duck, but we call it a canard instead so as not to offend the duck-haters
who somehow believe that ducks are harmful. There are some of us prepared
to pursue that route if necessary, but really, why? Perhaps we can instead
create aria-longdesc and be done with it? It all feels like un-necessary
gamesmanship to me.

> 
> Anyhow, I still haven't heard any arguments against fixing
> aria-describedby.

I would suggest that the same could be stated for @longdesc. If, as some
assert, @longdesc requires "fixing", what can we do to fix the problems?
I've ruminated on that question long and hard, and have solicited help in
providing proof-of-concept illustrations to show possible ways on how to
fix @longdesc moving forward, resulting in engineers and developers
developing solutions in JavaScript that fix the issues brought forward.
Jonas, have you looked at any of those examples? Can you provide
constructive feedback on them?

Cheers!

JF

Received on Saturday, 26 March 2011 05:21:35 UTC