RE: 48-Hour Consensus Call: InstateLongdesc CP Update

Sam Ruby wrote:
> 
> At one time Richard participated in a discussion concerning deprecating
> longdesc when aria-describedby was introduced.[1]  I'll note that that
> was over 4 years ago.

I would like to respectfully point out that there is no concept of
deprecation in HTML5 - a position that was established by the former Editor
of the current Draft Specification, and remains in effect today.

	"Since HTML5 has separate conformance requirements for authors and
user agents there is no longer a need for marking features "deprecated"."
http://dev.w3.org/html5/html4-differences/#backwards-compatible 

Given this statement, plus the fact (which has been also repeatedly brought
up) that browsers will continue to "support" @longdesc with the HTML4
DocType, this isn't even an engineering problem, it's an HTML5 authoring
conformance problem. 


> 
> Later Richard and Steve worked on an unofficial aria-describedat
> document.[2]  That was earlier this year.
> 
> Sadly, neither have gotten much traction to date.

ARIA 1.0 is currently in Candidate Recommendation, and so the efforts of
that Working Group appear to have been focused on that goal first.

Even when aria-describedat sees some renewed effort (and I am confident it
will), it is a future and forward looking technique that does not and will
not support the requirement of backward compatibility today (or possibly,
ever). But if we craft an engineered solution that is better than the
current solution, authors will most likely gravitate to the better solution.


But we don't have that solution today, and likely will not have it in time
for the HTML5 REC.


> 
> I'll go further, and say that the most optimistic estimates have HTML5
> going to REC in 2014, and if we could find a way to produce a
> collective
> "we" instead of continuing to refer to a collective "you" that a
> comprehensive solution could be designed by the early next year and
> deployed and tested for interoperability by year end and make it in
> time
> for HTML5.

As many have repeatedly tried to suggest, *the first step* is to remove the
very real authoring hole that would be left by the obsolescence of @longdesc
today. Even if WE had a fully "baked" proposal to add to HTML5 in the REC
timeline by the end of this month, the time it would take to see adoption by
the broad spectrum of stake holders involved would necessitate the need of
retaining an existing solution, while moving forward with that newer effort.

