Re: My case for the obsoletion of longdesc (Was: 48-Hour Consensus Call: InstateLongdesc CP Update)

Hi James,

I have made my antipathy towards longdesc clear in the past, the
majority ( i think) of the taskforce can live with longdesc back in
the spec or not in the spec. I could live with it back in the spec, I
could live with it not in the spec.

There are  substandard features in the spec, there are features that
are not yet supported, there are features that not yet accessibility
supported.  if longdesc is put back in the spec i would consider it
appropriate to have a warning about its use. I would consider it  a
feature at risk CR wise unless its interoperable support in browsers
is improved. I would consider it a failed feature unless it is
meaninggfully supported across the major browsers and AT. i.e. if
browsers such as IE and webkit based browsers, and AT such as
voiceover and NVDA do not implement meaningfull support for it.


regards
SteveF

On 15 September 2012 10:29, James Craig <jcraig@apple.com> wrote:
> I realize this is a heated topic, one with many facets and valid
> perspectives, and so I ask that you consider my arguments with an open mind,
> regardless of your previous conceptions in this debate.
>
> I also feel I should introduce myself, as I'm new to the HTML Working Group
> and the HTML Accessibility Task Force, though I am not new to web standards
> or accessibility. Despite my opposition to longdesc, I assure you that I
> vehemently evangelize the importance of accessibility, and I believe my
> record speaks for itself. I've been involved with the W3C for nearly a
> decade; I have been a contributor to CSS 2.1 and WCAG 2.0, an editor of ARIA
> 1.0, and most recently an editor in the newly formed IndieUI Working Group.
> I have worked professionally on accessibility part-time for more than a
> decade, and I now work full-time in the Accessibility Engineering team at
> Apple. I have volunteered with organizations like Knowbility and the Web
> Standards Project. I have spoken on the importance of accessibility and
> universal design at conferences like SXSW, Access U, and WWDC. I firmly
> believe that no product is complete until it's been made as accessible as
> possible to everyone, regardless of their level of ability.
>
> On Sep 13, 2012, at 10:10 AM, Janina Sajka wrote:
>
> The HTML-A11Y Task Force has twice resolved support for the InstateLongdesc
> Change Proposal on Issue-30 Longdesc reconsideration, most recently as
> logged at:
>
> http://lists.w3.org/Archives/Public/public-html-a11y/2011May/0399.html
> http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc
>
> As we expect reconsideration of the Issue-30 decision on longdesc will be
> taken up by the HTML-WG soon, the Task Force Text Subteam has provided a
> narrative wrapper for this CP which is intended to serve as concise
> orientation at the top level of the CP, leaving detailed evidence and
> argument to subpages.
>
> http://www.w3.org/html/wg/wiki/Talk:ChangeProposals/InstateLongdesc
>
>
> Despite the importance I place on accessibility, I am hereby voicing my
> opposition to inclusion of the longdesc attribute in HTML 5. I believe
> longdesc should only be reinstated in HTML 5 with the caveat that it be
> denoted as obsolete or deprecated. I will attempt to refrain from using a
> few subjective, difficult-to-prove arguments like the claim that longdesc is
> not commonly used, or that it was a bad design decision from conception.
> Instead I will mention the reasons I believe have not been accurately,
> completely, or convincingly addressed on the HTML Accessibility Task Force
> wiki page. Those reasons are as follows:
>
> 1. *There are existing, valid alternatives to longdesc in HTML 5, some of
> which work in implementations today.*
>
> Here are several: http://cookiecrook.com/longdesc/
>
> To the best of my knowledge, one of these approaches (the iframe example
> listed at http://cookiecrook.com/longdesc/iframe/) works in all major
> implementations today, which is to say that it is much better supported than
> longdesc itself.
>
> 2. *The separate-but-equal approach always falls short of being truly equal,
> and using this approach for accessibility is no exception.*
>
> As a physical example, compare a wheelchair ramp or curb-cut, used by
> everyone, to the expensive, clunky, separate-but-not-really-equal
> alternative, a wheelchair stair lift. For those of you unfamiliar with these
> terms, I've included some links to images below.
>
> http://www.google.com/search?q=curb+cut&tbm=isch
> http://www.uklift.co.uk/stairlift/wp-content/uploads/2009/08/wheelchair_stairlift_tsl1000.jpg
>
> As a digital example, I'll refer to this opinion piece about the Amazon
> Access web site. Please note that this reference is not intended to be
> political commentary about Amazon. It's just a prominent example and the
> article does a good job of explaining the cons to this approach.
>
> http://www.wired.com/techbiz/media/news/2001/12/49195
> http://www.amazon.com/access
>
> I am in favor of the general idea of providing structured accessible
> content, but I believe the best way to do that is to make the content itself
> accessible rather than linking to a separate alternative. As demonstrated in
> the examples above (e.g. embedded SVG), image content in many formats can be
> made directly accessible, which is a much better approach than either
> longdesc or the hidden iframe example. No one is clamoring to retain the
> mediocre accessibility of the <embed> element, because the accessibility of
> the <video> and <audio> elements provides a much better solution, especially
> when displaying media types that allow embedded accessible content like CC
> or SDH for the deaf and hard of hearing, and Described Audio tracks for
> persons with vision impairments. No one is clamoring for longdesc support of
> MathML, because it is defined in an accessible manner, despite the fact that
> support for MathML accessibility is varied in implementations today.
>
> I would even support a recommendation to include a structured long
> description alternative in the embedded metadata of raster image filetypes,
> such as PNG. Some of you may recall that Fireworks used to store its layer
> and path editing information in PNG metadata in much the same way.
>
> 3. *The longdesc attribute will never be removed from HTML 4.*
>
> Previous versions of HTML are set in stone (virtually of course). Once a
> document reaches Recommendation status at the W3C, it does not change. Ever.
> Web authors or publishers can still use a valid HTML 4 doctype for their
> creations, and those documents will always be conforming. Likewise,
> rendering engines and assistive technologies are allowed and encouraged to
> provide the best support possible, even in the case of non-conforming
> documents. The comparatively few implementations with existing support of
> longdesc are not required to drop support for it, and no one has suggested
> that they should.
>
> 4. *Progress is a goal we all share.*
>
> Software and hardware life-cycles are ever-changing. Web software is no
> exception, and neither is the native software that supports it, like
> browsers and screen readers. We live in an amazing world, and technology is
> progressing more quickly than at any time in the past. We no longer use
> punch cards to program computers. We no longer use serial ports and floppy
> drives. We no longer use the bgcolor attribute, or the <blink> and
> <basefont> elements to define style. We no longer use the <applet> or
> <noframes> elements to define functionality. A major part of software
> progression is that new development is focused on better ideas that arise,
> and continued support of older technologies is allowed to drop from newer
> implementations, while it's free to remain in existing implementations of
> the older standards.
>
> My belief is that this drawn-out, years-long debate over longdesc tarnished
> the reputation of web accessibility opinion within the web standards and
> technology communities, because longdesc itself was not worth the effort
> that many of you expended to save it. I previously tried to avoid the
> discussion because there are so many more important accessibility
> discussions on which I'd rather spend my time. There is a wealth of
> knowledge represented in the W3C working groups; imagine what amazing new
> things we could have accomplished in the time we've spent on this topic.
>
> As one of my managers likes to say, "I can fight for this if you need me to,
> but I only have so many silver bullets." Let's not waste any more of our
> collective silver bullets on longdesc, when there are much more important
> accessibility decisions to be made, and so many more amazing new
> technologies waiting to be made accessible.
>
> Let's move the Web forward as we are chartered to do. Let's work together to
> make the Web as accessible as it can be, instead of worrying so much about
> hanging on to the mediocre technologies of the past that we jeopardize
> forward progress towards better accessibility for everyone.
>
> Thank you for reading,
> James Craig
>
> PS. It is with some reluctance that I join this debate. I originally avoided
> discussing longdesc publicly, as I considered it an online "holy war" better
> left to those who felt more strongly than I, but I've come to the conclusion
> that I can no longer abstain. Like many of you, I have a busy schedule, but
> I will, to the best of my ability, read all points raised in this thread,
> and respond to all I can. I also realize not everyone can post to the HTML
> list, so if you feel I should be made aware of viewpoints expressed
> elsewhere, please click the reply-to link from the W3C email list archive
> page (this will retain the proper thread headers so I don't filter your
> message) and if needed, add me as a recipient directly. At the very least,
> ping me with a link on Twitter at @cookiecrook. Thanks.
>



-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html

Received on Sunday, 16 September 2012 09:29:56 UTC