W3C home > Mailing lists > Public > public-html-a11y@w3.org > March 2012

RE: Expanding longdesc use

From: David MacDonald <david100@sympatico.ca>
Date: Thu, 15 Mar 2012 14:05:34 -0400
Message-ID: <BLU0-SMTP14FB48A4FFC28253A382D9FE5E0@phx.gbl>
To: "'Laura Carlson'" <laura.lee.carlson@gmail.com>, "'Silvia Pfeiffer'" <silviapfeiffer1@gmail.com>
CC: 'Léonie Watson' <lwatson@nomensa.com>, "'Joshue O Connor'" <joshue.oconnor@cfit.ie>, "'HTML Accessibility Task Force'" <public-html-a11y@w3.org>, "'W3C WAI-XTECH'" <wai-xtech@w3.org>, "'Benjamin Hawkes-Lewis'" <bhawkeslewis@googlemail.com>, "'Loretta Guarino Reid'" <lorettaguarino@google.com>

There has been some discussion about describedby as a replacement for longdesc. However, screen reader user would have to encounter the description twice (once on the image and once on the page), which by definition is "long". The long text on the page clutters the page for most sighted users. (a deterrent for implementation by webmasters)

Some have proposed hidden describedby descriptions with offscreen CSS, or "hidden" but I don't think authors will find that acceptable given Google's position on hidden text.

Google says:

>>"If you do find hidden text or links on your site, either remove them or, if they are relevant for your site's visitors, make them easily viewable. If your site has been removed from our search results ... Once you've made your changes and are confident that your site no longer violates our guidelines, submit your site for reconsideration."

This article from Google's search engine team does not seem to leave any room for text that is hidden (or off screen) for good reasons like text alternatives.

So that leaves us with describedAt (which is non-existent) vs. Longdesc.

ARIA is clear that authors should "Use native markup when possible....Use the semantic elements that are defined in the host markup language."

So why would we obsolete an existing HTML element with the intention of recreating it in a "bridging technology" like ARIA, which was specifically created to make up for holes in HTML? <scratching head>

David MacDonald

CanAdapt Solutions Inc.
  "Enabling the Web"

-----Original Message-----
From: Laura Carlson [mailto:laura.lee.carlson@gmail.com] 
Sent: March-15-12 1:10 PM
To: Silvia Pfeiffer
Cc: Léonie Watson; Joshue O Connor; HTML Accessibility Task Force; W3C WAI-XTECH; Benjamin Hawkes-Lewis
Subject: Re: Expanding longdesc use

Hi Silvia,

Thank you very much for your email. Nice to hear from you.

> I couldn't agree more with the general sentiment of this thread - a 
> general solution to off-page linked long descriptions is necessary for 
> multiple elements, not just img.

That's great. The Change Proposal does state that "It would possibly allow longdesc to be used on other elements that need descriptions."

> I personally don't think that
> @longdesc is going to be the name of that solution, simply because it 
> has too much baggage, but I'm pragmatic about it and just want to see 
> a consistent, well-thoughtout solution that is applicable to multiple 
> elements.

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.


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.


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. 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.

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.

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.


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.

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

Best Regards,

[0] http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/Conclusion
[1] http://www.d.umn.edu/~lcarlson/research/ld.html#atools
[2] http://www.d.umn.edu/~lcarlson/research/ld.html#at
[3] http://www.d.umn.edu/~lcarlson/research/ld.html#browsers
[4] http://john.foliot.ca/wysiwyg_longdesc/
[5] http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/Implementation#Recent_Research_on_Authoring_Tools
[6] http://www.d.umn.edu/~lcarlson/research/ld-ua.html
[7] http://www.d.umn.edu/~lcarlson/research/ld.html#wild
[8] http://www.d.umn.edu/~lcarlson/research/ld.html#statcan
[9] http://www.d.umn.edu/~lcarlson/research/ld.html#statcanf
[10] https://www.w3.org/Bugs/Public/show_bug.cgi?id=13461#c1
[11] http://www.d.umn.edu/~lcarlson/research/ld.html#books
[12] http://www.d.umn.edu/~lcarlson/research/ld.html#tutorials
[13] http://www.d.umn.edu/~lcarlson/research/ld.html#glps
[14] https://www.w3.org/Bugs/Public/show_bug.cgi?id=10455
Laura L. Carlson
Received on Thursday, 15 March 2012 18:06:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:56:06 UTC