Re: Expanding longdesc use

Hi Laura,

On Fri, Mar 16, 2012 at 4:10 AM, Laura Carlson
<> wrote:
> The name is important for backwards compatibility. I considered
> seriously considered renaming the attribute but realized that breaking
> both compatibility with existing best practice (and documentation of
> the same), as well as requiring a wide range of tools, content, and
> authoring guidance to be updated in order to achieve compatibility
> with a replacement for longdesc - for something meant to solve the
> same problem, is an intolerable cost. It would be an illogical undue
> burden and unacceptable to authors and organizations that have already
> made investments in the use of longdesc.

None of those tools would break. Their authoring has only been
implemented for the img element. They have to be changed anyway to
adapt to their use on new elements. Changing the name of an attribute
in tools is really not a big issue, when you have to touch the
codebase anyway. And as for the authored content - @longdesc is in the
spec and any tool/browser that wants to be backwards compatible has to
support it anyway, no matter what the HTML5 spec says.

So, I don't share the concern about backwards compatibility.

If indeed we get better buy-in for a new attribute, I really see no
need to hold on to an attribute that has been perceived as a failure
by many, no matter whether reality supports that perception or not.

> Longdesc is implemented in authoring tools [1], assistive technology
> [2], and user agents [3]. A renamed longdesc would have zero
> implementations.
> Even when/if tools do come along, not everyone will be able to afford
> to throw away existing tools to get the newest model. People rely on
> existing tools to author and test long descriptions [4]. It has been
> well established that WYSIWYG tools simplify authoring longdesc. An
> array of tools exists to author longdesc [5] and to check that the
> longdesc works [6]. Two browsers (Opera and iCab) natively support
> this testing (three if we count Home Page Reader which is currently
> still in use in Japan). Longdesc has a growing arsenal of extensions,
> configurations, and plugins that are used for testing. A renamed
> longdesc will have zero existing support tools.
> Longdesc-related features in existing authoring tools should continue
> to output valid content: both authors and users have perfectly
> reasonable expectations that longdesc will continue to be supported by
> existing tools, and will continue to have its current (i.e., intended)
> effect in existing content.

None of these have to change for longdesc. They just have to add the
new support for other elements under whatever attribute name.

> It has been substantially evidenced via the documentation of over
> FIFTEEN HUNDRED real world examples [7]  of longdesc that authors do
> indeed use longdesc in practice to improve accessibility. This is a
> non-negligible number of examples elements that utilize longdesc in
> meaningful ways.

Honestly, 1500 is a very small number. I am considering transcripts
for videos that could be created from captions on YouTube
automatically and there are millions of them. You should be thinking
in similar numbers. You want to achieve millions of images to be
marked up in this way.

> All of the images in those examples would be
> significantly less accessible (some even totally inaccessible) without
> it.


> By using longdesc these real world examples provide
> programmatically determinable long descriptions of content in
> accordance with a target audience's needs.

Agreed and none of this will break.

> For a page that is fully accessible and compliant today to suddenly be
> flagged as non-compliant is counter to the backwards-compatibility and
> interoperability objectives of HTML5.

It continues to be compliant to HTML4, which is the backwards
compatible part of it. If somebody updates those pages to make them
HTML5-compliant, they can easily change the name of the attribute,
too, among with the other things that they have to change to become
HTML5 compatible. I'd only put up a depreciation warning if a new
attribute was in fact decided on. Until then, I agree that it should
be compliant. In fact, with the deprecation warning we can even
encourage people to provide long text equivalents for all their
complex elements on the page and potentially tell them to fix up the
markup if it was wrong.

> During the past year alone, numerous organizations such as the A11y
> Bugs Project, Aboriginal Affairs and Northern Development Canada, Axel
> Schafer, SPD Abgeordneter im Deutschen Bundestag fur Bochum, CSS
> Squirrel, Canadian Department of Justice, Canadian Space Agency,
> Correctional Service Canada, Department of Transportation (Taiwan),
> Courts Administration Service (Canada), Daegu Metropolitan Office of
> Education (South Korea), Office of the Superintendent of Financial
> Institutions Canada, Elections Canada, Environment Canada, Griffith
> University (Australia), Hipocampo, HTML Accessibility Task Force,
> HTML5 Multimedia, Kyungpook (South Korea), Marine National Park
> (Taiwan), Michigan State University, National Center on Birth Defects
> and Developmental Disabilities, Object Description, Ohlone College,
> University (South Korea), Oracle, Oriental Hospital of Daejeon
> University (South Korea), Panel on Responsible Conduct of Research
> (Canada), Paris Web, Parliament of Canada , Public Safety Canada,
> Public Works and Government Services Canada, Rebuilding The Web,
> Social Security Online, Special Education Support Center (South
> Korea), Statistics Canada, Statistique Canada, Substance Abuse &
> Mental Health Services Administration, tech.burningbird, Treasury
> Board of Canada Secretariat, Texas State Library, U.S. Department of
> Health & Human Services, and the University of Minnesota have used it
> in reports and publications.
> Notably the two sister sites Statistics Canada and Statistique Canada
> [9] are consistently using longdesc in "The Daily" publication. "The
> Daily" produces statistics on a business-day basis that help Canadians
> better understand their country, its population, resources, economy,
> society and culture. Please refer to Statistics Canada and Statistique
> Canada for detailed evidence. [8]
> On July 29, 2011 Suzanne Taylor and Ed McCoyd, Esq., of the
> Association of American Publishers attested:
> "We are using longdesc increasingly in our products." [10]
> Content owners should not have to re-author content, already being
> delivered to legacy devices as well as to today's leading-edge
> browsers and assistive technology, in order for it to be valid and
> accessible HTML5.

They shouldn't, no. And they won't have to. It's not like browsers
will drop support for longdesc. They will either improve it or add
another element with better support. In both cases they won't be worse
off with their existing content.

> Obsoleting and renaming longdesc would result in mixed messages
> between existing documents and HTML5. Such messages can serve only to
> confuse. Those who encounter the array of books [11], online tutorials
> [12], guidelines, laws, policies and standards [13] that have already
> recognized longdesc's importance to accessibility will expect longdesc
> to continue to function as described.

All HTML5 books have to be rewritten continuously these days. There is
continuous improvement all the time. People are or should be aware of
it. The new recommendations have to take into account old authoring
techniques and guidelines. So there should never be any mixed

> Materials such as these have a way of living on; they will not be
> obsoleted in the foreseeable future.
> Anyway, Silvia, re-branding to a new name would destroy all of this.

Indeed, you cannot re-brand: but longdesc is not going to mysteriously
disappear with a new attribute. It's more like bringing out an
additional new product with more bells and whistles.

> That is why I did not re-brand and pursue bug 10455 [14]. Instead I
> stayed with the longdesc name.

I understand all of this and repeating it over and over again won't
help any of us. It's all clearly stated in your change proposal. That
doesn't mean that I have to agree with it all. I think we're just
going to have to agree to disagree on our preferences and do what is
achievable given the circumstances.


Received on Thursday, 15 March 2012 20:46:55 UTC