longdesc
Improves Accessibility in Practice
It has been substantially evidenced via the documentation of over fourteen hundred real world examples of longdesc
that authors do
indeed use this attribute in practice to improve accessibility. This is a
non-negligible number of example <img>
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. Example sites using
longdesc
include but are not limited to:
- A11y Bugs Project
- A-Prompt
- ACCESS-ed: University of Wisconsin - Milwaukee
- Aboriginal Affairs and Northern Development Canada
- AccessAbility SIG
- Accessibilité du Web (Canada)
- algebraicthunk
- Alpen (Germany)
- Anblik
- Axel Schäfer, SPD Abgeordneter im Deutschen Bundestag für Bochum
- Australian Government: Department of Health and Aging
- Australian Government: Disability Services Census
- Australian Government: Volunteering Rate in Australia
- Bembelterror Frankfurt
- Berrien Metal Products, Inc.
- CSS Squirrel
- Canada Virtual Museum of Valentines
- Canada's Department of Justice
- Canadian Grain Commission
- Canadian Space Agency
- Center for the Study of Religion and American Culture
- Centers for Disease Control and Prevention
- City of Florence (Italy)
- Commonwealth of Massachusetts
- Connexions
- Conseil supérieur de la langue française
- Correctional Service Canada
- Courts Administration Service (Canada)
- Daegu Metropolitan Office of Education (South Korea)
- Department of Sustainability, Environment, Water, Population and Communities (Australia)
- Department of Transportation (Taiwan)
- dizABLED
- Dhammadana, The Original Teaching of Buddha (Myanmar)
- Digital Inspiration
- Division of Cancer Epidemiology & Genetics, National Cancer Institute
- ebility.com
- Education Place
- Elections Canada
- Environment Canada
- Escola de Todos (Portuguese)
- F*ckparade (Germany)
- Fakoo (Germany)
- Federal Deposit Insurance Corporation
- Federal Motor Carrier Safety Administration
- Financial Transactions and Reports Analysis Centre of Canada
- Fundación Sidar - Acceso Universal (Spain)
- Giheung-Gu Yong-in City (South Korea)
- Global Alliance on Accessible Technologies and Environments
- Graphical Object Server for Non-Visual Interaction (GONVI)
- Griffith University
- Grinning Planet
- haecceitas (UK)
- Hamilton College
- Hawaii Public Schools
- Health Resources and Services Administration
- Health and Safety Executive (UK)
- Hipocampo
- HTML5 Multimedia
- IBM Corporation
- IDCnet: Inclusive Design Curriculum Network
- Indian and Northern Affairs Canada
- Indiana University-Purdue University Indianapolis Common Core Curriculum Committee
- Industry Canada
- Institute for Community Inclusion
- Interacciones (Argentina)
- Iris Fernandez BETA Weblog, educación y tecnología en Argentina
- John.Foliot.ca
- Jun-seok, Park (South Korea)
- Kennedy Center
- Kilkee, County Clare, Ireland
- Korea Employment Information Service (South Korea)
- Kreuttal (Austria)
- Kyungpook (South Korea)
- Lexdis (UK)
- Linux Foundation
- Local Government Commission
- London Canal Museum
- Lusophone countries - Convention on the Rights of Persons with Disabilities (Portuguese)
- Marine National Park (Taiwan)
- Mecanizados EKIMEN
- Memphis Center for Independent Living
- Mesothelioma Center
- Michigan State University
- Ministère de la Culture et de la Communication
- Ministère des Relations internationales - Gouvernement du Quèbec
- Montana Arts Council
- Monterey County
- My Opera
- National Adult Literacy Database (Canada)
- National Center for the Dissemination of Disability Research
- National Gang Center
- National Institute of Information and Communications Technology (Japan)
- National Institutes of Health (Canada)
- National Institutes of Health (United States)
- National Property Administration Office in Central Taiwan
- Natural Resources Canada
- nota-ben (France)
- New Zealand Department of Labor
- Nick's Mathematical Miscellany
- Northern Ireland Planning Service
- Object Description
- Ocean Motion
- Office of the Superintendent of Financial Institutions Canada
- Ohlone College
- Oracle
- Oriental Hospital of Daejeon University (South Korea)
- Parliament of Canada
- Paris Web
- Panel on Responsible Conduct of Research (Canada)
- PC Net (Japan)
- Pessimistic Dot Com
- Province of Gyeongsangbuk (South Korea)
- Psychosocial Impact of Assistive Devices Scale (PIADS)
- Public Safety Canada
- Public Service Commission of Canada
- Public Works and Government Services Canada
- Rebuilding The Web
- Research and Innovative Technology Administration / US Department of Transportation
- San Diego University
- Santa Barbara Public Library
- Securian
- Sésame Province de Luxembourg (Belgium)
- Snowdon Award Scheme (UK)
- Social Security Online
- Special Education Support Center (South Korea)
- Standard Chartered Leading the way in Asia, Africa, and the Middle East
- Statistics Canada (English)
- Statistique Canada (French)
- Substance Abuse and Mental Health Services Administration (SAMHA)
- Talk Origins
- tech.burningbird
- Telsa Gwynne
- Technical University of Darmstadt (Germany)
- Texas Comptroller of Accounts, Susan Combs
- Texas State Library
- The Geography Site (UK)
- The Organisation Development Company (New Zealand)
- Trace Center
- Treasury Board of Canada Secretariat
- U.S. Department of Health & Human Services
- U.S. Department of Transportation Federal Highway Administration
- U.S. General Services Administration
- U.S. Patent and Trademark Office
- U.S. Postal Service
- U.S. Social Security Administration
- U.S. State Department
- UK Blind Piano Tuners
- Universal Remote Console Consortium
- Universal Remote Console Prototyping of an Emerging XML Based Alternate User Interface Access Standard
- University at Buffalo
- University of Melbourne
- University of Minnesota Duluth
- University of Texas
- University of Texas at Austin
- University of Victoria
- University of York
- Virginia Department of Environmental Quality
- W3C HTML5 Accessibility Task Force Bug Comparisons
- W3C HTML5 Accessibility Task Force Procedures
- W3C Rich Web Applications Backplane Incubator Group
- W3C Web Content Accessibility Guidelines (WCAG)
- WAI-ARIA Primer 1.0
- WebAIM
- Yasui (Japan)
- York University (Canada)
- Yorkshire and Humberside Books
- ZEW (Germany)
longdesc
Provides Authors With a Solution While
Allowing for Constraints
The Zero
Edit/Obsolete longdesc
Change Proposal fails to recognize that
use cases
evidenced by examples in the wild along with first person testimony establishes
that real constraints restrict the degree of freedom in providing solutions.
The constraints are effectively global requirements, such as limited resources or a decision by management or expected user functionality that restricts the way a solution can be provided. (e.g., technical requirement, business rule, etc.)
Forced Visual Encumbrance
A recurring constraint through the majority of use cases is that forcing a visual encumbrance on sighted users by adding long description text in-page or adding a visual link indicator in-page to a long description adds visual clutter for sighted users. This is a critical and significant constraint for designers, visual artists, and marketers because of usability and aesthetics.
Clutter is an important phenomenon in our lives, and an important consideration in the design of user interfaces and information visualizations. Many existing visualization systems are designed to reduce clutter by filtering what objects or information the user sees... Tips for designing web pages, maps, and other visualizations often focus on techniques for displaying a large amount of information while keeping clutter to a minimum through careful choices... [Rosenholtz et al., Feature Congestion: A Measure of Display Clutter (PDF)]
For sighted users, the consequences of adding a redundant visual text
description is information overload which wastes time and taxes attention at the
content's peril. It would be akin to having the value of the alt
attribute visible by default or providing visible indicators of it. Making such
features visible by default would cause needless work for designers to hide them or
frustration to the majority of sighted users if designers didn't hide them.
Removing such visual clutter increases understanding and actual time-on-task for the majority of sighted users. This is where visual design plays an increasingly important role. It is well known that reducing clutter improves usability.
The statement from cartoonist Kyle Weems provides first-hand author testimony that a default visual indicator on-screen is unacceptable due to this constraint. As Kyle explained, designers object to being told to use visible links. In this use case it is illogical and redundant to recreate the dialog of a series of cartoon speech bubbles directly after the cartoon from a visual design perspective. In these types of cases the aesthetic principle of the artist will always trump 'data' requirements when those requirements become onerous. Aesthetic principles restrict the way a solution can be provided. Ignoring such author constraints is ignoring reality.
Natively Free from a Visual Encumbrance Solves a Problem
A longdesc
's aim is to be a substitute for the image. It is
natively free from a visual encumbrance. It solves the problem. It allows
accommodation, customization, and personalization
of content in accordance with a target audience's needs and capabilities.
As Suzanne Taylor and Ed McCoyd, Esq., of the Association of American Publishers (AAP) testified to the HTML working group,
The
longdesc
attribute does not impact the visual design. So, authors do not have to worry about how the text might impact the visual user experience. Authors can, therefore, focus on the experience of students and instructors with visual impairment while they write text alternatives. This focus on the primary audience helps authors create text that is well-suited for its purpose.
AbilityNet discuses how hiding content from view optimizes browsing experiences for two user groups,
Hiding content from view but enabling it to be read out by screen readers enables the web developer to provide additional information that is helpful for the screen reader user. This would enable the screen reader user to understand the content of the web page or the way the web page is constructed without compromising on design. This is particularly useful for elements and areas where there is not enough text describing the area or element ...Hiding content from view can enhance the usability of the website for screen reader users without compromising on design. Visual users will have no indication that these design elements are present resulting in visual and non-visual users having the optimum browsing experience.
This constraint has been amply evidenced with the documentation of over One thousand
real world images that do not force a visual encumbrance for a
long description by using longdesc
. As evidenced, circumstances do
indeed exist where page authors need, desire, utilize longdesc
due to
this constraint.
Programmatic Determinability Aids Accessibility
Programmatic determinability aids accessibility. This means that a specific value can be determined in a standard, machine or software readable form. Assistive technology does not have to guess about it, or use heuristics. It is authoritative, precise, and provides unambiguous specificity.
When content is properly marked up in HTML, its semantic structure and relationships are in the markup itself. That is, they can be programmatically determined. Because this information is in the code, as it were, supporting technologies can programmatically retrieve it and present it to users in different ways. The information can be "transformed...into different sensory formats (e.g., visual, auditory) or styles of presentation needed by individual users.
An image with longdesc
is programmatically determinable. It is
catalytic, returning obvious value back to the user. When a long description is
marked up via a longdesc
attribute it allows software, including
assistive technology, to extract and present the information in different
modalities. It can be identified by assistive technology as being a long
description beyond doubt. In turn, assistive technology can pass on the information
to the user. Without programmatic determinability no explicit relationship exists
to indicate that a long description has anything to do with an image.
Modern screen readers take advantage of the programmatic determinability of
longdesc
. They announce its presence as being a long description and
provide the user with the option of reading it.
In JAWS 11 and up one can also use the list of graphics contained in the document in
order to retrieve longdesc
s, by using the Graphics List to move focus
to an individual graphic, the longdesc
of which can then be accessed
by hitting the "enter" key.
Additionally, longdesc
is used in popular screen readers as a hook
in order to notify the user that a long description exists, so even if
longdesc
is applied to an image that also serves as a link, it is
programmatically possible to separate the activation of the longdesc
for exposure from the UA's universal link activation action (which is usually
activated with the "enter" key, the space bar, or by mouse click), so that the
linked image retains the expected behavior in response to user interaction while a
discrete mechanism is used to retrieve the long description.
As Christophe Strobbe has said:
With @longdesc the relationship between an image and its long description can be programmatically determined. I think this is one of the best arguments in favour of this attribute. This is because the tendency in HTML has been towards higher degrees of semantics and programmatically determinable relationships, for example:
- before HTML 4, form fields could not be associated with labels because HTML had no label element; HTML 4 introduced the label element and a mechanism to associate labels with form fields in a way that can be programmatically determined;
- before HTML 4, table data cells were not explicitly associated with header cells; HTML 4 added @id and @headers to TD and TH elements to enable explicit association;
- before XForms and HTML5, there was no way to mark form fields as required, so developers resorted to JavaScript behaviours to work around this;
- before XForms and HTML5, there was no way to define data types for form fields, so developers resorted to JavaScript behaviours to work around this.
The list can probably be expanded, but the point should be clear: not adding @longdesc to HTML 5 is a step backwards because it goes against the tendency to more semantics and programmatically determined relationships.
Because the relationship between an image and its long description can be
programmatically determined with longdesc,
it provides higher level of
accessibility than techniques that are not programmatically determinable. With
techniques that are not programmatically determinable a screen reader user may
never know that any long description information exists.
Author Skill Sets Differ
The primary actors in use cases 1, 2, 5, 6, 7, 8, and 10 are not skilled developers but content authors, namely a:
- Cartoonist
- Task Force Member
- Photographer
- Information Technology Professional
- Group of Librarians
- Journalist
- Web Designer
These use cases show that people of limited skill set use HTML's
longdesc.
It offers a solution for these types of authors. Other
solutions do not. Obsoleting longdesc
would strip a useful mechanism
from authors of limited skill set who are using it to improve accessibility.
As explained in my objection to the "Keep the longdesc
attribute
for the img
element deprecated" proposal, different techniques require
different skills.
Pitting
aria-describedby
andlongdesc
against each other is counter-productive to accessibility. It should not be an either/or situation.Longdesc
is needed andaria-describedby
is needed. A different skill set exists between JavaScript library/app developers and the run of the mill content authors/web designers e.g. advanced skill set versus basic skill set. One group may learn ARIA to develop "Accessible Rich Internet Applications" the other will use basic HTML to put up a web page or a web site.As Cliff Tyllick has said, it is unlikely that many content creators or web designers will learn ARIA (something not native HTML). They already feel like they've learned far more than they should have to know under their job description. And in many cases, their supervisors agree. Cliff goes on to say,
And the use case for needing this to be inherent to HTML5 is simply this: Many people who put content on the Web have training in nothing more than html. If you call any technique by a different name - whether it's Java, AJAX, or ARIA - they will not learn it. So if the means for attaching this information to an image is not within html, they won't use it.
Content creators/basic authors should not be forced to read another large spec besides HTML5 to make content accessible. These authors may know basic HTML and be willing to put in
longdesc
for complex images but most are not going to delve into other specs. ARIA is not an option for them. If content is to be made accessible by both groups of authors we need both mechanisms.Most basic content authors are not going to learn two languages to make images accessible. When accessibility is not relegated to a separate spec but integrated into the host language, it is viewed as a mainstay rather than as an afterthought or add-on. Educators have a hard enough time teaching HTML, and an even harder time teaching the need for accessibility (and the means to address those needs). Pile on yet another layer and the difficulties will increase exponentially.
ARIA is powerful technology. If HTML5 forces ARIA upon basic content authors in order to make content accessible, what these authors will end up doing with it is unknown. Encouraging people who don't intend to learn ARIA thoroughly to dabble in it could have unintended consequences. For instance, make a counter a live region - disaster - but it seems logical. Mark a section of your page as an "application" because to you it is an application - seems great. But if you don't handle every keyboard command - it's another disaster.
Two types of authors are recognized, differentiated, and provided for separately by other standard organizations. For example, in 508-255 Refresh (ANPRM) the Access Board provides Chapter 5 for document authors and Chapter 4 for app developers. They state,
Advisory 501.1 Scope. The provisions of this chapter apply to electronic documents, which are mostly static, read-only, non-interactive electronic content. Examples include Word files, PDFs, PowerPoint presentations, Excel spreadsheets, and simple web pages (which do not contain Flash). However, electronic documents may also contain interactive content, such as hypertext links, buttons, and form elements or fields. All of these elements are covered in this chapter. Electronic content covered by this chapter includes most non-paper documents and web content, regardless of format.
This chapter is oriented towards document authors, rather than developers.
Provisions relevant to more robust user interaction, including scripting, are found in Chapter 4 (Platforms, Applications, and Interactive Content). Additional requirements for audio and video content are found in Chapter 6 (Synchronized Media Content and Players).
Both advanced developers and the run of the mill content authors/web designers deserve to have suitable tools at their disposal for providing long descriptions. Both need to be provided for. Anything else is a false choice. It would be discriminatory if only ARIA skilled developers are able to publish an accessible image on the Web.
Not Being Forced Upon Users
As explained in my objection to the "Keep the longdesc
attribute
for the img
element deprecated" proposal,
With
aria-describedby
the description is forced upon screen reader users whether they want it or not. They cannot interact with it at will.aria-describedby
is read aloud without any user intervention, forcing the screen reader user to listen to it each and every time they encounter the image whether they want to or not. The user is not able to control how they interact with the long description.As the Association of American Publishers has explained,
aria-describedby
cannot be silent by default in screen readers when used on images, compromising its use to illustrate that the content of an image is already available on the page.Such behavior makes
aria-describedby
a non-starter. None of this is a problem withlongdesc
as it supplies descriptions on-demand and not by force.Longdesc
is an "escapable structure" as Janina Sajka illuminated.Distracting and Frustrating Circular User Experience
AAP goes on to explain that,
Developers may not realize the distracting and frustratingly circular user experience that this would cause and might use
aria-describedby
to point to, for example, a paragraph just above the image. Users would then likely follow thearia-describedby
announcement, expecting to find additional content, but they would arrive, instead, at a paragraph that they have likely just read.
Supporting Structured Text
As explained in my objection to the "Keep the longdesc
attribute
for the img
element deprecated" proposal,
Even though it can point to structured content such as bulleted lists and paragraphs
aria-describedby
can only process structured content as string-text. This is because the accessibility APIs that aria-describedby maps to do not support structured content due to tab focus requirements.This means that assistive technology treats
aria-describedby
target content as though it does not have any mark-up. It is treated as a string. All structure is stripped clean. A user's reading keys will not work. Users are not able to interact with the content. All links are dead.This is not a problem with
longdesc
.Longdesc
supports structured content. Reading keys and links work.
longdesc
is Useful to Users
In recent research the majority of screen reader users declared
longdesc
useful. Over 60 percent of the 1090 respondents found it
somewhat to very useful. No evidence has been provided that the majority of the
longdesc
attribute target user group do not benefit from it.
The AAP has
directly testified that longdesc
enhances the user experience by
increasing learnability. They stated,
Students and instructors will find the same user interface throughout all materials, so they will not need to learn new interfaces product-to-product, which takes time and attention away from the learning content.
The Zero
Edit/Obsolete longdesc
Change Proposal fails to provide concrete
evidence that longdesc
creates a bad accessibility experience. As
stated in the original decision the supposed
"problems with longdesc
" are highly anecdotal or
non-scientific.
longdesc
Strengthens the Language
Content should be marked up based on what it is. The longdesc
attribute best reflects a long description.
Longdesc
strengthens the language. It adds semantics, which
provides a higher level of communication. Communication is pretty much the point of
language design. Lay people looking only at how a page displays may never get that
additional communication, but machines can. Providing that extra meaning allows
machines to translate it for people.
Semantic HTML is important to authors because as John Allsopp has explained,
We need mechanisms in HTML that clearly and unambiguously enable developers to add richer, more meaningful semantics-not pseudo semantics-to their markup. This is perhaps the single most pressing goal for the HTML 5 project.
But it’s not as simple as coming up with a mechanism to create richer semantics in HTML content: there are significant constraints on any solution. Perhaps the biggest one is backward compatibility. The solution can’t break the hundreds of millions of browsing devices in use today, which will continue to be used for years to come. Any solution that isn't backward compatible won’t be widely adopted by developers for fear of excluding readers. It will quickly wither on the vine.
Longdesc
provides semantic richness to the language while being
backwards compatible. Dropping longdesc
from the newest version of
HTML would drop meaningful semantics and weaken the language.
The rationale that HTML5 should have built-in semantics was successful
rationale used to keep <figure>
, <aside>
,
<details>
, and hidden=""
. The decisions on those
issues set the precedent that native HTML semantics is a determining factor of what
is included in the language.
For further rationale regarding semantics, please refer to my objection to the
Keep the longdesc
attribute for the img
element
deprecated proposal.
longdesc
Provides Backwards Compatibility
Expecting authors to rewrite their content in order to support techniques that (a) do not work for authors or users, (b) are not programmatically determinable, (c) ignore aesthetics and other constraints, and/or (d) are simply cumbersome "hacks", is nonsensical and totally unrealistic : such attempts will serve only to infuriate and alienate both those authors and the accessibility community as a whole.
As explained in my objection to the "Keep the longdesc
attribute
for the img
element deprecated" proposal,
It is much less invasive to make
longdesc
fully conforming. This approach removes an illogical undue burden and will be acceptable to authors and organizations that have made investments in the use oflongdesc.
This attribute has made content accessible to users on company, organizational, governmental, educational, and personal sites throughout the world. It is implemented in user agents, authoring tools, and assistive technology. 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.
Longdesc
-related features in existing authoring tools should continue to output valid content : both authors and users have perfectly reasonable expectations thatlongdesc
will continue to be supported by existing tools, and will continue to have its current (i.e., intended) effect in existing content.Obsoleting
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, online tutorials, guidelines, laws, policies and standards that have already recognizedlongdesc
's importance to accessibility will expectlongdesc
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, and therefore neither mustlongdesc
.
Obsoleting longdesc would break 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 the replacement - for something meant to solve the same problem, this is an intolerable cost. Backwards compatibility is absolutely necessary.
longdesc
is Experiencing Increased Usage in
the Wild
Even though it is most useful for a small group of users and not needed by the
majority who have the luck to live on this planet with two healthy eyes,
longdesc
is experiencing increased usage in the
wild.
For example, during the past year alone, numerous organizations such as the A11y Bugs Project, Aboriginal Affairs and Northern Development Canada, Axel Schäfer, SPD Abgeordneter im Deutschen Bundestag für Bochum, CSS Squirrel, Canada Virtual Museum of Valentines, 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 began 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.
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.
On March 11, 2011 Geoff Freed
indicated that professional content producers (such as those involved in the
ePub initiative, and the US federally-funded DIAGRAM Project) are interested and
ready to use longdesc
to meet their existing requirements, thereby
increasing the pool of useful and well constructed longdesc
descriptions in richly structured documents.
User Agent Support
Any user can access a longdesc
by using a user agent that supports
it. Recent research finds that
modern screen readers have good support for the longdesc
attribute. A collection of tools that provide support for longdesc
exists for those that need or require that support, and individual users who want
to access long descriptions supplied via longdesc
, whether they are
sighted or not, have a choice of options to do so. The claim that
longdesc
isn't exposed to some users is outweighed by the concrete
examples of it being exposed in accessible ways and is as ludicrous as suggesting
that the <img>
element should be removed from HTML5 because its
graphic contents cannot be disclosed to users who elect to use Lynx or similar.
On March 11, 2011, professional content producers at the Digital Image and
Graphic Resources for Accessible Materials Center (DIAGRAM) addressed
longdesc
support for other users. Their testimony
states:
features developed to help people with specific disabilities also assist other users, and this is true for long image descriptions. Today, for example, Firefox and Opera allow the user to open a context menu over an image and choose to see the long description on the screen, if @longdesc is included with the image. This is an excellent tool for assisting sighted students with learning disabilities who need textual reinforcement when deciphering the contents of a complicated image. Also, as image descriptions become more widely used, it is expected that search engines can take advantage of descriptions in locating relevant images.
Growth in User Agent Support
Since March 11, 2011 user agent implementation has
grown. The following examples clearly demonstrate this and how
longdesc
is machine readable.
longdesk
The Zero
Edit/Obsolete longdesc
proposal inaccurately states,
To be successful longdesc needs to have an activation mechanism as easy and intuitive to use as a normal link, which is probably impossible.
It is not impossible. A new longdesk FireFox
extension has been developed that adds a link to the longdesc
under images that provides one. It makes the longdesc
activation easy
and intuitive for sighted users who wish access.
TellMeMore
For those who would like an indication of when longdesc
s are
available on a page without interfering with page design, a new TellMeMore Opera
extension has been developed. It respects visual design and does not force an
on-page visual encumbrance. Instead it provides an icon in the chrome to indicate
when descriptions exist. Then, upon activating the icon, the user is presented with
a popup containing a list of all descriptions available along with their thumbnail
images.
Scripted Implementations
New direct replacement functionality has been provided via a scripted implementation. easyALBUM utilizes programmatic determinability as evidenced in several recent photo albums.
Internet Explorer Solution
Internet Explorer can now be configured to handle longdesc
.
The Future and User Agent Support
The Zero
Edit/Obsolete longdesc
Change Proposal fails to provide any
evidence that it would be difficult or impossible for user agents to identify and
make good use of longdesc
. In fact, a FireFox browser vendor responded
to a question asking "Would it be possible to make longdesc
a global
attribute?" by saying, "This is
software, anything is possible".
To help browser vendors in this effort in the future, new text has been
specified for the 10.6.1 rendering section. which illustrates how
longdesc
can be made discoverable.
Alternative Techniques
Overview
The Zero
Edit/Obsolete longdesc
Change Proposal suggests that the existence
of alternative/related long description techniques is rationale to drop
longdesc
from HTML. The alternatives are retrograde, makeshift
substitutes for longdesc
.
As delineated one-by-one in the
Include longdesc
in HTML5 Change Proposal, an explicit link,
aria-describedby
, figcaption
, details
,
aria-describedat
, image map
, or a new HTML attribute are
not viable solutions. Please refer to that document and the how proposed solutions
meet some common long description requirements matrix for details.
The following information regarding rel="longdesc"
, cascading style
sheets, and aria-describedby
provides further rationale as to why the
existence of these techniques does not justify killing off longdesc.
rel="longdesc"
rel="longdesc"
has been suggested as a "progressive enhancement"
solution for supplying long descriptions and a reason to obsolete
longdesc
. Accessibility is not "progressive enhancement"; it is core
functionality.
The fact is rel="longdesc"
syntax only works on a limited subset of
use cases. It is impossible for one link to take a user to two locations. As
Julian
Reschke has explained,
<a href=* rel=longdesc href=URL><img src=* alt=*></a>
only works when the<img>
element doesn't already have a parent<a>
element, which is something which is used a lot.
rel="longdesc"
is not programmatically determinable when an image
already has a link which is mapped to go to another page or a larger image.
Expecting all <img>
elements that need long descriptions not to
have a parent <a>
element mapped to a different task unrelated
to a long description is unrealistic. Attempting to force dual functionality into
single functionality as proposed in the Zero Edit/Obsolete longdesc
proposal is unworkable.
For example, if an image already has a link that takes the user to another page (i.e., a logo image that links to a home page, one cartoon in a series of cartoon images that links to the next comic strip page, a thumbnail image in a gallery that links to a larger version of an image, etc.), it is impractical and most times nonsensical for the destination page to shoehorn in a long description. It would provide a confusing and inferior user experience.
Removing the possibility for direct, dual, programmatic access to both a long
description via longdesc
and a separate a href
on an
<img>
element would be (a) needless authoring impediment, (b) a
step backwards for HTML, and (c) a barrier to providing accessible content.
Including longdesc
in HTML5 affords authors a way to provide both an
a href
as well as an accessible programmatically determinable long
description.
In addition, obsoleting longdesc
in favor of
rel="longdesc"
:
- Fails because it would force a visual encumbrance on sighted users unless additional code (in the form of CSS) were added in order to hide the visual indicator. Please refer to the Cascading Style Sheets section of this document for details of why this is a bad idea.
- Attempts to reinvent the wheel by duplicating a basic method that has already
previously been created. No use cases of
rel="longdesc"
have been presented that are not already satisfied bylongdesc
. - Would setback progress as it is not backwards compatible.
Longdesc
has a critical support base that has taken a decade to build and would probably take another to rebuild. Therel="longdesc"
technique is not:- Recognized or implemented by existing
authoring tools,
browsers, or
assistive technologies. For example, it is not automatically announced to
users of screen readers like JAWS, SuperNova/Hal or WindowEyes that a long
description is available when
rel="longdesc"
is used. - In numerous books, online tutorials, guidelines, laws, policies and standards throughout the world.
- Recognized or implemented by existing
authoring tools,
browsers, or
assistive technologies. For example, it is not automatically announced to
users of screen readers like JAWS, SuperNova/Hal or WindowEyes that a long
description is available when
In sum this suggestion is unworkable and not an excuse to drop
longdesc
from HTML. Its existence does
not negate the need for longdesc
.
Cascading Style Sheets
Cascading Style Sheets (CSS) have been suggested as a solution for hiding long
description indicators in combination with other alternative solutions such as
rel="longdesc"
or a non-programmatically determinable explicit link.
Requiring authors to use CSS to hide the indicator when longdesc
already does this natively, not only adds needless complexity, page weight, and
inconsistency, it also is error prone and disenfranchises authors of limited skill
set.
As pointed out in my objection to the "Keep the longdesc
attribute
for the img
element deprecated" proposal,
The Association of American Publishers (AAP) has attested that piecemeal, workarounds for not forcing a visual encumbrance creates complexity, inconsistency, and unreliability. In particular they point out that hiding long description link text visually,
would require custom CSS or scripting. The mechanism for hiding the link would therefore differ product-to-product, making browser extensions or features to show the links more complex to code and less reliable for users.
CSS rules such as img{border:0;}
for a long description link on an
image is a needless, circuitous kludge. Older native HTML syntax is simple.
Requiring CSS would add page weight and slow pages. Authors have voiced these
facts. For instance, on October 13, 2011, Barry
Kintner beseeched the HTML working group:
Please do not drop recognition of older (simpler) HTML vocabulary. I find far too many people are over-using CSS etc - not really knowing or understanding the needs of the visitor...
I find I've been able to re-create business web pages - with all functionality retained - that are 60-90% smaller in file size, by using so-called 'older' standards. Retain all the old codes that had been usable before (from 3.2-4.x).
Hiding long description indicators and link text with CSS adds needless complexity and is error prone. The potential for confusion is rife.
Even authors versed in CSS have problems hiding long description indicators with
CSS in a manner that is accessible. As explained in my objection to the "Keep the
longdesc
attribute for the img
element deprecated"
proposal, the declaration display:none
is hidden from screen readers.
Not many authors know that fact. They use it to hide long description link text and
it does not work for their target audience. For instance, Snowdon Award Scheme,
and Zew have
mistakenly used display:none
for long description link text
indicators. However, this common mistake was mitigated in these three examples
because they also used longdesc
, which works.
Another example of an inaccessible CSS technique is using
visibility:hidden
. This declaration should not be used for content
that is to be read by screen readers because it hides content
from them. Daegu Metropolitan Office
of Education is an example of an organization mistakenly using this technique.
Fortunately they also used longdesc
, which does work.
Hiding long description indicators and link text with CSS would especially place
an undue burden on authors of limited skill set. They will
not know how to use CSS let alone know which techniques may be accessible and which
definitely are not. With longdesc
this is not an issue because it is
natively free from a visual encumbrance.
If HTML5 obsoletes longdesc
and an author's only choice to hide
long description indicators/link text is relegated to CSS, many will use the wrong
techniques. Requiring the use of CSS when longdesc
is already natively
free from a visual encumbrance reinvents the wheel. It is an inefficient, inelegant
, and clumsy "hack" that not only adds needless complexity, confusion, page weight,
and inconsistency, it also is error prone and disenfranchises authors of limited
skill set. All told, it would result in less accessible content.
aria-describedby
aria-describedby
is explicitly addressed in my objection to the
aria-describedby
change proposal. Please refer to it for rationale of
why it is not workable. And even if it were, that
would not negate the need for longdesc
. Killing off
longdesc
in the name of ARIA
is a false choice and an
unwarranted conclusion.
No Proof of Better Authorability
The Zero Edit/Obsolete longdesc
Change Proposal fails to provide
any evidence that authors would use or get alternative techniques correct more
often than longdesc
.
Rebuttals to Use Case Comments
Longdesc
is an established and implemented solution to real
problems in valid use cases. All of the documented use cases are substantiated by
real world examples as cited in the use case notes. The use case real world
examples in the wild include longdesc
s from the following sites:
- A11y Bugs Project
- Accessibilité du Web (Canada)
- Axel Schäfer, SPD Abgeordneter im Deutschen Bundestag für Bochum
- CSS Squirrel
- Commonwealth of Massachusetts
- Conseil supérieur de la langue française
- Daegu Metropolitan Office of Education (South Korea)
- Dhammadana
- Digital Inspiration
- dizABLED
- easyALBUM
- Elections Canada
- Environment Canada
- Federal Motor Carrier Safety Administration
- Financial Transactions and Reports Analysis Centre of Canada
- Griffith University
- Grinning Planet
- Hawaii Public Schools
- IBM Corporation
- Interacciones
- Korea Employment Information Service
- Lexdis
- Michigan State University
- My Opera
- National Institute of Information and Communications Technology National Adult Literacy Database
- National Institutes of Health
- Natural Resources Canada
- nota-ben
- Oracle
- Paris Web
- Public Service Commission of Canada
- Rebuilding The Web
- Research and Innovative Technology Administration / US Department of Transportation
- San Diego University
- Snowdon Award Scheme
- Statistics Canada
- Statistique Canada
- Texas State Library
- The Organisation Development Company
- The Original Teaching of Buddha
- University of Minnesota Duluth
- U.S. Department of Health and Human Services
Content owners should not have to re-author accessible content, already being delivered to legacy devices, for it to be valid and accessible HTML5.
Describing a Logo
Logos provide evidence of long descriptions for images already inside of a
link. Evidence of this pattern is supported by real world examples in the wild.
No evidence has been presented that this functionality is not needed. It is
impossible for other solutions such as rel="longdesc"
to provide this functionality.
Freedom of Choice
The following statement from the Zero Edit
Obsolete longdesc
Change Proposal is inaccurate:
Using the logo description as a “replacement for the original rendered content” would mean users with this function enabled would hear the long description of the image as the link text, which would be useless.
On the contrary, longdesc
allows screen reader users freedom of
choice. The description is not forced upon them whether they
want it or not. Screen reader users can choose to interact with it at their own
will. The content of the long text description is voiced only when the user
requests it. In other words with Longdesc
the user is informed that
longer textual description is available, and they need can easily request that
content be presented to them--or not. In no instance, however, is the content
automatically forced on them.
Longdesc
provides authors freedom of choice. Authors are already
providing this functionality, as evidenced by real world examples.
Equal Access
No evidence has been provided that blind users do not deserve or want access to the long description of a logo whilst at the same time being given direct access to the link to (e.g.,) an organization's home page.
This functionality is taken for granted by sighted users as they automatically
see what a logo looks like while being able to directly access a home page link.
Longdesc
provides this same functionality for screen reader users.
It is an accommodation.
The majority of blind people lose their sight later in life, either
progressively, or through an accident. They have understanding of vision and are
able to "visualize" what things look like in their mind's eye. This is an
important part of them. They appreciate descriptions. Some have described
themselves by saying, "I am blind.
I am a visual person. I just can’t see". Other people born blind may
not be interested in what such an image looks like. If they don’t want to
listen to the long description, they won’t. In either case,
longdesc
provides the user the with the opportunity for an equal
experience.
Separate Logo Link Is Not Programmatically Determinable
Programmatic determinability aids accessibility as previously explained. A separate logo description link as part of the navigation is not programmatically determinable. There is no relationship that indicates that the link has anything to do with the logo. With such a technique, a screen reader user may never know that a long description exists for a given image.
In contrast, a longdesc
is tied to the image that it describes
and provides explicit semantics, which in turn enables a higher degree of
accessibility.
Real World Sites Implement longdesc
on Logos
The logo use case is substantiated by real world examples in the wild. For example, as documented in the use case notes, the following sites provide logo functionality:
- AccessAbility SIG
- Alpen
- anblik
- Center for the Study of Religion and American Culture
- Fundación Sidar - Acceso Universal (Spain)
- haecceitas
- Indiana University-Purdue University Indianapolis Common Core Curriculum
- Santa Barbara Public Library
- Securian
- tech.burningbird
- ZEW
Content owners should not have to re-author accessible content, already being delivered to legacy devices, for it to be valid and accessible HTML5.
Alternative Techniques
As previously explained, the suggested alternatives are not viable. They do not meet requirements.
- For detailed rationale of why
aria-describedby
is not viable, please consult:- My full objection to the "Keep the
longdesc
attribute for theimg
element deprecated" proposal - Author Skill Sets Differ
- Not Being Forced Upon Users
- Supporting Structured Text
- My full objection to the "Keep the
- Custom CSS is not viable.
- Image map is not viable.
Existence of other approaches do not justify killing off
longdesc
. It is an unwarranted conclusion.
Users Who Desire Access Can Have It
As previously explained, any user who wants to access a longdesc
can do so by using
tools that support longdesc
.
Describing a Cartoon
Shelley Powers has explained the
need for longdesc
on cartoon images,
There is no better justification for a verbose descriptor/longdesc, though, than political cartoons, as I demonstrate over at Puppies @ Burningbird.
The argument that the material describing the image can be repeated in the page just doesn't fly. To repeat the image data textually, just before or after the image, not only detracts from the image, it lessens the impact the political cartoon intends.
At the same time, political cartoons are highly sophisticated bits of imagery, which can't be described in a small blurb in an alt attribute. They also provide essential information, because political cartoons are created specifically to convey important arguments about ongoing political and other activities.
The Zero Edit
Change Proposal: Keep Longdesc
Non-Conforming does not dispute
this need.
I have no qualms with other people using hyperlinks where they desire to provide alternate text. However, as a designer, I object to being told I must use those links myself. As you've pointed out on Twitter, the current design of the comic page would certainly support a hyperlink wrapping around the comic. However, my upcoming design already has functionality mapped to clicking the comic, and won't have space for a large "transcript here" hyperlink sitting around in plain sight (which would be distracting for the 99% of my users that are sighted). In that scenario, longdesc can and does serve my needs.
Functionality mapped to clicking a comic can be evidenced in sites such as dizABLED which utilizes an a href
around the cartoon image to go to the next
image in a series of comic images while simultaneously utilizing the longdesc
attribute to provide the long description.
Rejecting artistic requirements and design functionality requirements is not a
winning strategy for HTML5 or for accessibility. Reinstating
Longdesc
is.
Alternative Techniques
As previously explained, the suggested alternatives are not viable. They do not meet requirements.
rel="longdesc"
is not viable.- Custom CSS is not viable.
- For detailed rationale of why
aria-describedby
is not viable, please consult:- My full objection to the "Keep the
longdesc
attribute for theimg
element deprecated" proposal - Author Skill Sets Differ
- Not Being Forced Upon Users
- Supporting Structured Text
- My full objection to the "Keep the
Other Approaches:
- Normal visible text link with appropriate link text, with the link mentioned in the comic’s short text alternative (e.g., "Comic foo, see transcript link below"), fails cartoon use case constraints.
- Normal link with appropriate link text, adjacent to the image fails cartoon use case constraints and is not programmatically determinable.
-
figcaption
is not viable and fails cartoon use case constraints. -
details
is not viable and fails cartoon use case constraints.
Existence of other approaches do not justify killing off
longdesc
. It is an unwarranted conclusion.
Real World Sites Implement longdesc
on
Cartoons
The cartoon use case is substantiated by real world examples. Content owners should not have to re-author accessible content, already being delivered to legacy devices, for it to be valid and accessible HTML5
Expecting authors to rewrite their content to support pervasive and intrusive coding changes ignores aesthetics and infuriates authors.
Users Who Desire Access Can Have It
As previously explained, any user who wants to access a longdesc
can do so by using
tools that support longdesc
.
Describing Artwork
Artwork Use Case Constraints
Linking the thumbnails to pages with both the larger image and the long description as in-page content is not a solution:
- When the image link is mapped to go to a page other than a description. For
example, Dayton Art Institute's accessart site uses/used the
longdesc
for the long description and ana href
to go to a different "dialogue with the director" page. Thelongdesc
attribute was used for all images in the tours to describe images. The site seems currently seems to be down. But they Wayback Machine provides examples: Museum Highlights From the WayBack Machine and Long Description: Joy of Waters 1917 from the Wayback Machine). - When the aesthetic constraints prevail. Ignoring aesthetic considerations
is ignoring reality.
Longdesc
affords efficient reuse of one long description for both the large and small image. This helps content authors as they only have to author the description content once and can reuse it on multiple images. Reuse is powerful and a valuable pattern found in other languages for instance external cascading style sheets.
Alternative Techniques
As previously explained the suggested alternatives are not viable. They fail artwork use case constraints and do not meet requirements.
- For detailed rationale of why
aria-describedby
is not viable, please consult:- My full objection to the "Keep the
longdesc
attribute for theimg
element deprecated" proposal - Author Skill Sets Differ
- Not Being Forced Upon Users
- Supporting Structured Text
- My full objection to the "Keep the
- Custom CSS is not viable.
- Image map is not viable.
rel="longdesc"
is not viable.
Existence of other approaches do not justify killing off
longdesc
. It is an unwarranted conclusion.
Users Who Desire Access Can Have It
As previously explained, any user who wants to access to a
longdesc
can do so by using
tools that support longdesc
.
Real World Sites Implement longdesc
on
Artwork
The artwork use case is substantiated by real world examples in the wild. Content owners should not have to re-author accessible content, already being delivered to legacy devices for it to be valid and accessible HTML5.
Describing Screenshots
Real World Sites Implement longdesc
on
Screenshots
Real
world sites implement longdesc
for screenshots. As noted the
Oracle and IBM the examples in the wild provide visible text links in addition to
longdesc
. IBM Corporation provides redundant non-programmatic
determinable link text "below the fold" in the
endnotes. All of these links are not programmatically
determinable. Longdesc
is.
Redundant link text attempts to mitigate damages of user agents that do not
yet have a long description feature built directly into them. Because
longdesc
it is not yet supported by some web browsers, some sites
provide a fallback method of providing a full description via redundant link
text. With proper implementation in user agents these links could all be solely
longdesc
. The new spec text for the rendering section will help more
user agents implement longdesc
properly.
Content owners should not have to re-author accessible content, already being delivered to legacy devices for it to be valid and accessible HTML5.
longdesc
on Screenshots is Perceivable
As explained longdesc
is perceivable.
Alternative Techniques
As previously explained, the suggested alternatives are not viable; most are not programmatically determinable; they fail screenshot use case constraints; they do not meet requirements.
- For detailed rationale of why
aria-describedby
is not viable, please consult:- My full objection to the "Keep the
longdesc
attribute for theimg
element deprecated" proposal - Author Skill Sets Differ
- Not Being Forced Upon Users
- Supporting Structured Text
- My full objection to the "Keep the
- Custom CSS is not viable.
-
figcaption
is not viable. rel="longdesc"
is not viable.
Other Approaches:
- Normal link below the image and mention the link below in the image's short text alternative fails screenshot use case constraints.
-
figcaption
is not viable. rel="longdesc"
is not viable.
Existence of other approaches do not justify killing off
longdesc
. It is an unwarranted conclusion.
Users Who Desire Access Can Have It
As previously explained, any user who wants to access a longdesc
can do so by using
tools that support longdesc
.
Describing a Chart
Users Who Desire Access Can Have It
As previously explained, any user who wants to access a longdesc
can do so by using
tools that support longdesc
.
Chart Use Case Constraints
Both long description text in page or a visual link to a long description page add visual clutter for the sighted. As previously explained, a forced visual encumbrance for sighted users is information overload, which wastes time and taxes attention at the content's peril. That is a critical constraint.
Alternative Techniques
As previously explained, the suggested alternatives are not viable. They do not meet requirements.
- For detailed rationale of why
aria-describedby
is not viable, please consult:- My full objection to the "Keep the
longdesc
attribute for theimg
element deprecated" proposal - Author Skill Sets Differ
- Not Being Forced Upon Users
- Supporting Structured Text
- My full objection to the "Keep the
- Custom CSS is not viable.
-
figcaption
is not viable and fails chart use case constraints. -
details
is not viable and fails chart use case constraints.
Other approaches:
- Providing the information in the graph as part of main commentary within the page text is not programmatically determinable and fails chart use case constraints.
- Provide an adjacent normal link that is not programmatically tied to the image is not programmatically determinable and fails chart use case constraints.
Existence of other approaches do not justify killing off
longdesc
. It is an unwarranted conclusion.
Real World Sites Implement longdesc
on Charts
The chart use case is substantiated by numerous real world examples in the wild.
- Accessibility Task Force Bug Comparisons
- Accessibilité du Web
- Commonwealth of Massachusetts
- Federal Motor Carrier Safety Administration
- Environment Canada
- Financial Transactions and Reports Analysis Centre of Canada
- Griffith University
- Hawaii Public Schools
- Korea Employment Information Service
- Michigan State University National Institute of Information and Communications Technology
- National Adult Literacy Database, National Institutes of Health, National Institutes of Health
- Natural Resources Canada
- Public Service Commission of Canada
- Research and Innovative Technology Administration / US Department of Transportation
- Statistics Canada
- Statistique Canada
- U.S. Department of Health and Human Services
- San Diego University
As previously mentioned sister sites Statistics Canada
and Statistique Canada
are using longdesc
on charts in "The Daily" publication. This is
concrete evidence of continuing growth.
Content owners should not have to re-author accessible content, already being delivered to legacy devices for it to be valid and accessible HTML5.
Describing a Photograph
Users Who Desire Access Can Have It
As previously explained, any user who wants to access a longdesc
can do so by using
tools that support longdesc
.
Alternative Techniques
As previously explained, the suggested alternatives are not viable. They do not meet requirements.
- For detailed rationale of why
aria-describedby
is not viable, please consult:- My full objection to the "Keep the
longdesc
attribute for theimg
element deprecated" proposal - Author Skill Sets Differ
- Not Being Forced Upon Users
- Supporting Structured Text
- My full objection to the "Keep the
-
figcaption
is not viable and fails photograph use case constraints. -
details
is not viable and fails photograph use case constraints. - A normal link on the image fails photograph use case constraints.
rel="longdesc"
is not viable.
Other approaches are not programmatically determinable. Programmatic determinability aids accessibility. Without programmatically determinability no explicit relationship exists to indicate that a long description has anything to do with an image.
Existence of other approaches do not justify killing off
longdesc.
It is an unwarranted conclusion.
Describing an Email Banner
Images in email are a significant and valid use case because email is a major form of communication. Email has changed the shape of our lives and become a major form of communication. According to a Radicati Group Study, billions of email messages are sent every day. By 2014, it is estimated that there will be some 2.5 billion e-mail users worldwide.
As the email banner use case demonstrates, if a long description of an image is needed it can not be provided in the body of the email when constraints include:
- The fact that the email's format is a short digest.
- Organization's design guidelines or branding requirements preclude it.
These constraints are evidenced by 2011 real world usage.
Email Banner Images Are a Valid Use Case for
longdesc
No evidence has been provided that blind users do not deserve or want equal access to descriptions of banner images. The majority of blind people lose their sight later in life, either progressively, or through an accident. They have understanding of vision and are able to "visualize" what things look like in their mind's eye. This is an important part of them. They appreciate descriptions. Some have described themselves by saying, "I am blind. I am a visual person. I just can’t see".
"A longdesc is a long description of an image...The aim is to use any length of description necessary to impart the details of the graphic. It would not be remiss to hope that a long description conjures an image - the image - in the mind's eye, an analogy that holds true even for the totally blind."
Other people born blind may not be interested in what such an image looks
like. If they don’t want to listen to the long description, they
won’t. In any case, providing longdesc
provides user
choice.
Critical Content Images in an email are a Valid Use Case for
longdesc
An email image that is content is also a valid use case for
longdesc
. If the information contained in an image is important to
the meaning of the page (i.e. some important content would be lost if the image
was removed), a longer description than the "alt" attribute can reasonably
display should be used. Longdesc
provides for rich, expressive
documentation of a visual image while allowing for afore
stated constraints.
Alternative Techniques
As previously explained, the suggested alternatives are not viable. They do not meet requirements.
- For detailed rationale of why
aria-describedby
is not viable, please consult:- My full objection to the "Keep the
longdesc
attribute for theimg
element deprecated" proposal - Author Skill Sets Differ
- Not Being Forced Upon Users
- Supporting Structured Text
- My full objection to the "Keep the
- Custom CSS is not viable.
- Image map is not viable.
Existence of other approaches do not justify killing off
longdesc
. It is an unwarranted conclusion.
Users Who Desire Access Can Have It
As previously explained, any user who wants to access a longdesc
can do so by using
tools that support longdesc
.
Describing Illustrations
Users Who Desire Access Can Have It
who wants to access an email longdesc
can do so by using
tools that support longdesc
.
Author Skill Sets Differ
As previously explained, a different skill set exists between JavaScriptlLibrary/app developers and the run of the mill content authors/web designers.
For detailed rationale regarding author skill set please refer to my objection the Zero Edit/Obsolete proposal.
In addition, training budgets for organizations such as libraries have been slashed, for instance, Jacksonville mayor cuts library's travel and training budgets, Ohio Libraries have cut staff training, Proposed Budget in Texas Nearly Zeros Out Key State Library Funds, Texas Governor Signs Budget Cutting State Funding for Library Services by 88 Percent, Texline 265: Proposed Budget Demolishes Statewide Library Programs Eliminates the Technology Allotment at TEA, 'Depression' Era Budget Cuts Could Shutter Libraries, State budget cuts hit rural libraries hard. In today's economic climate new training for run of the mill content authors/web designers is seldom an option leaving these workers with existing skill sets.
Alternative Techniques
rel="longdesc"
is not viable.- For detailed rationale of why
aria-describedby
is not viable, please consult:- My full objection to the "Keep the
longdesc
attribute for theimg
element deprecated" proposal. In particular please refer to the "Description Available in a Separate Document is a Key Author" section. - Author Skill Sets Differ
- Not Being Forced Upon Users
- Supporting Structured Text
- My full objection to the "Keep the
- A normal link fail illustration use case constraints.
Other approaches:
- A normal link on the image fails illustration use case constraints.
- Normal structural markup to provide the text content does provide illustrations.
- Custom CSS is not viable.
-
details
is not viable and fails illustration use case constraints.
Existence of other approaches do not justify killing off
longdesc
. It is an unwarranted conclusion.
Real World Sites Implement longdesc
on Charts
The chart use case is substantiated by real world examples in the wild. Content owners should not have to re-author accessible content, already being delivered to legacy devices for it to be valid and accessible HTML5.
Facilitating/Describing etext Image Descriptions
etext images are a valid and significant use case. On March 11, 2011 Jim
Fruchterman, Geoff Freed, and George Kerscher indicated that professional
content producers (such as those involved in the ePub initiative, or the US
federally funded DIAGRAM Project) indeed wish to use longdesc
to
meet their existing etext requirements to externally store descriptions in a
non-visual manner. Their testimony to the HTML working group in support of
reinstating longdesc
into HTML5 states,
We are writing on behalf of the Digital Image and Graphic Resources for Accessible Materials Center (DIAGRAM; http://diagramcenter.org/) in support of the reinstatement of @longdesc into HTML5 (http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc). We believe that omitting @longdesc from HTML5 would be a serious blow to the cause of accessibility, and would set back nearly two decades of work by accessibility researchers, technologists and educators throughout the world.
Other international working groups, such as those developing recommendations for digital talking books (DTB) and e-books (EPUB), look to HTML5 for guidance and conformance. Without a specified method for providing long descriptions, it is entirely possible that HTML documents, e-books and DTBs will wind up providing long or detailed descriptions in independent and perhaps incompatible ways. Such confusion in the delivery of long descriptions will undoubtedly result in a delay and/or reduction in the accessibility of textbooks with obvious negative impacts for students with print disabilities. Furthermore, as textbooks, electronic media content, Web browsers, mainstream e-readers and assistive technology continue to merge and are used interchangeably, a single universal standard for providing high-quality detailed image descriptions is essential.
Removing @longdesc from HTML5 without replacing it with superior technology puts people with print disabilities at a severe disadvantage. It is not possible to overstate the importance of having long-description support in HTML5. In its current state, @longdesc is the only method for authors to provide externally stored descriptions in a non-visual manner to users with print disabilities. @longdesc is in widespread use (http://www.d.umn.edu/~lcarlson/research/ld.html), and it is supported by widely available access technologies. Because @longdesc can point to external resources, it can deliver high-quality, detailed descriptions in a method that no other element, attribute or property can provide today. Without this attribute, authors of Web sites, electronic textbooks and other digital resources have no way to efficiently deliver long image descriptions to users with print disabilities. Access to educational materials, some of which are mandated by national laws, will be disrupted for countless blind and visually impaired students worldwide.
The Facilitating etext Image
Descriptions and Describing etext
Images use cases point to longdesc
as the best solution.
Bill facilitates
etext the creation of image descriptions by procuring a database system that
utilizes longdesc
. Susan, an
experienced volunteer trained in writing image descriptions,
creates the descriptions.
longdesc
not only fulfills requirements but also provides
efficiency in this use case:
- The description file is in a single central location, which simplifies creation by a group.
- When an external
longdesc
is used, one description file can globally control all instances of an image. This is powerful. It makes maintenance quite easy when a number of images exist in numerous books. - Lowers costs by lowering bandwidth use.
Longdesc
allows for leaner code overall - you only do your http transport on demand, resulting in smaller, faster pages, and reduced bandwidth consumption. Those who don't need the description are spared the extra bandwidth. etext sizes are smaller, quicker to load. - etext markup reduced in complexity as descriptions are external to the book.
Alternative Techniques
-
figcaption
is not viable and fails facilitating etext image descriptions image use case constraints as well as describing etext Image descriptions image use case constraints. rel="longdesc"
is not viable.
Existence of other approaches do not justify killing off
longdesc
. It is an unwarranted conclusion.
Users Who Desire Access Can Have It
As previously explained, any user who wants to access a longdesc
can do so by using
tools that support longdesc
.
Describing a Newspaper Image
Where an image is cropped has no bearing on the validity of the use case. A use case in software engineering and systems engineering, is
a description of steps or actions between a user (or "actor") and a software system which leads the user towards something useful.
The actors in the newspaper Image use scenario added value to their work in step-by-step action while adhering to constraints. The result is that both sighted and unsighted audiences are well served. Content is customized in accordance with user needs and capabilities making this a valid use case.
Alternative Techniques
- A normal link fails describing a newspaper image use case constraints.
- For detailed rationale of why
aria-describedby
is not viable, please consult:- My full objection to the "Keep the
longdesc
attribute for theimg
element deprecated" proposal - Author Skill Sets Differ
- Not Being Forced Upon Users
- Supporting Structured Text
- My full objection to the "Keep the
- Custom CSS is not viable.
-
figcaption
is not viable and fails describing a newspaper image use case constraints.
Existence of other approaches do not justify killing off
longdesc
. It is an unwarranted conclusion.
Users Who Desire Access Can Have It
As previously explained, any user who wants to access a longdesc
can do so by using
tools that support longdesc
.
A Direct Functional Replacement is the Wrong Approach
This
Zero Edit Change Proposal: Keep Longdesc
Non-Conforming had one
thing correct. A direct functional replacement is the wrong approach. It reinvents
the wheel. Longdesc
provides the needed functionality.
longdesc
is Perceivable
The
Zero Edit/Obsolete longdesc
Change Proposal accused
longdesc
of being a secret. The question is, "a secret from
whom?".
- It is perceivable by its target audience, while those who can process an image visually already have the image itself to provide them that very same information.
- It is programmatically determinable/machine readable. So user agents and tools can (many already do and more will with the new spec text for the rendering section) provide ways to make it available to others who may like access.
As Joseph C. Dolson has explained,
For most users, perceivable content is visual. Your visitors view video clips, see images of your products, and read your descriptive texts. Perceivable content applies to the visual aspect of your website. But other aspects include providing a version of your content that is available for users who require other modes of sensing it.
That sounds complex, but all it really requires is that information be provided in a machine-readable text format. Computers can easily and efficiently take text and convert it into Braille or audio, but they can't work with graphics, video, or audio in nearly as effectively.
These later formats must be made available in a "text equivalent," which provides the meaning of the content it represents.
longdesc
provides a text equivalent of visual content that is
available for users who require another mode of sensing it in a machine-readable
format. Longdesc
as a secret is a fallacy.
Alleged Incorrect Usage is a Hollow Argument
The Zero
Edit/Obsolete longdesc
Change Proposal parrots the same alleged
longdesc
usage problems as stated in Maciej
Stachowiak's 2010 change proposal. As the
prior Issue 30 decision determined, objections on this matter are weak and not
clearly established.
However, even if it was established, an incorrect usage argument is hollow. Many
web pages have incorrect usage i.e., duplicate id
values when they
should be unique on a page. Arguing that some authors use longdesc
ineffectively is no more sensible than arguing that we must obsolete the
id
attribute because some authors or spec
writers get it wrong. The argument is specious and a waste of time.
Incorrect usage is not the fault of a mechanism. Almost every attribute and element is incorrectly coded or applied in ways not intended. That does not mean the feature is useless and should be killed. It only means specification, education, or tools may need improvement.
Reinstating Preserves Hard-Won Progress
Access for people with disabilities is essential. This does not mean that features should be made obsolete if not all users can fully make use of them but rather that mechanisms that have a foothold must be retained. As Bill Shackleton has stated,
...an essential flaw in the key reasoning, as I understand it, to remove
longdesc
is in assuming that because its past effectiveness has been limited, it is doing more harm than good. That is to say, that because of poor implementation - by user agents, by content authors, etc. - it should therefore be removed.I respectfully disagree. Much accessibility work takes time and yes, some of that time includes the need for awareness and training. In my experience, progress in accessibility has rarely been consistent or even linear... And it is definitely not binary.
It progresses in fits and starts and even, unfortunately, backslides. That's why it's important, in this case as in others, to wedge in a backstop to preserve hard-won progress. Fortunately it is fundamental W3C policy that everyone be included (regardless of disability). This means that the burden of proof does not lay with the accessibility community to make the case for maintaining
longdesc
in the next version of HTML, but with those who wish to remove it.
HTML5's Cool Factor (Future Advancement)
Longdesc
has a starting position from which further advances can be
made. The hard-won progress that Bill Shackleton speaks of can be advanced further
by HTML5. HTML5 has significant buzz and is considered to be "cool". Reinstating
longdesc
into HTML5 will give:
- Educators the opportunity use HTML5's appeal when teaching
longdesc
. - Authors the opportunity "to be cool" by using HTML5's
longdesc
. - User agents the opportunity be part of the buzz when integrating HTML5's new
longdesc
rendering spec text. As Anne van Kesteren has said, examples in the specification serve as an incentive to vendors:
It's an incentive to get the software fixed."
Because HTML5 is a hot topic, reinstating it will engender
longdesc
's progress.
No Evidence That Obsoleting Brings Improvement
No evidence has been presented that obsoleting longdesc
will
provide more accessible content than including longdesc
in HTML5. It
would strip a useful mechanism from authors who in fact have and are using it to
improve accessibility.
Conclusion
I object to the Zero
Edit/Obsolete longdesc
proposal for a multitude of reasons as
detailed in this document.
The Zero Edit/Obsolete longdesc
Change Proposal fails to provide
(a) any evidence that it would be difficult or impossible for additional browser
vendors to make good use of longdesc
, (b) an accurate assessment of
use cases, (c) any evidence that a substantial number of authors would use other
techniques (or use them correctly), and (d) any evidence that obsoleting
longdesc
would provide more accessible content.
Longdesc
solves problems and makes things better. Concrete, ample,
and compelling evidence of over 1400 examples in the wild verifies beyond a
reasonable doubt that authors do in fact implement longdesc
in ways
that improve accessibility in practice. Valid use cases clearly and directly
support this specific feature of the language. Other proposed solutions do not meet
requirements or constraints and do not have an existing critical support base of
tools and educational materials.
Longdesc
strengthens the language. Other techniques are retrograde,
makeshift substitutes that do not directly provide the valuable native semantics
and critical backwards compatibility that longdesc
does. No better
technical solution exists. The existence of related techniques does not justify
obsoleting this attribute. Longdesc
is perceivable to its target
audience and new spec text will help browser vendors make it more discoverable to
others. No negative consequences exist for including longdesc
in
HTML5.
People with disabilities would be the losers if longdesc
were
removed from HTML in favor of this proposal. It would be an unnecessary atrocity on
authors and users with disabilities.