longdesc
Improves Accessibility in Practice
It has been substantially evidenced via the documentation of over two thousand 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
- ACCESS-ed: University of Wisconsin - Milwaukee
- Aboriginal Affairs and Northern Development Canada
- AccessAbility SIG
- Accessibilité du Web (Canada)
- Assisted Human Reproduction Canada
- Alienor (France)
- algebraicthunk
- Agencia de Calidad Sanitaria de Andalucía (Spain)
- 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.
- Calderdale Council
- California Department of Fish and Game
- 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
- Capita
- City of Florence (Italy)
- Commonwealth of Massachusetts
- Connexions
- Conseil supérieur de la langue française
- Cornell University
- Correctional Service Canada
- Courts Administration Service (Canada)
- CSS Squirrel
- Dayton Art Institute
- 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)
- Division of Cancer Epidemiology & Genetics, National Cancer Institute
- ebility.com
- Education Place
- Elections Canada
- Environment Canada
- Environnement Canada
- F*ckparade (Germany)
- Fakoo (Germany)
- Federal Deposit Insurance Corporation
- Federal Motor Carrier Safety Administration
- Financial Transactions and Reports Analysis Centre of Canada
- Free Technology Academy
- 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
- 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
- Immigration and Refugee Board of Canada
- 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
- 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)
- Lambda Theta Phi Latin Fraternity
- Linux Foundation
- Local Government Commission
- London Canal Museum
- Lusophone countries - Convention on the Rights of Persons with Disabilities (Portuguese)
- Marden Neighbourhood Plan
- Marine National Park (Taiwan)
- Mecanizados EKIMEN
- 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
- Museum of Australian Democracy
- 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 Institute of Dental and Craniofacial Research
- National Institute of Standards and Technology (NIST)
- National Institutes of Health (Canada)
- National Institutes of Health (United States)
- National Institute on Drug Abuse (United States)
- National Property Administration Office in Central Taiwan
- Natural Resources Canada
- National Transportation Safety Board
- New Zealand Department of Labor
- nota-ben (France)
- Nick's Mathematical Miscellany
- Northern Ireland Planning Service
- Object Description
- Ocean Motion
- Office of the Superintendent of Financial Institutions Canada
- Office of the Deputy Under Secretary of Defense
- Ohio Dental Clinics
- Ohlone College
- Oracle
- Oriental Hospital of Daejeon University (South Korea)
- Parcs Canada
- Parks Canada
- Parliament of Canada
- Paris Web
- Panel on Responsible Conduct of Research (Canada)
- PC Net (Japan)
- Pessimistic Dot Com
- Procréation assistée Canada
- Province of Gyeongsangbuk (South Korea)
- Public Safety Canada
- Public Service Commission of Canada
- Public Works and Government Services Canada
- Rebuilding The Web
- Régie des rentes du Québec
- Research and Innovative Technology Administration / US Department of Transportation
- Resources naturelles Canada
- San Diego University
- Santa Barbara Public Library
- State of California
- Secrétariat du Conseil du Trésor du Canada, Les rapports sur les plans et les priorités
- Securian
- Sésame Province de Luxembourg (Belgium)
- Snowdon Award Scheme (UK)
- Social Security Online
- South West Institute of TAFE
- Specific Claims Tribunal Canada
- Special Education Support Center (South Korea)
- Standard Chartered Leading the way in Asia, Africa, and the Middle East
- statedata.info
- Statistics Canada (English)
- Statistique Canada (French)
- Substance Abuse and Mental Health Services Administration (SAMHA)
- Syngenta
- Talk Origins
- tech.burningbird
- 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
- Transport Canada
- Transportation Safety Board of Canada
- Treasury Board of Canada Secretariat
- Tribunal des revendications particulières Canada
- 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 Navarra
- University of Texas
- University of Texas at Austin
- University of Victoria
- University of York
- 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
- Wengo
- Yasui (Japan)
- 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 Adds Visual Clutter
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.
Jonas Sicking publicly acknowledged and accepted that this constraint is valid in his change proposal saying that,
page designers often have quite strict requirements on the visual appearance of the page and it would likely negatively impact the level of accessibility support if contents specifically for for example screen readers had to be provided within those requirements.
A forced visual encumbrance 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
attribute is natively free from a visual encumbrance. It solves
a problem as 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 eighteen hundred real world images that do not force a visual
encumbrance for a long description by using longdesc
. As
this compelling pattern evidences, circumstances do indeed exist where page authors need, desire, and utilize
longdesc
due to this constraint.
Allowing Discoverability Serves Use Cases
Scott Berkun has explained the myth of discoverability,
The myth of discoverability, in concise form: The belief that all good user interfaces make all things in the website or product utterly and extremely discoverable, and any design that makes an element (button, link, etc.) less than extremely discoverable, can't possibly be very good, and should be thrown away, to the embarrassment of the designer...All things can not be easily discoverable because everything is limited.
The fact is that, some people may want or need to consume or access long description content that doesn't force a visual encumbrance but do not use assistive technology (AT). The following sighted people may be aided by access to a longdesc:
- Users who have a cognitive or visual impairment.
- Users with either a keyboard or pointing device without screen reader or assistive technology.
- Users with a custom input accommodation, such as a mouth-stick or sticky keys.
- Users who have small screens (e.g. mobile phone or screen magnifiers).
- Users who turn off images to decrease bandwidth use in order to lower their Internet usage fees.
- Authors, for ease of authoring, testing, and maintenance purposes.
Existing Discoverability Tools Fulfill These Use Cases
Discoverability
tools exist for longdesc
. These tools are used by sighted authors
and others. 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.
The Include
longdesc
in HTML5 change proposal provides a solution to the
forced visual encumbrance constraint while specifying
discoverability functionality for all who want access to the description. 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.
No discoverability tools exist for proposed solutions such as
hidden.
Incentive for More Discoverability Tools
On May 5, 2012, HTML Co-Chair, Maciej Stachowiak stated,
if a UA can give a better experience i think they should be encouraged to try
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. It
will encourage them to improve support. 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.
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.
Semantics Improve Communication
Semantic elements and attributes provide 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.
HTML5 Precedent
The rationale that HTML5 should have built-in semantics was successfully used to
keep <figure>
, <aside>
,
<details>
, and hidden
in the specification. The
Retain several newly-introduced semantic elements, attributes, and controls
change proposal stated,
Semantics are universal. Expressing semantics with native elements promotes Universal Access better than expressing semantics just to users of AT by using ARIA attributes.
The decisions on those issues set the precedent that native HTML semantics is a strong determining factor of what is included in the language.
WAI-ARIA Provides Missing Semantics
The bridging technology, aria-describedby
, and aria-describedat
sections of this document provide full
explanation of why ARIA is not viable. Shirking off the responsibility of providing
long description semantics to ARIA is retrograde. In other words, the premise is
entirely backward. ARIA should be used to augment missing native semantics of HTML
as necessary, not as an excuse to kill and to replace them.
As the Accessible Rich Internet Applications (ARIA) specification states,
WAI-ARIA is intended to provide missing semantics
HTML is Not Missing Native Semantics
HTML is not missing long description semantics. It possesses
native, built-in long description semantics that are conveyed to assistive technologies as well as other technologies with
longdesc
.
The longdesc
attribute is unequivocally the
most clear, direct, explicit, and strong semantic with the
broadest support base for providing a long description
of an image above and beyond any other attribute or element.
This undeniable semantic requires no heuristics to interpret which consequently enables precise programmatic determinability to take place.
Using a Bridging Technology is Backward
Bridging technologies are not intended to replace native HTML semantic features. Detouring accessibility technical requirements into an "Accessible Rich Internet Applications" bridging specification is backward.
The Introduction to ARIA clearly states,
WAI-ARIA is intended to be used as a supplement for native language semantics, not a replacement. When the host language provides a feature that provides equivalent accessibility to the WAI-ARIA feature, use the host language feature.
The Protocols and Formats (PF) Working Group's Charter states,
Note that WAI-ARIA is intended to be a bridging technology. It is expected that, over time, host languages will evolve to provide semantics for objects that currently can only be declared with WAI-ARIA.
This was reinforced by Al Gilman, prior PF Chair, on behalf of that Working Group,
The working group likes the idea of having built in semantics in HTML and in particular would prefer to have common document elements, such as widgets built in to the markup. This reduces download size and the effort required to make a web page accessible. For these reasons, we would promote the use of such markup over the ARIA approach.
The idea was that native mechanisms would enrich the vocabulary of the language, thus rendering ARIA increasingly unnecessary.
As Derek
Featherstone has stated, "ARIA is designed to provide accessibility at a
technical level - what you might call 'programmatic accessibility' - where it
doesn't already exist". Longdesc
exists.
WAI-ARIA Goal and Dangers
A significant goal of WAI-ARIA is to:
help stimulate the emergence of more semantic and accessible markup. When native semantics for a given feature become available, it is appropriate for authors to use the native feature and stop using WAI-ARIA for that feature.
WAI ARIA should only be used as a last resort when content can't be made accessible using the host language. Everett Zufelt commented on HTML5 Doctor,
There are huge dangers in using ARIA instead of natively supporting accessibility in HTML5, these are not technical in nature. The longer the broader development community, such as the HTMLWG, ignores accessibility, or thinks that others like the PFWG / WAI will take care of it for them, the longer we will need technologies like ARIA to fill in the blanks.
Karl Groves illuminated the main point in his article "Confusion over HTML5 & WAI-ARIA",
The HTML specification is the shortest path to true accessibility
HTML is the direct route.
the whole point of ARIA is to make semantic abuse accessible as an afterthought.
In other words ARIA is bandage meant to patch.
It is perhaps Ian Hickson who states the case best when he says that ARIA,
is not intended for use by authors who are trying to convey the very semantics that HTML can already convey.
Shirking Off Long Description Semantics to ARIA
HTML has native, built-in long description semantics with
longdesc
.
Keeping it core to the language keeps valuable semantics in HTML. It provides forethought, which thereby reduces the need for ARIA to be used as an accessibility afterthought.
The idea of HTML obsoleting longdesc
, a native semantic attribute,
and shirking off the responsibility of providing long description semantics to ARIA
is retrograde. In other words, the premise is entirely backward.
ARIA should be used to augment missing native semantics of HTML as necessary, not as an excuse to kill and to replace them.
Author Skill Sets Differ
People of Limited Skill Set Use
longdesc
Use cases demonstrate that people of limited skill set use longdesc.
The primary
actors in use
cases 1, 2, 5, 6, 7, 8, 9b, and 10 are not skilled developers but content
authors, namely a:
- Cartoonist
- Group of Librarians
- Information Technology Professional
- Journalist
- Photographer
- Task Force Member
- Volunteer Describer (subject matter expert and technology novice)
- Web Designer
These use cases demonstrate that people of limited skill set use HTML's
longdesc.
It offers a solution for run of the mill content authors/web
designers whereas other solutions do not. Obsoleting longdesc
would
strip a useful mechanism from authors of limited skill set who are using it to
improve accessibility.
Need for Simplicity
Complexity confuses and leads to errors. This is especially true when complexity
is imposed directly on run of the mill content authors/web designers.
longdesc
is simple. As
Kyle Weems illuminated,
are we going to pretend that using
longdesc
is difficult? Yes, people may use it wrong without some correction, but simply saying "Hey, put a URL there," is not complex at all
The Association of American Publishers (AAP) concurs. In regard to their production processes and quality assurance the AAP has provided first-hand testimony to the working group stating,
The
longdesc
attribute is easy to code.
As a rule, the more complex the markup pattern, the more likely authors are to make mistakes when implementing it. We should strive to find the simplest markup patterns that satisfy requirements.
Need for Support Tools
Without WYSIWYG authoring tools run of the mill content authors/web designers authors would be disenfranchised. They rely on tools to author and test long descriptions.
It has been well established that numerous WYSIWYG web designer authoring
tools support longdesc
. An array of tools exist to
author longdesc
and to check that the
longdesc
works.
Authors rely on tools to test long descriptions. Two browsers (Opera, iCab) natively support longdesc
link 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 including Jim Thatcher's powerful long description favelet, which provides universal functionality of longdesc
in browsers such as Chrome, FireFox, Internet Explorer, and Safari.
No tools for other solutions such as
aria-describedby
/hidden
exist to allow authors to create
and test long descriptions.
Indeed, authoring tool vendor Vlad Alexander has provided first-hand testimony stating,
Authoring tool vendors are likely to find it difficult (or even impossible) to build user-friendly interfaces that use the
aria-describedby
feature. This is likely to result in confusion and little use of the feature.
He confirmed on July 5, 2011 that,
As an authoring tool vendor, we will not be supporting ARIA for content in XStandard, and I cannot see that many other tool vendors will support it either. Implementing ARIA for content does not make business sense for authoring tool vendors, because the non-technical content authors who buy our tools will find it far too complex to use, and because using ARIA for content does not produce better results than existing accessibility features.
Need for Educational Materials
A longdesc
support base exists in the form of authoring
documentation, tutorials, books etc.
No evidence exists that substantial ARIA documentation or tutorials are in place and ready to educate developers. In fact, on June 18, 2011 Paul Irish said,
Most developers have no idea how to implement ARIA. The W3C Primer that looks like a spec is just.. laughable.. not at all appropriate for a web developer audience.
This situation has not changed. On June 1, 2012 Paul Irish repeated that statement,
Most developers have no idea how to implement ARIA. The W3C Primer that looks like a spec is not at all appropriate for a web developer audience.
In contrast a longdesc
support base already exists
in the form of authoring tools, tutorials, books etc. These longdesc
support materials will live
on.
Training Budget Limitations
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.
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
- Texas AFT Survey Shows Destructive Budget Cuts Hitting Students and Teachers Hard
- State budget cuts hit rural libraries hard
- California Budget Cuts State Funding for Libraries
Different Techniques Require Different Skills
Pitting ARIA and longdesc
against each other is counter-productive
to accessibility. It should not be an either/or situation.
ARIA Skill Set
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.
It is recommend [Freedom Scientific 2012 (doc file)] that Web page authors,
read the ARIA best practices guide carefully before adding ARIA markup to their pages.
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.
ARIA adds needless complexity, As Christian Heilmann stated,
If you dive into ARIA you will realise very quickly that it is a lot of work, hard to understand concepts and above all a lot of code to write. Instead of having accessibility as an integral part of HTML5, we have to deal with two parallel standards. One to achieve things quickly and move the web from documents to applications and another one to keep it available for everyone out there. This is not a good place to be in. Accessibility happens when you embrace it from the very start.
The fact is that it is far more complicated for ordinary authors and designers
to author hidden relationships than provide a simple link via a
longdesc
attribute.
No one would want redundant text on-screen, as it would state what is visually
evident. So to use aria-describedby
, a person would have to write the
content, then hide it, and then reference the hidden text with
aria-describedby
using hidden relationships. That's so burdensome that
surely even the most enthusiastic ARIA supporter should realize that the
longdesc
attribute is far more efficient.
Vlad Alexander thoroughly explains in the article Is ARIA for content
doomed to failure? how the aria-describedby
technique is far too
complex. The capacity for author error is great. Likely errors include but are not
limited to:
- Getting
ID
naming rules wrong. - Logical errors, such as circular references.
- Accidentally deleting the description leaving
aria-describedby
referencing a non-existentID
. - Accidentally overwriting the description with unrelated content leaving aria-describedby pointing to content that is not a description of the given element.
The potential for confusion is rife especially for ordinary content authors and
designers and the result is that accessibility will suffer. In fact even ARIA
experts have gotten ID
naming wrong and publish incorrect
ID
examples in the W3C WAI-ARIA 1.0 Authoring Practices
specification.
The aria-describedby
/hidden
technique is complex.
Longdesc
is easier to understand and put into practice. No evidence
has been presented that authors will get aria-describedby
correct more
often than longdesc
.
Cascading Style Sheet Skill Set
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.
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).
The repercussions for ordinary authors of HTML5 having to resort to CSS was pointed out on February 19, 2012 in Bug 16026. It states that HTML5 is,
unnecessarily biased towards integration with CSS, and is considerably more complicated and thus incredibly inaccessible to most average casual users of the web.
Hiding long description indicators and descriptions 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 previously explained, 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 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. This technique 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.
Forcing Descriptions on Users is Harmful
Forcing users to listen to long descriptions is an extremely negative and harmful user-experience, as John Foliot has explained
The ability to (mentally and literally) pause, step outside of the page flow to get a description of a complex image (because you cannot see it) and then return to the content flow AT EXACTLY THE SAME PLACE YOU LEFT OFF is a design feature, not a flaw. The key point about @longdesc (for screen readers) is that they are given a *choice* as to whether or not they want to hear what some might consider extraneous data or not - it is the difference between glancing at a sophisticated pie chart (for example) versus studying it. You, as a sighted user, have that choice (to glance or study), yet insisting that the full-on textual description be inserted into the content flow because the user is blind is tantamount to me holding your head in a fixed position and insisting that you explain aloud to me that pie chart before I allow you to continue reading the rest of the page.
@longdesc is about user-choice!
With aria-describedby
the description is forced upon screen reader
users whether they want it or not. It is read aloud without any user intervention,
forcing the screen reader user to listen to it each and every time they encounter
the image. The user is not able to control how they
interact with the long description.
As the Association of American Publishers states,
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.
In addition AAP goes on to explain what a confusing user experience this can create,
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.
Such behavior makes aria-describedby
a non-starter. None of this is a problem with longdesc
as it supplies
descriptions on-demand and not by force. Non-sighted users (using a screen reader that supports longdesc
) are presented with a) advice/notification that a longer description is available, and b) the opportunity/choice to either pursue that longer description, or skip past it and continue with the normal page content. This choice is a critical user-requirement.
Structured Markup Facilitates Critical Functionality
Structured markup encodes information about the structural role of elements that in turn enables functional long description content. It is apparent [Jordan, 2006] that,
For accessibility, structural markup is important because software can use structure to perform functions for the user and provide better access to page content. For example, software that reads web pages, such as voicing browsers and screen reader software, can audibly differentiate headings from other text so that the information structure of the page is communicated to non-visual users. In addition, software can provide optional views such as heading lists, which display a list of headings; or heading reading mode, which reads only headings, giving non-visual users a means to quickly skim a document.
Screen readers help their users find and jump to the information that they need more quickly by using keyboard shortcuts for headings, tables, lists etcetera.
JAWS Examples
JAWS (Job Access for Windows and Speech) is a popular screen reader program created by Freedom Scientific that allows people who are blind to gain access to information on their computers. It utilizes structural markup to enable keyboard commands that provide users functionality. The following are some examples.
Function | Keyboard Command |
---|---|
List Headings | INSERT+F6 |
Next Heading | H |
Prior Heading | SHIFT+H |
First Heading | INSERT+ALT+HOME |
Last Heading | INSERT+ALT+END |
Next Heading at Level | 1 through 6 |
Prior Heading at Level | SHIFT+1 through 6 |
First Heading at Level | INSERT+ALT+CTRL+1 through 6 |
Last Heading at Level | INSERT+ALT+CTRL+SHIFT+1 through 6 |
Function | Keyboard Command |
---|---|
Prior Paragraph | CTRL+UP ARROW |
Next Paragraph | CTRL+DOWN ARROW |
Current Paragraph | CTRL+NUM PAD 5 |
Function | Keyboard Command |
---|---|
Next List | L |
Prior List | SHIFT+L |
Select List | F8 |
List All Ordered, Unordered, and Definition Lists | INSERT+CTRL+L |
Next Item in a List | I |
Prior Item in a List | SHIFT+I |
Next Division | Z |
Prior Division | SHIFT+Z |
List Divisions | INSERT+CTRL+Z |
Function | Keyboard Command |
---|---|
Next Same Element | S |
Prior Same Element | SHIFT+S |
Next Different Element | D |
Prior Different Element | SHIFT+D |
Move to Beginning of the Current Table, List, or Element | WINDOWS Key+HOME |
Move to End of the Current Table, List, or Element | WINDOWS Key+END |
Next Element | SHIFT+PERIOD |
Prior Element | SHIFT+COMMA |
Select Entire Element | F8 |
Display Element Information | INSERT+SHIFT+F1 |
Display Detailed Element Information | INSERT+CTRL+SHIFT+F1 |
Key board shortcuts have always provided critical table functionality. In July 2012 JAWS 13 introduced a new simplified layer for navigating tables, which streamlines the process even further. Press and release INSERT+SPACEBAR, followed by T to get to the table layer. Then press any of the following keystrokes.
Function | Keyboard Command |
---|---|
Move by cell | ARROW Keys |
Move to beginning or end of a column or row | CTRL+ARROW |
Move to beginning or end of the current row | HOME or END |
Jump to first cell in a table | CTRL+HOME |
Jump to last cell in a table | CTRL+END |
Read the current cell | NUM PAD 5 |
Read the current row | SHIFT+UP ARROW |
Read from current cell to the end of the row | SHIFT+PAGE UP |
Read from beginning of the row to the current cell | SHIFT+HOME |
Read current column | SHIFT+NUM PAD 5 |
Read from the current cell to the bottom of the column | SHIFT+PAGE DOWN |
Read from the top of the column to the current cell | SHIFT+END |
Return to the prior table cell | WINDOWS Key+J |
Move to the next or previous table | CTRL+ENTER or CTRL+SHIFT+ENTER |
List the keystrokes you can use in this layer | QUESTION MARK |
Plain String Text Voids This Functionality
Due to the August 13, 2012 Chairs' decision on Issue 204, spec text from Allow ARIA Attributes to Reference Hidden Elements changes HTML5 to state,
...authors SHOULD NOT reference hidden content which would lose essential meaning when flattened.
Even though it can point to structured content such as headings,
lists, paragraphs, and tables and the new spec text from the Allow ARIA Attributes to Reference Hidden Elements proposal encourages user agents to expose the full semantics of hidden
elements to assistive technology, as implemented aria-describedby
/hidden
is limited in its ability to
process structured content. Accessibility APIs that aria-describedby
maps to do not support structured content due to key-binding focus requirements for sighted keyboard users who
cannot use a mouse. Sighted keyboard users need to know where their
focus is so they do not become disoriented. Focused items need to
be visible.
Consequently off-screen controls are not included in the tab order, exposed in the accessibility tree, listed in enumerations of controls (e.g. JAWS link list), or available to skip commands.
This means that most assistive technology treats aria-describedby
target content as though it does not
have any mark-up. It is treated as a string. Structure is
stripped. A user's reading keys will not work. Users are not
able to interact with the content. All links are dead.
As the WAI-ARIA 1.0 Authoring Practices explains using aria-describedby
to point to a hidden link would be futile because a user would not be able to to navigate to and activate the link:
When the author does not desire the entire descriptive text to be located on the main page,
aria-describedby
can also be used to point to a link to another page.<div id="figuretitle">Figure 1-1: Entity Relationship Diagram showing EMP and DEPT </div> <img src="foo" aria-labelledby="figuretitle" aria-describedby="link1"> <a href="descriptionLocation.html" id="link1"> Description of Figure 1-1: Entity Relationship Diagram showing EMP and DEPT</a> </div>
It is not good practice to use the above pattern when the describing elemen - the
<a>
tag with@id='link1'
- is hidden , since there is no way for a user to navigate to and activate the link. Use the technique only when the description is not hidden.
None of this is a problem with longdesc
. Longdesc
supports structured content. Reading keys and
links work.
Examples in the Wild Utilize Structured Markup
Sites in the wild utilize structural markup in long description pages. For instance Aboriginal Affairs and Northern Development Canada, ACCESS-ed: University of Wisconsin - Milwaukee, Accessibilité du Web, Affaires autochtones et Développement du Nord Canada, California Department of Fish and Game, Camera Obscura, Canada's Department of Justice, Canadian Grain Commission, Canadian Space Agency, Centers for Disease Control and Prevention (CDC), Cornell University, Commonwealth of Massachusetts, Connexions, Correctional Service Canada, Courts Administration Service (Canada), CSS Work, CSS Squirrel, Daegu Metropolitan Office of Education (South Korea), Department of Sustainability, Environment, Water, Parcs Canada, Parks Canada, Population and Communities (Australia), Department of Transportation (Taiwan), dizABLED, Elections Canada, Free Technology Academy, Giheung-Gu Yong-in City (South Korea), Graphical Object Server for Non-Visual Interaction (GONVI), Grinning Planet, Hamilton College, Hawaii Public Schools, Health and Safety Executive (UK), Health Resources and Services Administration, Hipocampo, IBM, Immigration and Refugee Board of Canada, IDCnet: Inclusive Design Curriculum Network, Indiana University-Purdue University Indianapolis Common Core Curriculum Committee, Iris Fernandez: BETA Weblog, educación y tecnología en Argentina, Kilkee, County Clare, Ireland, Korea Employment Information Service (South Korea), Kyungpook (South Korea), Local Government Commission, Lusophone countries - Convention on the Rights of Persons with Disabilities (Portuguese), Marine National Park (Taiwan), Mesothelioma Center, Michigan State University, Ministère des Relations internationales - Gouvernement du Quèbec, Monterey County, National Center for the Dissemination of Disability Research, National Institute of Information and Communications Technology (Japan), National Institute of Standards and Technology (NIST) , National Institutes of Health (Canada), National Institutes of Health (United States), National Transportation Safety Board, New Zealand Department of Labor, Northern Ireland Planning Service, Object Description, Office of the Commissioner of Review Tribunals, Ohio Dental Clinics, Ohio Dental Clinics, Ohlone College, Oriental Hospital of Daejeon University (South Korea), PARIS WEB, Province of Gyeongsangbuk (South Korea), Public Safety Canada, Rebuilding The Web,Régie des rentes du Québec, Resources naturelles Canada, Sésame Province de Luxembourg (Belgium), San Diego University, Social Security Online, Specific Claims Tribunal Canada, Special Education Support Center (South Korea), Statistics Canada, Statistique Canada, Texas Comptroller of Accounts, Susan Combs, Texas State Library, Trace Center, Transportation Safety Board of Canada Tribunal des revendications particulières Canada, Transportation Safety Board of Canada, Treasury Board of Canada Secretariat, Reports on Plans and Priorities, U.S. Department of Health and Human Services, Assistant Secretary for Planning and Evaluation, U.S. Department of Transportation Federal Highway Administration, U.S. General Services Administration, U.S. Patent and Trademark Office, U.S. State Department, UK Blind Piano Tuners, Universal Remote Console Consortium, University of Minnesota Duluth, W3C HTML5 Accessibility Bugs, W3C Rich Web Applications Backplane Incubator Group, Web Content Accessibility Guidelines (WCAG), Wrexham County Borough Council (UK), Yasui (Japan), and Zew all use structural markup.
Description Available in a Separate Document Provides Efficiency
Using one global document to provide descriptions for multiple instances of the same image is a powerful, portable, re-usable technique. It provides efficiency and scalability making authoring and maintenance easy wherever instances of the same image are used in multiple locations. It is analogous to the power of external style sheets.
The technique saves time and money by:
- Eliminating needless initial costs of having to create descriptions in multiple documents.
- Eliminating needless maintenance costs of having to update descriptions in multiple documents whenever a change is needed.
- Allowing for leaner code overall - you only do your http transport on demand, resulting in smaller, faster pages, and reduced bandwidth consumption.
Global long descriptions can be applied across multiple sites, or across an entire site, or across a subset of pages, and doing so means that you only need to update one file if you need to make a change.
HTML5 should not unduly obstruct authors in this regard.
As documented by the use cases and evidenced by real world
examples a description available in a separate document provides
easy reuse of the targeted description from multiple sources (i.e.
ability for an image to appear in multiple documents throughout a
site or throughout multiple sites or from an HTML email while at
the same time linking to one longdesc
document).
Other "solutions" such as figcaption
, details
, and aria-describedby
as
implemented lack this functionality. They are hamstrung to on-page
descriptions.
Examples in the Wild
The CSS
Squirrel, SEO
Design, the Lambda Theta Phi Latin Fraternity, the Texas State Library, and
the University of
Minnesota Duluth use images in separate documents that share the same
long description page. This technique is key to the logo description use
case and the lightbox description use
case as evidenced through examples in the wild. Geoff Freed has 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 externally store descriptions to facilitate etext
descriptions and describe etext
Images.
Of long description techniques, using a separate document is a prevalent design pattern/cowpath with authors who supply descriptions. Less than two-dozen on-page long descriptions via anchor were found out of over two thousand examples in the wild.
Code and User Interface Patterns
The code and UI patterns for how to navigate to an external page
with a longdesc
are well established (and used for
example by JAWS and Opera).
Equal Access to Dual Functionality
Blind users deserve to be afforded a programmatically determinable way to obtain equal access to a long description of content images as well as decorative images whenever an image already has a link which is mapped to another function.
Dual Functionality Provides 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 they deserve the opportunity for an equal experience.
Being 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 SpaceBar, or by mouse click), so that a linked image retains the expected behavior in response to user interaction while a discrete mechanism is used to retrieve the long description provides accommodation for blind users.
This functionality is taken for granted by sighted users as they automatically
see what an image looks like while being able to directly access a parent
<a>
element mapped to a different task.
One Link Cannot Take a User to Two Locations
Attempting to force dual functionality into single functionality is unworkable because it is impossible for one link to take a user to two locations.
- Expecting all
<img>
elements on the web that need long descriptions not to have a parent<a>
element mapped to a different task unrelated to a long description is unrealistic, i.e., a thumbnail <img> that links to a larger .jpg as evidenced by sites such as the National Institute of Dental and Craniofacial Research. - Expecting all pages on the web to shoehorn in a long description is unrealistic and most times nonsensical. For example, if an image already has a link that takes the user to another URI that has a different purpose (i.e., a logo image that links to the home page, a small image that links to a large image (lightbox use case), one cartoon in a series of cartoon images that links to the next comic strip page).
ARIA provides no mechanism for separating out what contributes to the accessible description and a navigational link.
Disallowing Equal Access is Unacceptable
Removing the possibility for direct, dual, programmatic access to both a long
description and a separate a href
on an <img>
element would be:
- Discriminating to bind users
- A barrier to providing accessible content and a needless authoring impediment
- A step backwards for HTML
Breaking Backwards Compatibility is an Intolerable Cost
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
in terms of tools,
content and documentation. All other "solutions" introduce a
non-backwards compatible change which negatively affects existing tools, existing content, existing documentation. The vision of HTML5 was to extend the Web without breaking it; evolution rather then revolution.
Existing Tools
Longdesc
is implemented in authoring tools,
assistive
technology, and user agents.
Not everyone can afford to throw away tools to get the newest model. For
instance run of the mill content authors/web designers rarely can afford to throw
away their WYSIWYG editor to get the newest model. They rely on existing tools to
author and test long descriptions. It has been well established that WYSIWYG tools simplify authoring
longdesc
. An array of tools exists to
author longdesc
and to check that the
longdesc
works. Authors rely on tools to test long descriptions. Two browsers (Opera, iCab) natively support longdesc
link 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 including Jim Thatcher's powerful long description favelet, which provides universal functionality of longdesc
in browsers such as Chrome, FireFox, Internet Explorer, and Safari.
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.
Existing Content
It has been substantially evidenced via the documentation of over two thousand real world examples of longdesc
that authors do
indeed use longdesc
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.
For an image 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.
For example, during the past year alone, numerous organizations such as the A11y Bugs Project, Aboriginal Affairs and Northern Development Canada, Alienor, Assisted Human Reproduction 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), Cornell University, 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), Immigration and Refugee Board of Canada, Marden Neighbourhood Plan, Marine National Park (Taiwan), Michigan State University, National Center on Birth Defects and Developmental Disabilities, National Institute of Standards and Technology (NIST), National Institute on Drug Abuse, Object Description, Office of the Commissioner of Review Tribunals, 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 , Procréation assistée 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, Transport Canada, Transportation Safety Board of Canada, 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.
Expecting authors to rewrite deployed 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. 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.
Existing Documentation
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 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, and therefore neither must longdesc
.
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.
Gregory J. Rosmaita a longdesc
consumer who fully supports this objection document wrote the following to me on August 1, 2012. It is reprinted here with his permission,
ever since i first started working with the W3C, i've been attempting to explain that while a picture may be worth a thousand words, that doesn't mean i want to hear all one-thousand words all at once or at this particular moment... i do, however, absolutely need to know that: 1) the author has inserted an image here, so it is probably relevant to the content (the purpose of "alt"); 2) that there is a long description of the image available should i need/want it; 3) that i can use familiar structural navigational features and commands to obtain the description's contents, with the ability to stop speech and review in detail (i.e. by character) or by structure (i.e. current list item, next list item, list item x out of y) the structured content used to provide the long description; and 4) the confidence that when i am satisfied with the amount of information obtained from the long description, i can and will return to the exact place in the main content from which i initiated exposition of the long description.
longdesc
fulfills all my requirements and needs, and i fully support its retention in HTML5.
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
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, Alienor, Assisted Human Reproduction 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), Cornell University, 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, Immigration and Refugee Board of Canada, Kyungpook (South Korea), Marine National Park (Taiwan), Michigan State University, National Center on Birth Defects and Developmental Disabilities, National Institute of Standards and Technology (NIST), National Institute on Drug Abuse, Object Description, Office of the Commissioner of Review Tribunals , 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 , Procréation assistée 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, Transport Canada, Transportation Safety Board of Canada, 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.
longdesc
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. 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.
Long Description Favelet
A longdesc favelet by James Thatcher first announces the number of images on a page that has longdesc attributes. Then it highlights each image on the page that has a longdesc
and provides on-screen text links to each corresponding description. It provides universal functionality of longdesc
in browsers such as Chrome, FireFox, Internet Explorer, and Safari. For the functional favelet drag longdesc to your bookmarks.
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".
On May 5, 2012, HTML Co-Chair, Maciej Stachowiak stated,
if a UA can give a better experience i think they should be encouraged to try
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. It will encouraged to them to improve support. 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.
Alternative Techniques Are Not Viable
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, aria-describedat
, aria-describedby
, canvas,
figcaption
, href
, details
, iframe
, imagemap
, or a new HTML attribute are
not viable solutions. The following matrix delineates how proposed solutions meet long description
requirements.
Requirement | longdesc |
aria- describedat |
aria- describedby |
canvas |
figcaption |
href |
details |
iframe |
imagemap |
New HTML Attr | rel |
---|---|---|---|---|---|---|---|---|---|---|---|
No forced a visual encumbrance | Pass | Fail [3] | Fail | Fail | Fail | Fail | Fail | Fail | Pass | Fail [3] | Fail |
Discoverability tools exist when there is no forced visual encumbrance. | Pass | Fail [3] | Fail | Fail | Fail | Fail | Fail | Fail | Fail | Fail [3] | Fail |
Programmatically ties a set of structured content that is external to the document to an <img> element. | Pass | Fail [3] | Fail | Fail | Fail | Fail [1] | Fail | Pass | Pass | Fail [3] | Pass |
Programmatically determinable when an image already has a link which is mapped to go to another page or a larger image. | Pass | Fail [3] | Pass | Fail | Pass | Fail | Pass | Pass | Fail | Fail [3] | Fail |
Provides easy reuse of the targeted description from multiple sources. | Pass | Fail [3] | Fail | Fail | Fail | Fail [1] | Fail | Pass | Pass | Fail [3] | Pass |
Provides the choice to consume. As currently implemented, the description is not forced upon screen reader users. | Pass | Fail [3] | Fail | Fail | Fail | Fail [1] | Fail | Unknown [4] | Unknown [4] | Fail [3] | Unknown [4] |
Does not require reengineering ARIA. | Pass | Fail | Fail | Pass | Pass | Pass | Pass | Pass | Pass | Pass | Pass |
Is not a bridging technology. | Pass | Fail | Fail | Pass | Pass | Pass | Pass | Pass | Pass | Pass | Pass |
Provides WYSIWYG tool support for authors of limited skill set. | Pass | Fail [3] | Fail | Unknown [4] | Unknown [4] | Pass | Unknown [4] | Pass | Pass | Fail | Fail |
Does not force people to read another large specification. | Pass | Fail [3] | Fail | Pass | Pass | Pass | Pass | Pass | Pass | Pass | Pass |
Provides ease of use. | Pass | Fail [3] | Fail | Fail | Fail | Fail [1] | Fail | Pass | Pass | Fail [3] | Unknown [4] |
Provides ease of authoring. | Pass | Fail [3] | Fail | Fail | Fail | Fail [2a] | Fail | Fail | Fail | Fail [3] | Unknown [4] |
Provides native HTML long description semantics. | Pass | Fail | Fail | Fail | Fail | Fail [2] | Fail | Fail | Fail | Fail [3] | Pass |
Provides backwards compatibility and no need to retrofit. | Pass | Fail | Fail | Fail | Fail | Fail | Fail | Fail | Fail | Fail | Fail |
Is recognized by existing authoring tools, user agents, assistive technologies. | Pass | Fail | Fail | Fail | Fail | Fail | Fail | Pass | Unknown [4] | Fail | Fail |
Numerous tutorials and documentation throughout the world explain how to use this technique for complex image descriptions. | Pass | Fail | Fail | Fail | Fail | Fail | Fail | Fail | Fail | Fail | Fail |
Is law in various countries. | Pass | Fail | Fail | Fail | Fail | Fail | Fail | Fail | Fail | Fail | Fail |
Is a standard in numerous organizations and companies. | Pass | Fail | Fail | Fail | Fail | Fail | Fail | Fail | Fail | Fail | Fail |
Is policy in many organizations and companies in throughout the world. | Pass | Fail | Fail | Fail | Fail | Fail | Fail | Fail | Fail | Fail | Fail |
Is in numerous guidelines throughout the world. | Pass | Fail | Fail | Fail | Fail | Fail | Fail | Fail | Fail | Fail | Fail |
Does not reinvent the wheel. | Pass | Fail | Fail | Fail | Fail | Fail | Fail | Fail | Fail | Fail | Fail |
Provides solutions to all specific use cases. | Pass | Fail [3] | Fail | Fail | Fail | Fail | Fail | Fail | Fail | Fail [3] | Fail |
The only solution that meets all requirements and fulfills all specific use cases is longdesc
.
The following information provides further rationale as to why the
existence of these techniques does not justify killing off longdesc
.
aria-describedat
aria-describedat
Status
On March 21, 2012 an unofficial aria-describedat
document surfaced. It is a public working draft of a potential
specification. aria-describedat
has no official standing of any kind
and does not represent the support or consensus of any standards organization.
It is unknown if or when specification aria-describedat
would be
complete. Possible introduction of aria-describedat
in a future ARIA
version, does not require the abolition of longdesc. Rather, it acknowledges that
the idea behind longdesc is good.
aria-describedat
Use Cases
No use cases for aria-describedat
have been presented that are not
already satisfied or could be satisfied by longdesc.
aria-describedat
is a Bridging
Technology
If aria-describedat
ever does becomes an ARIA attribute it would
remain a bridging technology.
Shirking off the responsibility of providing long description semantics to ARIA is retrograde. In other words, the premise is entirely backward. ARIA should be used to augment missing native semantics of HTML as necessary, not as an excuse to kill and to replace them. For full rationale please consult the bridging technology section of this document.
aria-describedat
Forces a Visual
Encumbrance
By default aria-describedat
as described in the
unofficial/unsupported draft violates the forced
visual encumbrance constraint.
Different Authors Have Different Skill Sets
Pitting aria-describedat
and longdesc
against each
other is counter-productive to accessibility. It should not be an either/or
situation. 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.
It is recommend [Freedom Scientific 2012 (doc file)] that Web page authors,
read the ARIA best practices guide carefully before adding ARIA markup to their pages.
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 as role="application"
removes the
screen reader's navigation methods.
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 and binary thinking. It would be discriminatory if only ARIA skilled developers are able to publish an accessible image on the Web.
aria-describedat
Lacks Educational
Material
No evidence exists that substantial ARIA documentation or tutorials are in place and ready to educate developers. In fact, on June 18, 2011 Paul Irish said,
Most developers have no idea how to implement ARIA. The W3C Primer that looks like a spec is just.. laughable.. not at all appropriate for a web developer audience.
This situation has not changed.
In contrast a longdesc
support base already exists in the form of
authoring tools, tutorials, books etc. These
longdesc
support materials will live on.
aria-describedat
Lacks Backwards
Compatibility
The aria-describedat
would be void of all backwards compatibility. It is not:
- Recognized or implemented by existing authoring tools, browsers, or assistive technologies.
- In numerous books, online tutorials, guidelines, laws, policies and standards throughout the world.
For further rationale please consult the backwards compatibility section of this document.
aria-describedat
has No Examples in the
Wild
No examples in the wild of accessible long text alternatives with
aria-describedat
have been presented.
aria-describedat
Lacks
Implementations
aria-describedat
has no implementations.
aria-describedat
Reinvents the Wheel
Attempting to use aria-describedat for
long descriptions would
reinvent the wheel by duplicating a basic method that has already previously been
created.
aria-describedat
No Evidence of
Improvement
No evidence has been presented that aria-describedat would
produce
more accessible content for long descriptions than longdesc
.
aria-describedby
aria-describedby
is a Bridging
Technology
Shirking off the responsibility of providing long description semantics to ARIA is retrograde. In other words, the premise is entirely backward. ARIA should be used to augment missing native semantics of HTML as necessary, not as an excuse to kill and to replace them. For full rationale please consult the bridging technology section of this document.
aria-describedby
Adds Needless
Complexity
No evidence has been presented that authors will get
aria-describedby
correct more often than longdesc
.In fact it is far more verbose and complicated for ordinary authors and designers to author hidden
relationships than provide a simple link via a longdesc
attribute.
This workaround would be very cumbersome and error
prone. No one would want redundant text on-screen, as it would state what is
visually evident. So to use aria-describedby
, a person would have to
write the content, then hide it, and then reference the hidden text with
aria-describedby
using hidden relationships. That's so burdensome that
surely even the most enthusiastic ARIA supporter should realize that the
longdesc
attribute is far more efficient.
Vlad Alexander thoroughly explains in the article Is ARIA for content
doomed to failure? how the aria-describedby
technique is far too
complex. The capacity for author error is great. Likely errors include but are not
limited to:
- Getting
ID
naming rules wrong. - Logical errors, such as circular references.
- Accidentally deleting the description leaving
aria-describedby
referencing a non-existentID
. - Accidentally overwriting the description with unrelated content leaving aria-describedby pointing to content that is not a description of the given element.
The potential for confusion is rife especially for ordinary content authors and
designers and the result is that accessibility will suffer. In fact even ARIA
experts have gotten ID
naming wrong and publish incorrect
ID
examples in the W3C WAI-ARIA 1.0 Authoring Practices
specification.
No aria-describedby
/hidden
tools exist to help authors
in this task, whereas authors possess an array of tools to
author longdesc
and to check that
longdesc
works in browsers.
The aria-describedby
/hidden
technique is complex. In
contrast longdesc
is simple. As
Kyle Weems illuminated,
are we going to pretend that using
longdesc
is difficult? Yes, people may use it wrong without some correction, but simply saying "Hey, put a URL there," is not complex at all
The Association of American Publishers (AAP) concurs. In regard to their production processes and quality assurance the AAP has provided first-hand testimony to the working group stating,
The
longdesc
attribute is easy to code.
As a rule, the more complex the markup pattern, the more likely authors are to make mistakes when implementing it. We should strive to find the simplest markup pattern that satisfies requirements.
aria-describedby
Lacks Ability to Provide Description
in a Separate Document
aria-describedby
Use Cases
As documented by the use cases and evidenced by real world examples a
description available in a separate document provides easy reuse of the targeted
description from multiple sources (i.e. ability for an image to appear in multiple
documents throughout a site or throughout multiple sites or from an HTML email
while at the same time linking to one longdesc
document).
The CSS
Squirrel, SEO
Design, the Lambda Theta Phi Latin Fraternity, the Texas State
Library, and the University of Minnesota
Duluth use images in separate documents that share the same long
description page. This technique is key to the logo description use
case as evidenced on numerous sites.
Geoff Freed has indicated that professional content producers (such as those
involved in the ePub initiative, and the US federally-funded project) are
interested and ready to use longdesc
to externally store descriptions
to facilitate
etext descriptions and describe etext
Images.
aria-describedby
as implemented lacks this direct functionality. It
is limited to on-page descriptions. ARIA provides no mechanism for separating out what contributes to the accessible description and a navigational link.
Global control for all instances is a powerful technique. It makes maintenance easy wherever instances of the same image exist in numerous locations. This is akin to the power of external style sheets.
In addition if long descriptions were hamstrung to on-page only, it would add
page weight inhibiting performance and slow pages. Longdesc
allows for
leaner code overall - you only do your http transport on demand, resulting in
smaller, faster pages, and reduced bandwidth consumption.
Different Authors Have Different Skill Sets
Pitting aria-describedby
and longdesc
against each
other is counter-productive to accessibility. It should not be an either/or
situation. Longdesc is needed and aria-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.
It is recommend [Freedom Scientific 2012 (doc file)] that Web page authors,
read the ARIA best practices guide carefully before adding ARIA markup to their pages.
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 as role="application"
removes the
screen reader's navigation methods.
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 and binary thinking. It would be discriminatory if only ARIA skilled developers are able to publish an accessible image on the Web.
aria-describedby
Lacks ARIA Educational
Material
No evidence exists that substantial ARIA documentation or tutorials are in place and ready to educate developers. In fact, on June 18, 2011 Paul Irish said,
Most developers have no idea how to implement ARIA. The W3C Primer that looks like a spec is just.. laughable.. not at all appropriate for a web developer audience.
This situation has not changed.
In contrast a longdesc
support base already exists in the form of
authoring tools, tutorials, books etc. These
longdesc
support materials will live on.
Two-Step Retrieval Instead of One-Step Retrieval with
aria-describedby
The effort for users to retrieve a description is significantly and negatively impacted. The Association of American Publishers has provided the working group first-hand testimony on this matter stating,
Since the
aria-describedby
attribute points to a link or to other content on the same page, its structure implies a two-step process to reach the text alternative. Compared withlongdesc
, the two step process is more tedious:
- The user moves to the object that aria-describedby references
- If the object is or contains a link or a button, the user interacts with that object to move to the text alternative.
This means
that screen reader users would need to exert double the effort to retrieve an
aria-describedby
description than they do with longdesc
.
People with disabilities face some unique challenges and barriers. Doubling their
on-task work load is needless and intolerable.
aria-describedby
Lacks Support for
Structured Text
As previously explained even though it can point to structured content such as bulleted
lists and paragraphs as implemented aria-describedby
/hidden
can only process
structured content as string-text. Please refer to Plain String Text Voids This Functionality for further information.
aria-describedby
Is Forced Upon
Users
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. 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 with longdesc
as it supplies
descriptions on-demand and not by force. Non-sighted users (using a screen reader that supports longdesc
) is presented with a) advice/notification that a longer description is available, and b) the opportunity/choice to either pursue that longer description, or skip past it and continue with the normal page content. This choice is a critical user-requirement. 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.
aria-describedby
Forces a Visual
Encumbrance
aria-describedby
technique would force a visual encumbrance on sighted users unless
additional code (in the form of CSS or hidden
) were added in order to
hide the visual indicator. This would exacerbate aria-describedby
's inherent complexity. Please refer to the Cascading Style
Sheets and hidden
sections of this document
for details of why using these techniques is a bad idea.
aria-describedby
Lacks Vendor Support
Authoring Tools
No evidence exists that authoring tools will implement
aria-describedby
.
Indeed, authoring tool vendor Vlad Alexander has provided first-hand testimony stating,
Authoring tool vendors are likely to find it difficult (or even impossible) to build user-friendly interfaces that use the
aria-describedby
feature. This is likely to result in confusion and little use of the feature.
He confirmed on July 5, 2011 that,
As an authoring tool vendor, we will not be supporting ARIA for content in XStandard, and I cannot see that many other tool vendors will support it either. Implementing ARIA for content does not make business sense for authoring tool vendors, because the non-technical content authors who buy our tools will find it far too complex to use, and because using ARIA for content does not produce better results than existing accessibility features.
However, Vlad
Alexander has envisioned a user friendly longdesc
authoring tool.
He stated,
As a WYSIWYG developer, I can imagine a user-friendly interface that can encourage not only the use but also correct use of
longdesc
. I cannot say the same foraria-describedby
for images.
As evidenced he has not only envisioned an improved
longdesc
interface, but he also implemented
one.
User Agents
No evidence exists that user agents will implement aria-describedby
uniformly and in the manner intended by its designers. For example as tested
and reported by Steve Faulkner the
latest versions of NVDA and JAWS used with IE 9 will not announce descriptions unless
tabindex=-1
is added to elements such as p, div and span when referenced fromaria-describedby
oraria-labelledby
that reference multiple elements
Firefox 14 attempts to use aria-describedby for long descriptions. As David MacDonald has tested and explained in Firefox 14: long description via link associated using aria-describedby, the aria-describedby
attribute is
a poor imitation of
Longdesc
, not well supported, does very similar thing but not as well, it requires an extra step, and it is a little difficult for the user to return to the original image. They wouldn't know it's opening to a new tab...
That a user agent might attempt to expose a mechanism for navigating to a description doesn't mean authors can safely refer to content that cannot be easily consumed when its structure and semantics are stripped away to plain text.
For all intents and purposes aria-describedby
is only suitable for short descriptions. ARIA provides no mechanism for separating out what contributes to the accessible description and a navigational link.
That some UAs might additionally expose a mechanism for navigating to the accessible description doesn't mean you can safely refer to content that cannot be easily consumed when its structure and semantics are stripped away to plain text.
Basically aria-describedby is only suitable for short descriptions. ARIA provides no mechanism for separating out what contributes to the accessible description and a navigational link.
Browser Discoverability for Non-AT Users
No evidence has been presented that any browser makes hidden
content referred to by aria-describedby
discoverable to those who do not use accessible technology. As Matt Garrish stated [Accessible EPUB 3, February 2012] only persons using accessible technologies will easily find it,
Images present a challenge for a variety of disabilities, and the means of handling them are not new, but HTML5 has added a new barrier in taking away the longdesc attribute for out-of-band descriptions... The problem is that HTML5 doesn't replace these removals with any mechanism(s) to allow the discovery of the same information, instead deferring to the aria-describedby attribute to point to the information (see the scripting section for more on WAIARIA). This attribute however, may make the information even less generally discoverable to the broader accessibility community, as only persons using accessible technologies will easily find it.
Safari is a typical example of a browser that does not make aria-describedby/hidden
discoverable to non-AT users. On August 15, 2012 Apple representative Maciej Stachowiak confirmed,
In Safari, aria-describedby (and aria properties in general) are only exposed via output-side assistive technologies.
The fact is that new spec text from the Allow ARIA Attributes to Reference Hidden Elements change proposal changes HTML5 to disallow user agents from rendering hidden content. It states:
User agents should not render elements that have the
hidden
attribute specified.
In contrast, longdesc
has an existing support base (two browsers that natively support it,
three if we count Home Page Reader which is currently still in use
in Japan). It has a growing arsenal of extensions, configurations, and plugins that enable
discoverability and provides the required functionality.
No ARIA features to date have been implemented in a way that can be used by non AT users, this appears to be by design as those who influence implementations believe that ARIA should only affect the 'accessibility layer' not mainstream aspects of content display and behaviour. Ian Hickson has stated,
ARIA is intended to only affect accessibility API mappings (and thus ATs). Features such as alt="", however, are relevant far beyond AT users, for example to text browsers. It would be wrong, therefore, to make solutions that exclusively affect accessibility APIs be a suitable alternative for solutions that are necessary for UAs that do not use accessibility APIs.
Furthermore by specifying UA behavior
for longdesc
as accomplished by the Include
longdesc
in HTML5 Change Proposal we uphold the Priority
of Constituencies and give all users the benefit of this useful attribute.
aria-describedby
Reinvents the Wheel
This proposed replacement for longdesc
attempts to duplicate a
basic method that has already previously been created.
This proposed replacement is new and more complicated syntax for the same thing, or for a limited subset as it restricts the description to be on the same page.
aria-describedby
Lacks Backwards
Compatibility
aria-describedby
is new. It has no legacy or provenance. Whereas,
longdesc
has legacy content and legacy support.
Expecting authors to rewrite their content in order to support a technique that (a) does not work for authors or users, (b) reinvents the wheel, (c) lacks vendor support, (d) attempts to obsolete vital core host language semantics with a bridging technology, and (e) is simply a cumbersome "hack", is nonsensical and totally unrealistic : such attempts will serve only to infuriate and alienate both those authors and the accessibility community as a whole.
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 of longdesc.
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 that longdesc
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 copious array of books, tutorials, guidelines, laws,
policies and standards 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, and therefore neither must
longdesc
aria-describedby
Retrofitting Problem
Any proposed solution should be easy for authors who are already
publishing content with longdesc
to retrofit their
existing pages. aria-describedby
possesses a radically
different, inherently complex, two-step
authoring pattern than longdesc
. Because of this, as
well as its on-page limitations, retrofitting with aria-describedby
would be difficult, labor intensive,
and error prone. No retrofitting is required for longdesc
as it is an existing HTML feature not a new one.
aria-describedby
No Examples in the Wild
No examples in the wild of accessible long text alternatives with
aria-describedby
have been presented for any of the use cases. No
evidence exists that authors have or will use it for accessible long text
alternatives.
No Evidence of Improvement with
aria-describedby
No evidence has been presented that aria-describedby
produces more accessible content for
long descriptions than longdesc
or that more authors
would use it correctly. It is an inferior long description solution possessing no benefits over longdesc
.
The longdesc
attribute possesses the ability to provide both on-page and off-page descriptions while retaining all rich content in the long description. It does not force itself upon users. The longdesc
attribute unequivocally and directly provides native semantics
and critical backwards compatibility.
canvas
canvas
is an Illogical Long Description
Technique
Authors are not going to think about canvas
when they want to use a
complex image. If they want to use an image they will simply use
img
.
It is illogical to require img
to be encased in canvas
in order to provide a long description.
canvas
Long Description Semantics
Semantic elements and attributes improve communication. For details please consult the semantics section of this document.
The semantics of
canvas
element does not provide a clear, direct, explicit, and strong
semantic for an image long description.
canvas
Adds Needless Complexity
Requiring canvas
to supply long descriptions would introduce
needless complexity.
This in turn would make it more prone to authoring error as complexity confuses and leads to errors. longdesc
is a
simple link - no coordinates to figure out.
Overloads canvas
canvas
overloads fallback content.
No canvas
Examples in the Wild
No examples in the wild of accessible long text alternatives with
canvas
have been presented for any of the use cases. No evidence
exists that authors have or will use this technique.
canvas
Lacks Educational Material
No tutorials, books, or documentation exists that explain to authors how to make
an accessible long text alternative with canvas
.
No Evidence of Improvement with
canvas
No evidence has been presented that canvas
produces more accessible
content for long descriptions than longdesc
or that more authors would
use it correctly.
canvas
Lacks Backwards
Compatibility
Any canvas
technique for long descriptions lacks backwards compatibility. It 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
canvas
is used. - In numerous books, online tutorials, guidelines, laws, policies and standards throughout the world.
For further rationale please consult the backwards compatibility section of this document.
canvas
Retrofitting Problem
Any proposed solution should be easy for authors who are already
publishing content with longdesc
to retrofit their
existing pages. canvas
possesses a radically
different, authoring pattern than longdesc
. Because of
this, retrofitting with canvas
would be difficult. No retrofitting is required for longdesc
as it is an existing HTML feature.
Cascading Style Sheets
Cascading Style Sheets (CSS) have been suggested as a solution for hiding long description indicators or long description content. This suggestion:
Violates Search Engine Guidelines
Search engines do not seem to leave any room for text that is hidden (or off screen) for good reasons like long descriptions.
Google's guideline on hidden text states:
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..
The penalty for a site using hidden text may be removed from the Google index, and will not appear in search results pages.
Yahoo!'s search engine has a similar content quality guideline:
...examples of the types of content that Yahoo! does not want included...The use of text or links that are hidden from the user...
Long descriptions that utilize the longdesc
attribute have no such search engine penalties imposed. longdesc
is a simple link.
CSS Adds Needless Complexity, Page Weight, and Inconsistency
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.
Different CSS techniques for hiding have very different results.
Elements styled with "display:none"
or "visibility:hidden"
are not included in the
accessibility tree. They are always hidden from screen readers and browsers. [McCathieNevile 2012 test case]
However, other declarations for hiding such as "left:
-9999px; top: -9999px;"
is rendered to screen reader users
just as any other currently visually visible element on the screen
is but it is stripped of all interactivity and semantic
structure.
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...
Even authors versed in CSS have problems hiding long description
indicators with CSS in a manner that is accessible. 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. As Marco Zehe recently stated,
Elements styled with
"display:none"
or"visibility:hidden"
are always hidden from screen readers as well. This is true for screen readers on Windows like NVDA or JAWS, and has been so for at least the last ~7 years. Orca on Linux, VoiceOver on OS X and iOS also adhere to this rule. JAWS has consistently supported this since version 7, which was released in 2005. All other screen readers I know do this right, too, and have been for ages. Why this rumor that one can provide extra content to screen readers via elements styled with"display:none"
keeps sticking around, I have no clue. It is definitely wrong! Screen readers completely ignore elements styled with"display:none"
or"visibility:hidden;"
.
Daegu
Metropolitan Office of Education is an example of an
organization mistakenly using this technique. Fortunately they also
used longdesc
, which does work.
The Paciello Group recently illuminated various techniques to hide content. They detail the correct technique to hide interactive (focusable) content from visible display with CSS, but still have it in the tab order. As stated,
Focusable content should only be hidden from visible display if the focusable element becomes visible when it receives focus:
Example code:
a.offscreen {position:absolute; left:-10000px; top:auto; width:1px; height:1px; overflow:hidden;} a.offscreen:focus {position:relative; left:0px; width:auto; height:auto; overflow:auto; }
This technique is required to correctly hide long descriptions
that contain interactivity and semantic structure. The two sister
sites Statistics
Canada and Statistique
Canada are examples of an organization that incorrectly use
positioning off screen position: absolute; top: -100px
without a focus technique for interactive semantic content.
Fortunately they also used longdesc
, which preserves all interactivity and semantic structure.
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 authors hide long
description indicators/link text with 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.
Structure is Stripped From Hidden Content Referenced by ARIA
As explained, structured markup facilitates critical functionality.
Due to the August 13, 2012 Chairs' decision on Issue 204, spec text from Allow ARIA Attributes to Reference Hidden Elements changes HTML5 to state,
...authors SHOULD NOT reference hidden content which would lose essential meaning when flattened.
Even though it can point to structured content such as headings,
lists, paragraphs, and tables and the new spec text from the Allow ARIA Attributes to Reference Hidden Elements proposal encourages user agents to expose the full semantics of hidden
elements to assistive technology, as implemented aria-describedby
/hidden
is limited in its ability to
process structured content. Accessibility APIs that aria-describedby
maps to do not support structured content due to key-binding focus requirements for sighted keyboard users who
cannot use a mouse. Sighted keyboard users need to know where their
focus is so they do not become disoriented. Focused items need to
be visible.
Consequently off-screen controls are not included in the tab order, exposed in the accessibility tree, listed in enumerations of controls (e.g. JAWS link list), or available to skip commands.
This means that most assistive technology treats aria-describedby
target content as though it does not
have any mark-up. It is treated as a string. Structure is stripped.
A user's reading keys will not work. Users are not able to interact
with the content.
As the WAI-ARIA 1.0 Authoring Practices explains using aria-describedby
to point to a hidden link would be futile because a user would not be able to to navigate to and activate the link:
When the author does not desire the entire descriptive text to be located on the main page,
aria-describedby
can also be used to point to a link to another page.<div id="figuretitle">Figure 1-1: Entity Relationship Diagram showing EMP and DEPT </div> <img src="foo" aria-labelledby="figuretitle" aria-describedby="link1"> <a href="descriptionLocation.html" id="link1"> Description of Figure 1-1: Entity Relationship Diagram showing EMP and DEPT</a> </div>
It is not good practice to use the above pattern when the describing elemen - the
<a>
tag with@id='link1'
- is hidden , since there is no way for a user to navigate to and activate the link. Use the technique only when the description is not hidden.
None of this is a problem with longdesc
. Longdesc
supports structured content. Reading keys and
links work.
No Evidence of Improvement with CSS
No evidence has been presented that using Cascading Style Sheets (CSS) to hide long description indicators or long description content produces more accessible content for long descriptions or that more authors would use it correctly.
figcaption
Incorrect figcaption
Semantics
Semantic elements and attributes
provide a higher level of communication. While a figcaption
can be used as a valid replacement for alt
to supply a context dependant caption of an image constrained to being inside of
a figure, it does not provide an explicit, and strong semantic for
an image long description. Terse and verbose descriptors differ. As Gregory J. Rosmaita aptly explained,
alt text is the brief "at a glance" or "cognative thumbnail"... alt text needs to be terse for a number of reasons, including usability, extremely limited viewports, small amount of video "real estate" (iPad and smaller devices) etc.
The prevailing rationale for keeping figure
/figcaption
change proposal
stated, that figcaption
was not a long description but rather a short
description:
The
figcaption
element exposes a short description of thefigcaption
content, which may be read out to help a user determine if they wish to look at the content offigcaption
now or later.
figcaption
Lacks Support
With the one exception of Firefox on Windows figcaption
is not accessibility supported semantics
wise. HTML5 accessibility
states that it,
provides the same amount of semantic information to AT as a
div
element.
figcaption
Forces a Visual
Encumbrance
The figcaption
technique would force
a visual encumbrance on sighted users unless additional code (in the form of
CSS or hidden
) were added in order to hide the visual indicator.
Please refer to the Cascading Style Sheets and hidden
sections of this document for details of why using
these techniques is a bad idea.
figcaption
Lacks Ability to Provide
Description in a Separate Document
The figcaption
technique lacks the key functional requirement of
providing a long description in a separate document.
figcaption
Reinvents the Wheel
Attempting to use figcaption
to provide a long description
reinvents the wheel by duplicating a basic method that has already previously been
created.
No use cases of figcaption
for a long description
has been presented that are not already satisfied by longdesc
.
figcaption
Lacks Educational Material
No tutorials, books, or documentation exists that explain to authors how to make
an accessible long text alternative with figcaption
.
No Examples in the Wild for figcaption
No examples in the wild of accessible long text alternatives with
figcaption
have been presented for any of the use cases. No evidence
exists that authors have or will use it for accessible long text alternatives.
figcaption
Lacks Backwards
Compatibility
The figcaption
technique lacks all backwards compatibility. It 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
figcaption
is used. - In numerous books, online tutorials, guidelines, laws, policies and standards throughout the world.
For further rationale please consult the backwards compatibility section of this document.
figcaption
Retrofitting Problem
Any proposed solution should be easy for authors who are already
publishing content with longdesc
to retrofit their
existing pages. figcaption
possesses a radically
different authoring pattern than longdesc
. Because of
this as well as its on-page limitations, retrofitting with figcaption
would be difficult, labor intensive, and
error prone. No retrofitting is required for longdesc
as it is an existing HTML feature.
No Evidence of Improvement with
figcaption
No evidence has been presented that figcaption
produces more
accessible content for long descriptions than longdesc
or that more
authors would use it correctly.
hidden
The hidden
attribute has been suggested as a solution to hide descriptions.
Users Who Do Not Use Assistive Technology
Some people may want or need to consume long description content that doesn't force a visual encumbrance but do not use assistive technology (AT). The following sighted people may be aided by access to a longdesc:
- Users who have a cognitive or visual impairment.
- Users with either a keyboard or pointing device without screen reader or assistive technology.
- Users with a custom input accommodation, such as a mouth-stick or sticky keys.
- Users who have small screens (e.g. mobile phone or screen magnifiers).
- Users who turn off images to decrease bandwidth use in order to lower their Internet usage fees.
- Authors, for ease of authoring, testing, and maintenance purposes.
No Discoverability Specified for
hidden
The hidden
technique is void of any discoverability
specification and shuts out all people who do not use AT but who do
want or need access to the description.
As Microsoft stated May 24, 2012,
exposing the content of a hidden referenced element *only* in the accessibility tree, without any UI, is a bad user experience.
In contrast the Include longdesc
in HTML5 change proposal provides a
solution to the forced visual encumbrance constraint while specifying
mainstream discoverability functionality for all who want
access to the description.
No Discoverability Tools for hidden
No discoverability tools exist for hidden
. No browser vendor has said that this situation will change. In fact with regard to discoverability Apple representative and HTML Co-Chair Maciej
Stachowiak explained Apple's aria-describedby
/hidden
implementation,
I don't think a mouth-stick user who is not visually impaired would ever be exposed to the link, because they would not have access to the description. At least in Safari, aria-describedby is only ever exposed via output-side assistive technologies. If we implemented the "encouraged" behavior, I would not expect that to change.
He further clarified Apple's position,
To be clear, here is what I would expect us to do, if we were to implement the "encouraged" rich semantics functionality in WebKit.
(1) Sighted user, using either keyboard or pointing device to manipulate the content, and with no screen reader or assistive technology running:
- The aria-describedby description would not be exposed to such a user at all. They would neither see it nor be able to tab into it.(2) Same as #1, but using a custom input accommodation, such as a mouth-stick or sticky keys.
- Same experience as #1 - the description is not exposed at all.
Maciej then tested the following markup and reported,
<img alt="the reddit logo" aria-describedby="hidden-link" src="http://d.thumbs.redditmedia.com/-6cwonBxQa40zpxo.png"> <span hidden id="hidden-link">The <a href="http://reddit.com/">reddit </a> logo, showing the reddit alien mascot. </span>
(1) For a sighted user using the keyboard (or other alternative input):
- The image shows up, and none of the associated text is read out loud, and the link is not in the tab cycle.
aria-describedby
/hidden
fails the discoverability constraint.
In contrast discoverability tools exist for longdesc. Sighted authors, people with cognitive or visual impairment, and others use these tools. 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.
Structure is Stripped From Hidden Content
As explained, structured markup facilitates critical functionality.
Due to the August 13, 2012 Chairs' decision on Issue 204, spec text from Allow ARIA Attributes to Reference Hidden Elements changes HTML5 to state,
...authors SHOULD NOT reference hidden content which would lose essential meaning when flattened.
Even though it can point to structured content such as headings,
lists, paragraphs, and tables and the new spec text from the Allow ARIA Attributes to Reference Hidden Elements proposal
encourages user agents to expose the full semantics of hidden
elements to assistive technology, as
implemented aria-describedby
/hidden
is limited in its ability to
process structured content. Accessibility APIs that aria-describedby
maps to do not support structured content due to key-binding focus requirements for sighted keyboard users who
cannot use a mouse. Sighted keyboard users need to know where their
focus is so they do not become disoriented. Focused items need to
be visible.
Consequently off-screen controls are not included in the tab order, exposed in the accessibility tree, listed in enumerations of controls (e.g. JAWS link list), or available to skip commands.
This means that most assistive technology treats aria-describedby
target content as though it does not
have any mark-up. It is treated as a string. Structure is stripped.
A user's reading keys will not work. Users are not able to interact
with the content.
As the WAI-ARIA 1.0 Authoring Practices explains using aria-describedby
to point to a hidden link would be
futile because a user would not be able to to navigate to and
activate the link:
When the author does not desire the entire descriptive text to be located on the main page,
aria-describedby
can also be used to point to a link to another page.<div id="figuretitle">Figure 1-1: Entity Relationship Diagram showing EMP and DEPT </div> <img src="foo" aria-labelledby="figuretitle" aria-describedby="link1"> <a href="descriptionLocation.html" id="link1"> Description of Figure 1-1: Entity Relationship Diagram showing EMP and DEPT</a> </div>
It is not good practice to use the above pattern when the describing element - the
<a>
tag with@id='link1'
- is hidden , since there is no way for a user to navigate to and activate the link. Use the technique only when the description is not hidden.
None of this is a problem with longdesc
. Longdesc
supports structured content. Reading keys and
links work.
No Accessible Object Representing the Text Description is Exposed in the Accessibility API
As Richard Schwerdtfeger has said,
text is loaded into the accessible description string in an accessible object even though no accessible object representing the text description is exposed in the accessibility API.
hidden
is Hidden From its Target Audience
Most common screen readers in use today will ignore elements that have been
hidden using the display:none
; declaration. When material is
hidden from visual display on a screen in this manner, it is hidden it from screen
readers. As
Roger Johansson explained,
Setting an element's display CSS property to
none
makes it completely invisible. It doesn't generate a box, it doesn't take up any place, it doesn't affect the layout. display:none hides the element - and its descendants - visually, and it also hides the element from screen readers.
In both Gecko-based (Firefox, Seamonkey, ...) and Webkit-based
(Safari, ...) browsers the hidden
attribute is implemented by applying CSS display:none
. The The Paciello Group recently illuminated HTML5 hidden
effects,
HTML5 hidden effects:
- In supporting browsers the content is not displayed to any user.
- semantic indicator of state in HTML code (hidden attribute)
- CSS style of display:none applied by browser.
- Focusable content is not included in tab order.
- Not included in the accessibility tree.
This means that the long description
using the proposed hidden
technique would be hidden
from its target audience.
hidden
Violates Search Engine Guidelines
Search engines do not seem to leave any room for text that is hidden (or off screen) for good reasons like long descriptions.
Google's guideline on hidden text states:
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..
The penalty for a site using hidden text may be removed from the Google index, and will not appear in search results pages.
Yahoo!'s search engine has a similar content quality guideline:
...examples of the types of content that Yahoo! does not want included...The use of text or links that are hidden from the user...
Long descriptions that utilize the longdesc
attribute have no such search engine penalties imposed. longdesc
is a simple link.
No Authoring Tools exist for hidden
No authoring tools for hidden
exist to allow authors to create and
test long descriptions.
Without WYSIWYG authoring tools run of the mill content authors/web designers authors would be disenfranchised. They rely on tools to author and test long descriptions.
It has been well established that numerous WYSIWYG web designer authoring
tools support longdesc
. An array of tools exist to
author longdesc
and to check that the
longdesc
works.
Authors also rely on tools to test long descriptions. 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.
hidden
is a Confusing and Complex
Technique
Due to the August 13, 2012 Chairs' decision on Issue 204, spec text from Allow ARIA Attributes to Reference Hidden Elements will be applied to HTML5. This causes confusion as the specification states:
The
hidden
attribute must not be used to hide content that could legitimately be shown in another presentation...
It goes on to say:
if something is marked hidden, it is hidden from all presentations, including, for instance, screen readers...
Now Issue 204 introduces a paradox as hidden doesn't mean hidden anymore. A new addition to the spec states:
It would be fine, however, to use the ARIA
aria-describedby
attribute to refer to descriptions that are themselveshidden
. While hiding the descriptions implies that they are not useful alone, they could be written in such a way that they are useful in the specific context of being referenced from the images that they describe.
Although the new aria-describedby
paragraph could
provide some highly skilled ARIA developers a limited technique, it is ambiguous.
The spec text explicitly says that hidden
must not be used to hide
content. Then it turns around and asserts it is okay to use it with
aria-describedby
to point to hidden content.
Possessing more than one possible meaning inherently causes uncertainty. It is
error prone, and would be difficult to comprehend and put into practice especially
for novice or run of the mill content authors. Author error will increase exponentially especially when combined with identified aria-describedby
problems.
In contrast longdesc
is simple and does not require a
hidden
hack.
No hidden
Examples in the Wild
No examples in the wild of accessible long text alternatives with
hidden
have been presented for any of the use cases.
hidden
Lacks Backwards
Compatibility
The hidden
technique is new. It lacks all backwards
compatibility. It 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
hidden
is used. - In numerous books, online tutorials, guidelines, laws, policies and standards throughout the world.
hidden
Retrofitting Problem
Any proposed solution should be easy for authors who are already
publishing content with longdesc
to retrofit their
existing pages. Because of hidden
's inherent complexity retrofitting would be difficult,
labor intensive, and error prone. No retrofitting is required for longdesc
as it is an existing HTML feature.
No Evidence of Improvement with
hidden
No evidence has been presented that hidden
produces accessible
content for long descriptions or that more authors would use it correctly.
a href
a href
Semantics
Semantic elements and attributes improve communication. For details please consult the semantics section of this document.
The semantics of an href
does not provide a clear, direct,
explicit, and strong semantic for a long description.
a href
Not Programmatic Determinable
Programmatic determinability aids accessibility.
A normal link below or near an image or in another part of the document is not programmatically determinable. Without programmatically determinability no explicit relationship exists to indicate that a long description has anything to do with an image.
Impossible for One Link to Have Two Destinations
The fact is a href
only works on a limited subset of use cases as
it is impossible for one link to take a user to two locations. An href
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 on the web
that need long descriptions not to have a parent <a>
element mapped to a different task
unrelated to a long description is unrealistic, i.e., a thumbnail <img> that links to a larger .jpg as evidenced by National Institute of Dental and Craniofacial Research.
a href
Forces a Visual Encumbrance
An href
forces a visual
encumbrance on sighted users unless additional code (in the form of CSS or
hidden
) were added in order to hide the visual indicator. Please refer
to the Cascading Style Sheets and hidden
sections of this document for details of why using
these techniques is a bad idea.
No Evidence of Improvement with a href
No evidence has been presented that an href
produces more
accessible content for long descriptions.
iframe
Incorrect Semantics
Semantic elements and attributes improve communication. For details please consult the semantics section of this document.
The semantics of an iframe
does
not provide a clear, direct, explicit, and strong semantic for an
image long description. An iframe
provides a generic
link.
Forces a Visual Encumbrance
The iframe
technique would force a visual encumbrance on sighted
users unless additional code (in the form of CSS or
hidden
) were added. Please refer to Cascading Style Sheets and hidden
for details of why using these
techniques are a bad idea.
An iframe
using CSS or
hidden
Lacks Discoverability
Allowing for discoverability serves other use cases.
Adds Needless Complexity
Using an iframe
to supply long descriptions would
introduce needless complexity. Complexity
confuses and leads to errors.
longdesc
is a simple link.
Reinvents the Wheel
Attempting to use iframe
to provide a long
description reinvents the wheel by duplicating a basic method that
has already previously been created.
No use cases of iframe
for a long
description has been presented that are not already
satisfied by longdesc
.
Lacks Educational Material
No tutorials, books, or documentation exists that explain to
authors how to make an accessible long text alternative with
iframe
.
No Examples in the Wild
No examples in the wild of accessible long text alternatives
with iframe
have been presented for any of the use
cases. No evidence exists that authors have or will use it for
accessible long text alternatives.
Lacks Backwards Compatibility
The iframe
technique lacks backwards compatibility. For further
rationale please consult the backwards
compatibility document.
Retrofitting Problem
Any proposed solution should be easy for authors who are already
publishing content with longdesc
to retrofit their
existing pages. R
etrofitting with iframe
would be difficult, labor intensive, and error prone.
No retrofitting is required for longdesc
.
No Evidence of Improvement
No evidence has been presented that iframe
produces
more accessible content for long descriptions than
longdesc
or that more authors would use it
correctly.
imagemap
imagemap
is an Illogical Technique
Authors are not going to think about image maps when they want to use a complex
image. If they want to use an image they will simply use img
.
It is illogical to require img
to be encased in an
imagemap
in order to provide a long description.
imagemap
Semantics
Semantic elements and attributes improve communication. For details please consult the semantics section of this document.
The semantics of an imagemap
href
does not provide a
clear, direct, explicit, and strong semantic for an image long description. An
imagemap
href
is a generic link.
imagemap
Adds Needless Complexity
Requiring image maps to supply long descriptions would introduce needless complexity.
This in turn would make it more prone to authoring error as complexity confuses and leads to errors. longdesc
is a
simple link - no coordinates to figure out.
imagemap
Programmatic
Determinability
Programmatic determinability aids accessibility.
For a long text alternative provided through a link in an image map to be
exposed to assistive technology programmatically would require a special marking on
one area, such as a longdesc
boolean attribute.
Impossible for One Link to Have Two Destinations
Overloading the mechanism of image maps with that of providing long text alternatives clashes in the case that you need both, an image map and a long text alternative.
The fact is image map syntax only works on a limited subset of use cases. It is impossible for one link to take a user to two locations. It 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 images that need long descriptions to not have a different task unrelated to a long description is unrealistic. Attempting to force dual functionality into single functionality is unworkable.
No imagemap
Examples in the Wild
No examples in the wild of accessible long text alternatives with an
imagemap
have been presented for any of the use cases. No evidence
exists that authors have or will use for accessible long text alternatives.
imagemap
Retrofitting Problem
Any proposed solution should be easy for authors who are already
publishing content with longdesc
to retrofit their
existing pages. imagemap
possesses a radically
different authoring pattern than longdesc
. Because of
this, retrofitting with imagemap
would be difficult,
labor intensive, and error prone.
No long description imagemap
Educational
Material
No tutorials, books, or documentation has been presented that explains to
authors how to make an accessible long text alternative with an
imagemap
href.
No Evidence of Improvement with
imagemap
No evidence has been presented that an imagemap
produces more
accessible content for long descriptions than longdesc
or that more
authors would use it correctly.
New HTML Attribute
New HTML Attribute Status
Creating a new HTML attribute could possibility rectify HTML5's failure of not providing native longdesc functionality and semantics.
Bug 10455 was filed on August 26, 2010 to create a new HTML attribute. Since then some discussion of introducing a new long description attribute has occurred.
However, to date nothing has been specified. Nothing has been implemented.
New HTML Attribute Reinvents the Wheel
Specifying a new element for long descriptions would reinvent the wheel by duplicating a basic method that has already previously been created.
No Evidence of Improvement with a new HTML Attribute
No evidence has been presented that a new attribute would produce more
accessible than longdesc
.
Use Cases for a new HTML Attribute
No use cases have been articulated or presented that are not already satisfied
or could be satisfied by longdesc.
No Examples in the Wild for a new HTML Attribute
No examples in the wild have been presented of a new long description attribute.
A new HTML Attribute Lacks Vendor Support
No Authoring Tools and a new HTML Attribute
No evidence exists that authoring tools would implement a new attribute.
User Agents and a new HTML Attribute
No evidence exists that user agents would implement a new attribute or in a manner intended by its designers.
A New HTML Attribute Lacks Educational Material
No evidence exists that substantial documentation or tutorials are in place and ready to educate developers for a new attribute.
In contrast a longdesc
support base already exists in the form of
authoring tools, tutorials, books etc. These
longdesc
support materials will live on.
A New HTML Attribute Lacks Backwards Compatibility
A new attribute would be void of all backwards compatibility. It would not:
- Be recognized or implemented by existing authoring tools, browsers, or assistive technologies.
- In numerous books, online tutorials, guidelines, laws, policies and standards throughout the world.
For further rationale please consult the backwards compatibility section of this document.
rel="longdesc"
rel="longdesc"
Semantics
Semantic elements and attributes provide a higher level of
communication. The semantics of an a href
alone does not provide a
clear, direct, explicit, and strong semantic for an image long description. An
a href
is a generic link. It is not an explicit link to a long
description. Adding rel="longdesc"
would provide explicit semantics.
However, this technique is riddled with problems.
Impossible for One Link to Have Two Destinations
rel="longdesc"
Use Cases
No use cases of rel="longdesc"
have been presented that are not
already satisfied by longdesc
. Whereas use cases for
longdesc
have been presented that are not satisfied by
rel="longdesc".
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.
rel="longdesc"
Forces a Visual
Encumbrance
rel="longdesc"
fails because a href
forces a visual
encumbrance on sighted users unless additional code (in the form of CSS or hidden
) were added in order to hide the visual
indicator. Please refer to the Cascading Style Sheets and
hidden
sections of this document for details of
why using these techniques is a bad idea.
rel="longdesc"
Reinvents the Wheel
rel="longdesc"
attempts to reinvent the wheel by duplicating a
basic method that has already previously been created. This proposed replacement is
new syntax for the same thing, or for a limited subset as It is
impossible for one link to have two destinations.
No Examples in the Wild for rel="longdesc"
No examples in the wild of accessible long text alternatives with
rel="longdesc"
have been presented for any of the use cases. No
evidence exists that authors have or will use it for accessible long text
alternatives.
No Improvement with rel="longdesc"
No evidence has been presented that rel="longdesc"
produces more
accessible content for long descriptions than longdesc
or that more
authors would use it correctly.
No Implementations exist for
rel="longdesc"
No user agent takes advantage of rel="longdesc"
semantics. None
inform users that a rel="longdesc"
link leads to a description
page.
No evidence exists that authoring tools will implement
rel="longdesc"
.
In contrast user
agents that support longdesc
differentiate between
longdesc
and an a href
. Moreover the new spec text for the
rendering section will help even more user agents do so.
rel="longdesc"
Lacks Backwards
Compatibility
rel="longdesc"
is new. It has no legacy or provenance. Whereas,
longdesc
has legacy content and legacy support. It lacks all backwards compatibility. It 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.
For further rationale please consult the backwards compatibility section of this document.
In sum rel="longdesc"
is unworkable and not an excuse to drop
longdesc
from HTML. Its existence does
not negate the need for longdesc
.
summary
/details
summary
/details
Semantically Incorrect
Semantic elements and attributes provide a higher level of
communication. The semantics of summary/details
does not provide
an explicit and strong semantic for an image long description. This technique
provides incorrect semantics for long descriptions of images. The HTML
specification states,
The
summary
element represents a summary, caption, or legend for the rest of the contents of thesummary
element's parentdetails
element, if any.
An img
element
isn't a summary, caption, or legend. An img
element is an image. An image and a long
description are peers: the same thing expressed in two different
mediums.
summary
/details
Forces
a Visual Encumbrance
The summary
/details
technique would force a visual encumbrance on sighted users unless
additional code (in the form of CSS or hidden
) were added in order to
hide the visual indicator. Please refer to the Cascading Style
Sheets and hidden
sections of this document
for details of why using these techniques is a bad idea.
summary
/details
Lacks Ability
to Provide Description in a Separate Document
The summary/details
technique lacks the key functional requirement
of providing a long description in a separate
document.
summary
/details
Assistive Technology Support Support
summary
/details
is not accessibility
supported semantics wise. HTML5
accessibility states that this technique,
Currently provides the same amount of semantic information to AT as a
div
element.
summary
/details
Lacks
Backwards Compatibility
The summary/details
technique for long descriptions lacks backwards compatibility. It 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
summary/details
is used. - In numerous books, online tutorials, guidelines, laws, policies and standards throughout the world.
For further rationale please consult the backwards compatibility section of this document.
summary/details
Retrofitting Problem
Any proposed solution should be easy for authors who are already
publishing content with longdesc
to retrofit their
existing pages. summary/details
possesses a radically
different authoring pattern than longdesc
. Because of
this as well as its on-page limitations, retrofitting with summary/details
would be difficult, labor intensive,
and error prone. No retrofitting is required for longdesc
as it is an existing HTML feature.
No Examples in the Wild exist for
summary
/details
No examples in the wild of accessible long text alternatives with
summary
/details
have been presented for any of the use
cases. No evidence exists that authors have or will use for accessible long text
alternatives.
No Evidence of Improvement with summary
/details
No evidence has been presented that summary
/details
produces more accessible content for long descriptions than longdesc
or that more authors would use it correctly.
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
- AccessAbility
- Accessibilité du Web
- Accessibility Task Force Bug Comparisons
- Alienor
- Assisted Human Reproduction Canada
- Axel Schäfer, SPD Abgeordneter im Deutschen Bundestag für Bochum
- Cornell University
- Camera Obscura
- Center for the Study of Religion and American Culture
- Commonwealth of Massachusetts
- Conseil supérieur de la langue française
- CSS Squirrel
- Dhammadana
- dizABLED
- easyALBUM
- Environment Canada
- Federal Motor Carrier Safety Administration
- Financial Transactions and Reports Analysis Centre of Canada
- Grinning Planet
- Hawaii Public Schools
- Indiana University-Purdue University Indianapolis Common Core Curriculum
- Interacciones
- Korea Employment Information Service
- Kyungpook (South Korea) Michigan State University National Institute of Information and Communications Technology
- National Adult Literacy Database
- National Institute of Dental and Craniofacial Research
- National Institutes of Health
- National Institute of Standards and Technology (NIST)
- Natural Resources Canada
- nota-ben
- Object Description
- Oracle
- Paris Web
- Procréation assistée Canada
- Public Service Commission of Canada
- Rebuilding the Web
- Régie des rentes du Québec
- Research and Innovative Technology Administration / US Department of Transportation
- San Diego University
- Santa Barbara Public Library
- Securian
- SIGBerrien Metal Products, Inc.
- Snowdon Award Scheme
- South West Institute of TAFE
- SPD Abgeordneter im Deutschen Bundestag für Bochum
- Statistics Canada
- Statistique Canada
- State of California
- tech.burningbird
- Texas State Library
- The Organisation Development Company
- U.S. Department of Health and Human Services
- University of Minnesota Duluth
- 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.
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.
Impossible for One Link to Have Two Destinations
As explained, one link cannot take a user to two locations. Attempting to force dual functionality into single functionality is unworkable.
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 users freedom of choice. Authors are already
providing this functionality, as evidenced by real world examples.
Equal Access to Dual Functionality
longdesc
affords equal access to dual functionality.
Separate Logo Link Is Not Programmatically Determinable
As explained programmatic determinability aids accessibility. 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.
Description Available in a Separate Document Provides Efficiency
Using one global document to provide descriptions for multiple instance of the same image is powerful. It provides efficiency and scalability making authoring and maintenance easy wherever instances of the same image are used in multiple locations. For a full explanation of this please consult description available in a separate document provides efficiency.
Real World Sites Implement longdesc
on Logos
The logo use case is evidenced by real world examples in the wild. For example, as documented in the use case notes, the following sites provide logo functionality:
- AccessAbility SIG
- Berrien Metal Products, Inc.
- Center for the Study of Religion and American Culture
- Hamilton College
- 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 explained the suggested alternatives are not viable. Most are not programmatically determinable. They fail logo use case constraints and do not meet requirements.
For detailed rationale of why aria-describedby
is not viable,
please consult the aria-describedby
section of this document
as well as:
- Description Available in a Separate Document Provides Efficiency
- Author Skill Sets Differ
- Forcing Descriptions on Users is Harmful
- Structured Markup Facilitates Critical Functionality
- Bridging Technology
Existence of other approaches do not justify killing off
longdesc
. It is an unwarranted conclusion.
Users Who Desire Access Can Have It
As 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.
Cartoonist Kyle Weems (aka CSS Squirrel) provides artistic requirements and design functionality testimony [web.archive]:
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.
Description Available in a Separate Document Provides Efficiency
Using one global document to provide descriptions for multiple instance of the same image is powerful. It provides efficiency and scalability making authoring and maintenance easy wherever instances of the same image are used in multiple locations. For a full explanation of this please consult description available in a separate document provides efficiency.
For instance the CSS Squirrel uses images in separate documents that share the same long description page.
Alternative Techniques
As explained the suggested alternatives are not viable. Most are not programmatically determinable. They fail cartoon use case constraints and do not meet requirements.
For detailed rationale of why aria-describedby
is not viable,
please consult the aria-describedby
section of this document
as well as:
- Description Available in a Separate Document Provides Efficiency
- Author Skill Sets Differ
- Forcing Descriptions on Users is Harmful
- Structured Markup Facilitates Critical Functionality
- Bridging Technology
In addition:
- 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 and is not programmatically determinable
- Normal link with appropriate link text, adjacent to the image fails cartoon use case constraints and is not programmatically determinable.
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 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 page. For
example, Dayton Art Institute's accessart site uses the
longdesc
attribute to take the user to a long description page and ana href
to go to a different "dialogue with the director" page. Thelongdesc
attribute is used to describe all images in all of the tours. - When the aesthetic constraints prevail. Ignoring aesthetic considerations is ignoring reality.
As previously explained it is impossible for one link to have two destinations.
Alternative Techniques
As explained the suggested alternatives are not viable. They fail artwork use case constraints and do not meet requirements. In particular:
- For detailed rationale of why
aria-describedby
is not viable, please consultthe aria-describedby
section of this document as well as: - For detailed rationale of why an adjacent normal link not viable, please consult the Programmatic Determinability Aids Accessibility section of this document.
Existence of other approaches do not justify killing off
longdesc
. It is an unwarranted conclusion.
Users Who Desire Access Can Have It
As explained any user who wants to access 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
The suggested alternatives are not viable. Most are not programmatically determinable. They fail screenshot use case constraints and do not meet requirements.
For detailed rationale of why aria-describedby
is not viable,
please consult the aria-describedby
section of this document
as well as:
- Description Available in a Separate Document Provides Efficiency
- Author Skill Sets Differ
- Forcing Descriptions on Users is Harmful
- Structured Markup Facilitates Critical Functionality
- Bridging Technology
A normal link below the image and mentioning the link below in the image's short text alternative fails screenshot use case constraints. It is not programmatically determinable.
Existence of other approaches do not justify killing off
longdesc
. It is an unwarranted conclusion.
Users Who Desire Access Can Have It
As 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 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 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 explained, the suggested alternatives are not viable. They do not meet requirements.
- For detailed rationale of why
aria-describedby
is not viable, please consultthe aria-describedby
section of this document as well as: - In
addition:
- 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.
- Providing an adjacent normal link 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
- Assisted Human Reproduction Canada
- 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
- Procréation assistée 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
Notably 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 explained any user who wants to access a
longdesc
can do so by using tools that support
longdesc
.
Alternative Techniques
- For detailed rationale of why
aria-describedby
is not viable, please consultthe aria-describedby
section of this document as well as: - Other alternative techniques are not viable. They do not meet requirements. They fail photograph use case constraints.
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-2012 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.
Description Available in a Separate Document Provides Efficiency
Using one global document to provide descriptions for multiple instance of the same image is powerful. It provides efficiency and scalability making authoring and maintenance easy wherever instances of the same image are used in multiple locations. For a full explanation of this please consult description available in a separate document provides efficiency.
For instance the University of Minnesota Duluth uses images in separate documents that share the same long description page.
Alternative Techniques
As explained, the suggested alternatives are not viable. They do not meet requirements.
For detailed rationale of why aria-describedby
is not viable,
please consult the aria-describedby
section of this document
as well as:
- Description Available in a Separate Document Provides Efficiency
- Author Skill Sets Differ
- Forcing Descriptions on Users is Harmful
- Structured Markup Facilitates Critical Functionality
- Bridging Technology
Existence of other approaches do not justify killing off
longdesc
. It is an unwarranted conclusion.
Users Who Desire Access Can Have It
As 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
As explained any user who wants to access a
longdesc
can do so by using tools that support
longdesc
.
Description Available in a Separate Document Provides Efficiency
Using one global document to provide descriptions for multiple instance of the same image is powerful. It provides efficiency and scalability making authoring and maintenance easy wherever instances of the same image are used in multiple locations. For a full explanation of this please consult description available in a separate document provides efficiency.
For instance the Texas State Library uses images in separate documents that share the same long description page.
Author Skill Sets Differ
As explained, a different skill set exists between JavaScriptlLibrary/app developers and the run of the mill content authors/web designers.
Alternative Techniques
The suggested alternatives are not viable. Most are not programmatically determinable. They fail Illustration use case constraints and do not meet requirements.
For detailed rationale of why aria-describedby
is not viable,
please consult the aria-describedby
section of this document
as well as:
- Description Available in a Separate Document Provides Efficiency
- Author Skill Sets Differ
- Forcing Descriptions on Users is Harmful
- Structured Markup Facilitates Critical Functionality
- Bridging Technology
Existence of other approaches do not justify killing off
longdesc
. It is an unwarranted conclusion.
Real World Sites Implement longdesc
on
Illustrations
The illustration 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.
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.
Description Available in a Separate Document Provides Efficiency
Using one global document to provide descriptions for multiple instance of the same image is powerful. It provides efficiency and scalability making authoring and maintenance easy wherever instances of the same image are used in multiple locations. For a full explanation of this please consult description available in a separate document provides efficiency.
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
The suggested alternatives are not viable. Most are not programmatically determinable. They fail etext image descriptions image use case constraint and do not meet requirements.
Existence of other approaches do not justify killing off
longdesc
. It is an unwarranted conclusion.
Users Who Desire Access Can Have It
As explained any user who wants to access a
longdesc
can do so by using tools that support
longdesc
.
Describing a Newspaper Image (Lightbox Technique)
The Zero Edit change proposal is wrong regarding the validity of this use case. It incorrectly stated that:
This does not seem to be a valid use case: the image of the newspaper front page cuts off the text of the article at the bottom of the image, and the image appears to include unrelated stories. Providing a text version of a partial story is pointless when the article text already links to the full article within the main body of the text. The purpose of the image of the front page can be effectively described just with a short text alternative like "Front cover of Newspaper on 9.9.99 when we originally broke the story"
Where an image is cropped is a red herring to this use case. The point of the use case is that sighted users are provided detailed visual content. That content is locked in an image. It includes text as well as look and feel details of visual appearance. A blind user should be afforded the equal opportunity to have that detailed visual content of the large image described to them.
Real World rel="lightbox"
Images
Real world images use lightbox functionality on an a href
with
rel="lightbox"
to display a larger image while simultaneously using
longdesc
to provide a text description.
For example the lightbox technique is used on screenshots, photographs of paper forms, and equipment tags.
Sample markup:
<a href="images/big/checkin.jpg" rel="lightbox"
title="Lightbox Image">
<img src="images/checkin.jpg" id="checkin1"
alt="Annotated Lab Check In System Screenshot"
longdesc="images/ld/checkin.html#content_frame"
width="200"
height="149" />
</a>
The technique provides equal access. In this example it enables employees with disabilities and employees without disabilities needed information to do their jobs.
Impossible for One Link to Have Two Destinations
One link cannot take a user to two locations. Attempting to force dual functionality into single functionality is unworkable.
Alternative Techniques
As explained the suggested alternatives are not viable. They fail newspaper image (lightbox) use case constraints and do not meet requirements.
For detailed rationale of why aria-describedby
is not viable,
please consult the aria-describedby
section of this document
as well as:
- Author Skill Sets Differ
- Forcing Descriptions on Users is Harmful
- Structured Markup Facilitates Critical Functionality
- Bridging Technology
Existence of other approaches do not justify killing off
longdesc
. It is an unwarranted conclusion.
Users Who Desire Access Can Have It
As 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 use it and depend on it to provide 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 two thousand 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. The only solution that meets all requirements and fulfills all specific use cases is longdesc. 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.
Notes
[1] Fails whenever link is used for another function. And it is not automatically announced to users of screen readers like JAWS, SuperNova/Hal or WindowEyes that a long description is available.
[2] Fails because link semantics are already well-defined.
[2a] To provide proper semantics rel="longdesc"
would be needed. But rel="longdesc"
is not implemented by existing
tools.
[3] This proposed solution fails as it is neither formally specified or nor implemented.
[4] Unknown. No evidence presented.