Just because WE can (possibly) develop a comprehensive solution that can be
deployed and tested for interoperability by year end does absolutely nothing
to solve the real issue of deployment "out there" - a global landscape where
IE 6 still won't die (but IE 6 + JAWS will support @longdesc), where much to
the chagrin of Microsoft (I suspect), numerous corporate computing
infrastructures still rely on Windows XP
(http://gs.statcounter.com/#os-ww-monthly-201108-201208 - greater than MacOS
and iOS combined),  and where the cost of upgrading to the latest version of
some screen readers and other AT Tools can cost more than the average PC
laptop available for sale at Frys Electronics. (JAWS Professional: $1,095 -
http://www.freedomscientific.com/products/fs/jaws-product-page.asp) 

These are social problems, and while they too are changing, they don't
change at the same rate as the latest and greatest ideas from key software
developers in Silicon Valley.  A new solution, fully implemented by all of
the browsers, would still take at minimum between 3 and 5 years to be
'solid' enough for industry outside of Silicon Valley to be comfortable
using: government, education, energy, medicine, financial, and travel
sectors, to name but a few. 

I know this, because this is what I encounter professionally every day -
when I started at my new gig they proudly handed me my new laptop, fully
loaded with the corporate build of Windows XP and IE7 (plus no Admin
rights). My daily mandate is to ensure that users of slightly older
hardware/software still have an accessible experience, and this means that
sometimes the newer solutions still are not enough.

I know this is a shared problem, because I talk to others who do what I do
(http://www.meetup.com/Bay-Area-Accessibility-Dinners/,
http://www.accessibilitycampla.org/), and who struggle with wanting to use
ARIA fully today, but are being held back due to poor support "in the wild".


I also know that teaching a technique, new or old, takes time, patience and
effort, because I've done just that for over a decade now, and many of my
colleagues confirm that similar experience (WebAIM, Deque, TPG, Knowbility,
etc.).

I know that a working solution is needed TODAY, because I hear others say
so: Pearson Publishing and NCAM voices have all said so clearly,
unemotionally, and unequivocally.
 
I also know that they ARE using @longdesc to achieve this goal today,
because they are specifically saying so: 
http://lists.w3.org/Archives/Public/public-html-a11y/2012Sep/0210.html
http://wps.pearsoned.com/accessibility/115/29601/7577872.cw/index.html
(Guideline 29 > Show HTML & JS Coding)


Failing to take all of this into account is a critical failure IMHO, and one
that actively hurts accessibility efforts in this Working Group.

The computer engineering solution we can work on (and to be abundantly
clear, I support that effort 100%), it's the social engineering problem that
is being left behind on the shop floor today. Solving the social problem is
complex, and far beyond the scope of this Working Group. The VERY LEAST this
Working Group can do however is not deliberately hurt HTML5's adoption by
these other publishing sectors over something as simple to fix as NOT
implementing an authoring conformance change. Leave that sleeping dog lie,
then we can work on solving the engineering problem. 


Maciej Stachowiak wrote:
> 
> In addition to issues with these specific suggestions, keep in mind
> that a previously raised concern with longdesc is that the corpus of
> available longdesc content in the wild appears to have very high level
> of bad content.

I encourage you or others to provide specific proof of that assertion. 

On one hand, we have professional content producers that are creating
@longdesc content today (Pearson Publishing and the  Government of Canada to
name 2), who, if nothing else, are probably quite good at document
management practices. 
(http://lists.w3.org/Archives/Public/public-html-a11y/2012Sep/0210.html)  

On the other hand, we have a 5-year old blog post from Mark Pilgrim
(http://blog.whatwg.org/the-longdesc-lottery) that alludes to statistics
that Ian Hickson accrued, but was unwilling to publicly share.

Do you have any other "proof" of this assertion? Have you or anyone else
"surveyed" the corpus recently to see if there have been any changes to this
assertion over the past 5 years? (Note: I have not, but given that serious
content publishers are now using this attribute routinely in their work, I
can only surmise it has improved significantly - but feel free to dispute
that claim with proof to the contrary.)


> While folks may disagree on the merits of this
> argument, it seems unlikely that a clever UI idea would change anyone's
> mind about the wisdom of exposing the existing longdesc corpus to
> users.

It would appear that JAWs, Window-Eyes, Opera, iCab and a raft of others
don't seem to agree with that point of view
(http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/Implementati
on). Furthermore, using some of those screen reading tools, users can
consume their web content with browsers such as IE and Firefox (any
version), and be exposed to @longdesc content as a matter of course. All
these tools and tool combinations expose the existing corpus of @longdesc to
their users today, and I challenge you to produce *ONE* "complaint" (bug
report, forum comment, email, etc.) lamenting the alleged pollution that so
concerns you and others. The concern may be legitimate, but it has also been
blown significantly out of proportion.


> 
> So while I appreciate the constructive engagement, it seems unlikely to
> be very persuasive to browser vendors. It does not seem to me that
> their past key concerns were based on lack of UI ideas.

As I read that, I hear "It doesn't matter what you say, or how
constructively you say it, we the browser vendors will not entertain
supporting longdesc". 

I am happy to have you qualify that statement however.


Sam Ruby wrote:

> I'll suggest that the way forward is to put the needs of the people
> with
> disabilities first, and cease what John Foliot is describing as a
> "stare-down"[1].  

If what I am hearing (above) is indeed the case, then an unequivocal stance
such as that is not "putting the needs of people with disabilities first",
it is instead and saying "no"- no discussion, no willingness to re-think or
revisit longdesc, no - period.

There have been some fruitful and positive discussions happening here, by
many people beyond John Foliot, and a good number of those voices have all
suggested an equivalent of what Josh O'Connor wrote:

	"To do this I suggest the partial reinstating of @longdesc (with
warnings is fine with me) and when this is done - effort to gain some
traction amongst friends here that actually moving forward is a good idea
and that we collectively support the re-engineering of a new solution."
http://lists.w3.org/Archives/Public/public-html-a11y/2012Sep/0185.html  


	"In my personal opinion: if we can fix it up such that it is
actually implementable in a UI, and we have at least one or two UAs willing
to give it a try, we can give the attribute another chance."
Silvia Pfeiffer:
http://lists.w3.org/Archives/Public/public-html-a11y/2012Sep/0233.html 


	"I think (hope) we all share those higher aspirations. The thing
that puzzles me is why we'd want to take away the broken bicycle before a
quality car is available? In other words, what would we lose by leaving
longdesc in situ, whilst we focus our collective energies on finding a
robust replacement?"
Leonie Watson:
http://lists.w3.org/Archives/Public/public-html-a11y/2012Sep/0245.html  


I noted earlier, ACTIVE listening is important on both sides of the
discussion. There is *no technical reason* why @longdesc cannot be retained
for now, while we collectively work on a better solution. Refusing to admit
this however is not "putting the needs of people with disabilities first",
but rather has the appearance of an entrenched position on an authoring
conformance requirement that has zero impact on engineering effort going
forward.

JF

Received on Tuesday, 18 September 2012 21:17:26 UTC