RE: 48-Hour Consensus Call: InstateLongdesc CP Update

Joshue O Connor wrote:
> 
> So the questions are:
> 
> 1) Why did it fail? From the perspective of both the end user
> experience and also browser implementation.

Hi Josh,

[Standard Disclaimer - the following is my personal opinion and does not
reflect the thoughts of any particular WG or Task Force, my employer, or
anyone else.]

I'll start by asking why you feel it failed from a user-experience? 

While I will agree that it is hardly the most sought-out aspect of an
accessible web page, I have heard first-hand (and second-hand) anecdotal
evidence that when deployed, non-sighted users did avail themselves to
longer text descriptions. One young woman told my good friend Catherine Roy
that without long descriptions (supplied via @longdesc) she didn't think
should would have been able to complete an online course she took. While it
is hardly mountains of evidence, it *does* speak to the desire and need to
have longer textual descriptions, and their benefit. Given the choice of
using @longdesc today as it is supported by, say JAWs, versus nothing at all
is not much of a contest.


Stepping back however, I think we have two types of failures non-the-less. 

The first one is situational. When @longdesc was first introduced, it was
quite likely way ahead of its time: back in the late 90's when @longdesc was
added to the HTML4 specification, we had no implementation at any level. We
also (as accessibility advocates) were struggling with the "why" question a
lot more (and far less with the "how"), and so just getting authors to
consistently add @alt text was an uphill battle. (Some days it feels that
still hasn't changed - but I know in my heart and head that it has).

As a result, "we", the accessibility advocates/teachers/specialists focused
on lower-hanging fruit, there was after all (sadly) plenty to pick. We
rarely talked about the need for longer textual descriptions (even though
the need existed then as it does now), and in part, without any
implementations to actually support @longdesc, it often got left on the
cutting room floor. That was unhelpful.

Back then, the majority of web content was crafted, one html document at a
time, often using rudimentary tools (that often did a horrible job of
mangling HTML), or hand written in a text editor. The entire work-flow of
creating sites, and managing cross links (etc.) was laborious and tricky -
and so there are instances where the link that is the @longdesc became
brittle - broken or out of date being the outcomes that have been cited.

But authoring tools became better, site management overall became better,
more accurate, and able to scale to the rapid growth of the web. The
introduction of content management systems and dynamically assembled web
pages, where "content" was but a data-base entry also eased the burden.
Today, most authoring tools, including those used in popular content
management tools have the ability to create and maintain @longdesc content.
(http://john.foliot.ca/wysiwyg_longdesc/)

We also began to see some support from the tools that users use, with a
significant gain coming from JAWS when that software began to support
@longdesc. Research has shown that there are other tools out there as well
that support @longdesc today, and "shim" solutions such as browser
extensions and jQuery modules that seek to improve the situation for those
users who need and want longer textual descriptions.

Finally, to be both frank and introspective, I think that WAI/PF was so
focused on getting WCAG 2 done that many involved with that effort were
somewhat narrow-focused - a lot of stuff was happening out there while we
were struggling with that colossal effort, and we missed some opportunities
that perhaps we shouldn't have.


The second failure however is a technical one. Throughout that same time
period that you and I spent pleading for @alt and eliminating nested tables
8 levels deep, we witnessed (and lived through) "The Browser Wars", where
the two dominant players were constantly looking to out-pace and one-up
their competition, deploying all manner of 'innovations', from the extremely
useful (JavaScript), to the frivolous (blink/marquee). Pushing for support
of an 'esoteric' HTML4 requirement that was not getting a lot of demand
resulted in a situation where the browsers did nothing. I don't say this to
be overly critical - I get the situation - but I think that this is also an
honest assessment: had browser vendors done something useful with @longdesc
previously, I don't think we'd be stuck today. 

All of the above created a chicken-and-egg scenario that we are trying to
bust out of. We've had some modest success in getting content creators to
start actually providing longer textual descriptions (as Laura's curated
list attests), we've seen the authoring tools step up and do their part, and
we have content creators (ePub in particular) now stating that they *will*
do the heavy lifting, just tell them what tool to use that will deliver the
results today.


> 2) What can we do to avoid these failures and improve upon a method to
> support the original use cases that it was designed to accommodate? The
> inception of @longdesc wasn't pulled out of the sky for no good reason.

In my opinion, the single most critical thing we need today is a commitment
from the browser vendors that they *will* do something to support longer
textual descriptions, and the use-cases that have been brought forward. 

Whether that is by supporting @longdesc (paving cowpaths), supporting an
aria-based solution (describedat -
https://dvcs.w3.org/hg/aria-unofficial/raw-file/tip/describedat.html), or
creating a new native HTML attribute (@magicbean), without support from the
browser vendors we will only get so far. As it stands today, we have
moderately decent support from some screen readers and browsers (with others
providing no support, for their own reasons) for one solution, we have an
emergent proposal that without vendor support will be a wishing and hoping
document, and we have an HTML specification that *MUST* ship soon - the
deadline is palpable and urgent.

I still have faith in @longdesc. I believe that the HTML5 working group
needs to chart out a managed transition from "the not very good" to the
"significantly better" without breaking existing content on the web, and by
not punishing content creators who want to use HTML5, and be conformant, and
still provide longer textual descriptions. I believe that the ideal of
ensuring that HTML5 is backward compliant is justification enough to retain
@longdesc now, and then we can turn to making things better - something you,
James and I all share in common.

We also need time - something that HTML5 "The Standard" is in very short
supply of. We need time for authors, and authoring tools, to adapt to
whatever enhanced solution we craft. @longdesc is supported by the majority
of authoring tools already, and some screen readers as well, and/but if we
are to move towards a newer, better attribute (or other solution, such as
James' idea of embedded content in the image format itself) we will still
need time for that solution to work itself out onto the larger web -
upgrades to browsers, to screen readers, to authoring and other production
tools, authoring guidance, and more. (There also needs to be a recognition
that the hardware and software that the world uses to access the web is not
as modern as that of today's cutting edge web engineer.) 

But most of all, we need the browsers to commit to helping us solve this
problem. We cannot do it without them, and by the same token I personally
don't think they can afford to ignore the use-cases brought forward - which
recent conversations indicate an awareness of (and a willingness to start
talking). For all its rancor over the past 4 or 5 years, the 1 positive
outcome has been an increased awareness of the need for, and the requirement
to provide, longer, semantically rich, discoverable on-demand textual
descriptions of complex images.


> 
> Before we do this however, we need to consolidate our position
> internally. 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.

Despite what many think, I've actually stated essentially that for quite
some time. 

We need an orderly transition from where we are to where we want to be, and
unfortunately that is not the situation we are faced with today. It feels to
me like we've been backed into one of 2 corners - obsolete @longdesc
outright *right now* with no functional replacement, or preserve it without
working on the problems we have with @longdesc, a status quo that many
engineers are unhappy with, which then leads to accusations of "...worrying
so much about hanging on to the mediocre technologies of the past." -
failing to also acknowledge that improving mediocre to excellent is also a
possibility. For example, it seems to me this is what Apple did to the Cell
Phone... (I also personally think that this is not what Laura's CP is
advocating - those actively involved in that initiative have always said
that we need to improve @longdesc support, but to do so we first must
reinstate it.)

I strongly support the work that Steve and Rich have started on with
aria-describedat, but I also worry that without the participation of
engineers from the various browser vendors becoming actively involved, and
banging out an *implementation* solution that address the problems that have
been articulated, that effort will be for naught as well.

Ultimately it's not the "attribute" that is flawed, it is everything else
around it that is malfunctioning. What we call the mechanism is far less
important than how the mechanism is supported by the browser vendors. *IF*
collectively we can craft a better solution (with a different name if that
is what will make others happy) that addresses everyone's needs, then
authors will embrace that solution - not immediately, but ultimately, until
we reach the point that @longdesc will simply fade from sight, just like
blink and marquee have. 

(As an aside, I am personally not keen on a 'warning', because if the author
creates conformant @longdesc then it would need to be accepted as correct.
Not perfect, but not broken either, which is what a warning suggests.
However, that is hardly the biggest sticking point before us.)


> 
> Without these simple steps, I strongly feel the energy that will be
> dissipated in appeasing what have been previously irreconcilable views
> will be utterly divisive and counter productive.

I remain hopeful if cautious.

JF

Received on Monday, 17 September 2012 20:01:28 UTC