ChangeProposals/LongdescZeroEdit

From HTML WG Wiki
< ChangeProposals
Revision as of 05:02, 7 September 2011 by Mturvey (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Zero Edit Change Proposal: Keep Longdesc Non-Conforming

Summary

This is a Change Proposal for ISSUE-30

The longdesc attribute does not improve accessibility in practice, is poorly supported and has a history of authorability, discoverability and usability problems. This proposal is for keeping the longdesc attribute as currently specified in the HTML5 spec:

  • Make the longdesc attribute obsolete, so authors who use a conformance checker on their pages containing a longdesc attribute will see an error, which will hopefully encourage them to use a more accessible, more robust techniques that work for everyone.

Making progress on web accessibility requires being candid about past failures, and providing new alternative techniques that do not replicate problems with existing solutions.

Rationale

The WHATWG and HTML WG have previously identified evidence that longdesc is problematic as actually used: authors use it incorrectly or misuse it for functionality unrelated to long descriptions, users are not always aware how to access the longdesc link even if their user agent supports it, and it does not degrade gracefully, locking out most users.

Even though the intent of the feature is to improve accessibility, it seems to create a bad accessibility experience due to usability, authoring and perceivability problems, and should be obsoleted in favour of better techniques.

Problems with Longdesc

  • Evidence suggests users have problems accessing the longdesc even when their user agent supports it:
    • This video (.wmv) shows "take two" of an experienced blind user using Jaws for Windows to access a longdesc link. The first take was abandoned because the user could not access the longdesc - even with the help of a PFWG member sitting right next to him.
    • This comment suggests even with "university students who are pretty adept at using the screen reader [..] many of them don't realize how to access the longdesc content (even though in JAWS it is as easy as pressing Enter). "
  • Evidence suggests authors often misunderstand how to use the longdesc attribute and use it incorrectly. One study found over 99% were incorrect. A more recent study purported to find "79% of the longdesc attributes were correct" but on closer inspection this result is misleading: most of the longdesc attributes in the study were from data.gov where the longdesc attribute is used for carousel functionality, others are clearly links to images, top level domains link facebook or twitter, or other pages that are not long descriptions like Adobe's PDF Reader download page. Examining the results (Excel file) of this study (which does not declare how the sample was selected but seems to be focused on .gov websites, which can be expected to generally provide better web accessibility due to legal requirements and in-house expertise) suggests about 9% are actually properly used longdesc links, 9% are blank, 16% are the actual text description instead of a URL, 2% are links to images and the remaining ~63% are links to pages that are not long descriptions.
  • longdesc can only be used in situations where the author wants to hide the link; authors that wish to provide a long description for all users must use a different technique. aria-describedby can be used in multiple scenarios: when the description is present on the page, when the description is available via a link (optionally positioned off-screen with CSS for aesthetic reasons) and could (potentially) be used when the image is contained inside a normal link to associate the image with the link.
  • longdesc only applies to images. Other elements that may need a long description, like a table or a an SVG image have to use a different technique like aria-describedby. There is some utility to be gained from using a generally applicable technique: authors only have to use one approach which can then be applied in different scenarios consistently.
  • Only a small number of websites use the longdesc attribute and most already provide an alternative link (WCAG techniques recommended using a duplicate link until WCAG2 was released in 2008). Although a low level of usage is not in itself a reason to obsolete longdesc, if users only very rarely come across pages using longdesc they may have forgotten how to access them, or have given up checking for the existence of longdesc (eg in a context menu) making it effectively useless in practice.
  • To be successful longdesc needs to have an activation mechanism as easy and intuitive to use as a normal link, which is probably impossible. If it is not as easy and intuitive to use as a normal link, it means that using this "accessibility" technique results in a net decrease in usability and accessibility: users have to be trained in how to access the longdesc link because it cannot use normal "clicking" activation techniques because it may be inside a link.
  • longdesc is not widely supported at the current time and is not backwards compatible or "robust" with user agents that do not support it, unlike aria-describedby which points to an element on the page. Accessibility specialists currently recommend using a normal link or in page description as methods preferred over using longdesc.
    • WebAim recommend providing "the long description in the context of the document itself" or "a link to a long description via a normal text link" as preferred methods over using longdesc
    • RNIB (word doc) "don't recommend the use of the LONGDESC attribute because it isn't available to users without screen readers. The long description should be made available to everyone who can't process information conveyed in images, whether or not this inability is sight related." (which is different from recommending not to use longdesc apparently). They recommend using "related text on the same page." or "a separate page, with a link to that page placed next to the image (for instance 'Full text description of the information presented in graph A above')"
  • WCAG2 explicitly notes that text alternatives may also be useful to other users, e.g. user with cognitive disabilities:
"Text alternatives may help some people who have difficulty understanding the meaning of photographs, drawings, and other images (e.g., line drawings, graphic designs, paintings, three-dimensional representations), graphs, charts, animations, etc. … Additionally, text alternatives support the ability to search for non-text content and to repurpose content in a variety of ways."
  • The general consensus of opinion including WAI PFWG members is that longdesc should be obsoleted, though there are disagreements over timing, with some PFWG members suggesting we need more time to properly deprecate longdesc. But longdesc is not currently widely supported enough in Assistive Technologies (AT) or browsers to rely on as an effective technique. Screen readers including VoiceOver, Orca and NVDA do not natively support it without plugins that users are not guaranteed to have installed, and the only mainstream browser with significant usage to provide access to longdesc via a hidden context menu link is Opera.
  • Another approach from some accessibility advocates seems to suggest it is unacceptable to obsolete now, when there is a very small amount of usage on the web, users and authors have problems using it, and most user agents do not support it; and instead we should launch a campaign to retrain all users and authors, and improve longdesc support in user agents, and then obsolete it. This plan is sub-optimal: training and implementation efforts would be better directed towards supporting a long term solution like aria-describedby.

Programmatic Determinability

The change proposal to restore longdesc emphasizes the need to be able to programmatically determine that a long description link is present, but only suggests that users need to be able to determine a link is present, and provides no evidence that users also need to be able to discern a long description link from an normal link.

However, UAAG2 does mention possible uses for this programmatic determinability:

  • Displaying a visual indicator
  • Rendering long descriptions "as replacements for the original rendered content."

In both these cases, a normal link associated with the image using aria-describedby or with rel=longdesc on an linked image appear to provide the required programmatically determinable link, as a progressive enhancement. The longdesc attribute does not provide progressive enhancement, so although it provides the programmatic determinability, it does not work at all on the majority of user agents where it is currently unsupported.

The displaying a default visual indicator seems a questionable use case as it's unclear why users would need to be informed a long description is available or differs from a normal link, or why an author would deliberately use a hidden technique for the purpose of displaying a visual indicator. The replacing rendered content does seem to be a valid potential use case for Digital Talking Books, but aria-describedby or rel=longdesc could provide the same functionality. There do not seem to be any use cases that require replacing the rendered content with the long text alternative when the image is also linked, so rel=longdesc on a normal link seems to meet the requirements for in-situ replacements.

Using aria-describedby

  • There has been some confusion over whether aria-describedby can be used to point to links and expose other structured or interactive content
  • Early implementations appear to have incorrectly flattened the content of the element referenced by aria-describedby even when the description is not explicitly set to hidden. This problem seems to have arisen because the WAI-ARIA1.0 spec is vague on this issue.
  • However the WAI-ARIA 1.0 User Agent Implementation Guide notes "aria-describedby may reference structured or interactive information where users would want to be able to navigate to different sections of content. User agents MAY provide a way for the user to navigate to structured information referenced by aria-describedby and assistive technology SHOULD provide such a method."
  • aria-describedby does not appear to be designed to be limited to only expose flattened text: the use case for providing a long description on a separate page using aria-describedby is included in the WAI-ARIA 1.0 Authoring Practices document in response to specific last call feedback on this issue.
  • Feedback from two people who work on browsers (Firefox and Webkit) suggests fully exposing all "html semantics to AT users" is currently being worked on at Mozilla, and is "tentatively" a "reasonable requirement". In contrast Firefox has already removed the partial support it previously provided for exposing longdesc in the context menu. It does seem reasonable to expect "aria-describedby will be supported by assistive technologies at least as well as longdesc when HTML5 becomes a W3C Recommendation" either directly in the AT or indirectly via the functionality exposed by the browser by 2022, and will support structured content.

Use Cases

Notes on the use cases presented in the Change Proposal to Reinstate longdesc

The use cases appear to have been reverse engineered from existing longdesc functionality:

  • There seems to be an assumption that visual noise/visual clutter/forced visual encumbrances/default visual indicators are a significant usability problem, but no evidence is provided to support this assumption.
  • In contrast the lack of perceivability resulting from using an invisible technique is apparently assumed to not be a significant usability problem at all.
  • a programmatic tie to the image is listed as a requirement but no explanation is provided for why this is a requirement for most of the use cases (but see Programmatic Determinability section above):
    • In-place replacement of an image with its’ text alternative has been put forward as one possible use in UAAG2, but it’s unclear whether this would ever be required for a linked image (like a logo linked to the homepage). For images that are not already linked, a normal link with rel=longdesc appears to meet the requirement.
    • Another possible use suggested in UAAG2 is displaying a visual indicator but this suffers from the same problem as “d” links: users do not know what the indicator represents, or necessarily how to access the description, and it’s unclear whether this is in fact a useful feature, or that people with or without disabilities benefit from this information in any way.
    • Using rel=longdesc seems to be a better option overall for the majority of images which are not linked: it works for everyone now, and AT can use the association to programmatically identify the link as a long description for the image if this turns out to be a valid requirement in future.
  • It’s unclear why accessing a long description cannot take the user away from their current position (like any other link on the page), or how a longdesc link meets this requirement but aria-describedby or rel=longdesc on a normal link could not. Current screen readers that support longdesc either navigate to the longdesc link as with a normal link in the current window, or open the link in a new window.
  • It’s unclear why a normal link, optionally associated with aria-describedby or rel=longdesc does not meet the “long description must not be forced on the user” requirement. More informative link text available with rel (in the image’s alt attribute) or aria-describedby (inside the anchor) can provide more information about the destination of the link beyond a simple identification as a “long description” and meets the WCAG2 guideline for providing clear link text, and provides additional information to the user about whether they want to force a long description on themselves by visiting a link.
  • All of the use cases only attempt to address the needs of blind users. But we know that text alternatives may also be useful to other users and this is explicitly noted in WCAG2. For example, people with a visual impairment who can perceive the image but need text to read and understand it; people with low educational attainment who do not understand a chart but can understand a text summary of trends; non-native language speakers who would benefit from machine translation of a cartoon transcript to their native language, sighted users who may wish to access the long description to read additional information about an art exhibit or photograph that they may have missed in the actual image.
  • It’s unclear whether we want to encourage using deliberately hidden accessibility features by providing an attribute specifically for this purpose. It appears to directly contradict WCAG2’s “perceivable” principle, and may encourage authors to use hidden techniques when a visible link with better usability would work just as well or better for their requirements.
  • Visual presentation is important to authors, but that does not mean we should accommodate every author requirement, especially when that requirement contradicts basic accessibility and usability principles. Other accessibility guidelines constrain what authors do to ensure they do not damage accessibility for aesthetic reasons, for example visual contrast guidelines limit the colour palette available to designers.
  • CSS is commonly used by authors and recognised as a best practice way to control visual presentation, and techniques for exposing content only to screen reader users are widely available and well known, with the proviso that "Cases where verbose cues or instructions are provided only for screen reader users are most likely a reflection of poor design and accessibility."
  • Non AT-users and users with AT that is not a screen reader may also benefit from the long description but be unaware it’s there because it’s hidden. It’s unclear in any of these use cases the long descriptions are only useful to blind users, so longdesc here could be viewed as an inaccessibility technique: longdesc makes the description link available to (at best, some) screen reader users at the expense of making it effectively inaccessible to everyone else.
  • Using CSS also means users can access the full page content including hidden elements by turning off CSS or using a custom user stylesheet, and authors can provide alternative stylesheets to meet different user groups requirements e.g. “verbose” and “concise” stylesheets to control “visual clutter” if this is a real issue.

Websites often use a logo image at the top of the page, linked back to the homepage of the website.

  • visually-impaired users and sighted users may also benefit from being able to read a long description of the logo to understand what it represents or means, which may not be visually apparent, especially in a small logo in a page header.
  • All users, not just blind users, could benefit from to access a logo description, for example when a new logo is launched to understand the changes, or for people with cognitive impairments to understand what the image represents.
  • Having a normal link as part of the website navigation does not seem to be an unreasonable requirement: other websites use this approach:
    • Accessible Gaming Rendering Independence Possible (AGRIP) Project - note that the logo image is treated as styling, and is only present in the page as a background image. In this case, there is no programmatic association at all between the actual image and the link to the description, but the content is available to everyone.
    • Parents Forum - provides a link to the description in the navigation, without a link on the image.
    • Archdiocese of Denver - provides a link to the description in the navigation, with a link to the homepage on the logo image.
  • It is not explained why having the description programmatically tied to the logo is necessary.
    • Displaying a visual indicator of the description constitutes a “forced visual encumbrance” and suffers from the same usability problems as “d” links because users do not know what it means without specific training, and the indicator may be too small to be apparent to users with a visual impairment.
    • 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.
    • The AGRIP website is aimed at visually impaired users but does not a provide the logo image as content in the page at all, in favour of using a CSS background image with a normal unassociated link to the logo description.

These techniques meet the use case's requirements:

  • Use aria-describedby to point to a link positioned off screen with CSS.
  • Use an image map, with an area linked to the homepage and an area linked for the logo long description, optionally with a rel=longdesc attribute or aria-describedby attribute on the image pointing to the long description area.

Other approaches:

  • Use aria-describedby to point to a visible link in the website navigation
  • Provide a normal link that is not programmatically tied to the logo image for all users
  • Provide a normal link that is not programmatically tied to the logo image, positioned off screen just for blind users.
  • Although a normal link without aria-describedby does not provide a programmatic association, it does mean blind users are not exposed to verbose “audio clutter” when navigating the website. A regular user of a website browsing using a screen reader would not benefit from hearing the long description announced e.g. “Press Alt-Enter for long description” every time they want to navigate to the homepage, on every visit to the website, on every page, but may wish to hear a description of the logo once to get an idea of the visual branding, and this could be made available from the site’s main navigation sections, a link positioned off screen, on an about page or in a marketing/branding section, or with a normal link on the logo image on the homepage, where a self-link to the homepage is not required.

Describing a Cartoon

  • Users without a visual impairment may also benefit from a transcript, for example to use machine translation tools on a comic that is not in their native language, to understand context or get character names, or to copy and paste dialogue, so generally hidden links of this kind should be discouraged in this scenario in favour of other techniques that are accessible to everyone.

Alternative techniques for describing a cartoon

These techniques meet the use case's requirements:

  • A normal link anchor on the image, progressively enhanced with a rel=longdesc on the link (or possibly aria-describedby) to provide a perceivable solution without requiring a longdesc attribute and without imposing a “forced visual encumbrance”
  • Provide a separate text link, positioned offscreen and associated with the image using aria-describedby: this technique is also used on the CsSquirrel examples.

Other approaches:

  • Use a 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"
  • Use a normal link with appropriate link text, preferably adjacent to the image.
  • None of the real world examples have other functionality mapped to the comic image. If this is an real requirement, for example for a lightbox function, the long description link could be presented below the image in the lightbox and associated with the image using aria-describedby, or the lightbox image could be linked with a rel=longdesc attribute.
  • Use the details element as a perceivable disclosure widget from which the user can obtain additional information.
  • Use the figure element with a link in the figcaption, optionally enhanced with aria-describedby and/or optionally positioned off screen with CSS.
  • In future, SVG could provide a potential alternative approach, removing the need to provide a separate text version of the content.

Describing Artwork

  • The use case requires "direct, dual, programmatic access to both the long description and to a larger version of the image from an image gallery page displaying thumbnails but does not explain why linking the thumbnails to pages with both the larger image and the long description as in-page content would not be a viable solution.
  • Ability to use the same text for the thumbnail image and the large image is unnecessary: the short text alternative on the thumbnail provides a link for all users to follow for more information about the image, without it being forced upon them.
  • There's some evidence for sighted users also appreciating long descriptions of artwork:
As is frequently the case with accommodations for people with disabilities, visual descriptions are also beneficial for the general public. They are helpful for people who are unable to access images because of computer hardware or software limitations. And as indicated by positive responses from museum patrons, visual descriptions are appreciated even by people with normal eyesight as they look at works of art. This may be because the descriptions point out details that they might not have noticed, or because people often welcome the perspectives of others on topics such as art. (emphasis added)
  • Another in the wild example, the Burmese Religious Building Gallery includes a visible link to a page with all the long descriptions. So both the real world examples cited both also provide a visible links to the long descriptions.
  • The third example does not provide a normal link so is currently inaccessible to most users including at least some screen reader users. A normal link on the image to a page with the larger image and description is a better solution: it works right now for everyone without requiring software upgrades, special activation techniques or user training and does not impose a “forced visual encumbrance.”

Alternative techniques for describing artwork

These techniques meet the use case's requirements:

  • Use aria-describedby to point to links positioned off screen with CSS.
  • Use an image map, with an area link to the large image and an area link for the long description, optionally with a rel=longdesc attribute.

Other approaches:

  • Put the larger image and the long description on a page linked from the thumbnail. The in-page description can be programmatically tied to the image using aria-describedby, or aria-describedby can point to a link to a long description on a separate page.
  • Put the larger image on a page inside a normal link, linked to a page with the long description, and use rel=longdesc on the normal link.
    • provide a link to the text description separately from the image link, as shown on the W3C's Facts page

Describing Screenshots

  • Long descriptions of screenshots may also be useful to non-native language speakers for machine translation so they can understand the text in the image, this may be an important requirement for large international companies.
  • People with a visual impairment may be able to perceive the image but need a text alternative to be able to read the writing in the image.
  • The Oracle and IBM the examples in the wild cited both also provide visible text links.
  • It’s unclear why documentation teams in large companies would gladly remove a WCAG2 “perceivable” visible link but would not gladly remove a longdesc link when longdesc has a well-established history of usability problems and is not “perceivable”.
  • The Michael Fields example goes to a page that does not appear to be a long description of the screenshot.
  • The Rebuilding the Web and MyOpera examples do not provide a normal link so are currently inaccessible to most users including at least some screen reader users. Both of these examples would be more accessible and offer better usability if they used a normal link on the image, optionally progressively enhanced with rel=longdesc, or a separate text link nearby associated with aria-describedby. Unlike longdesc both these techniques use progressive enhancement so are more robust, and work for everyone now.
  • The Reinstate longdesc Change Proposal mentions linking the images to the homepage for unknown reasons: this is unnecessary.
  • The use case dismisses aria-describedby as a suitable technique because it is "read aloud without any user interaction" but this appears to be an error in early implementations of the feature. The WAI-ARIA 1.0 User Agent Implementation Guide notes "aria-describedby may reference structured or interactive information where users would want to be able to navigate to different sections of content. User agents MAY provide a way for the user to navigate to structured information referenced by aria-describedby and assistive technology SHOULD provide such a method."
  • aria-describedby does not appear to be designed to be limited to text that appears on the same page: the Consensus Resolutions on Text alternatives in HTML 5 supported using aria-describedby to allow users to navigate to a link, and this use case is also included in the WAI-ARIA 1.0 Authoring Practices document.

Alternative techniques for describing screenshots

These techniques meet the use case's requirements:

  • Use aria-describedby to point to a link positioned off screen with CSS.
  • Link the screenshot image to the long description using a normal link, with rel=longdesc for programmatic determinability.

Other approaches:

  • Use aria-describedby to point to a visible link in a figcaption (this is similar to the approach Oracle currently uses)
  • Provide a normal link below the image and mention the link below in the image's short text alternative.

Describing a Chart

  • User with cognitive disabilities may also require a text alternative to be able to understand the information represented in a graph.
  • All users benefit from being able to access a data table for the graph so they can inspect the data for themselves, and check the graph does not present a misleading impression.
  • A normal link on the graph, progressively enhanced with rel=longdesc provides a perceivable option without imposing "information overload of redundant information" or adding "visual clutter"
  • Some visual clutter may be useful: the graph could be in a figure element, with a caption linked to the long description, making both caption and long description perceivable and usable by all.
  • A visual indication could also be provided with the details element for minimum visual clutter.

Alternative techniques for describing a chart

These techniques meet the use case's requirements:

  • Use aria-describedby to point to a link positioned off screen with CSS if the description is only useful for blind users.
  • Use a figure element with a link to the long description in the figcaption element (some visual clutter) as per WCAG2 G73
  • Use the details element as a perceivable disclosure widget from which the user can obtain additional information about the graph.

Other approaches:

  • Provide the information in the graph as part of main commentary within the page text per WCAG2 G74
  • Provide an adjacent normal link that is not programmatically tied to the image for all users as per WCAG2 G73
  • Provide a normal link that is not programmatically tied to the image, positioned off screen just for blind users.
  • Use an accessible chart technique using a suitably marked up data table

Describing a Photograph

  • Sighted users may also wish to access a long description of the photo for context or more information.
  • One of the in the wild examples prompted a sighted user to write the "longdesk" extension for Firefox to make the longdesc links more easily discoverable

Alternative techniques for describing a photograph

These techniques meet the use case's requirements:

  • Use aria-describedby to point to a link positioned off screen with CSS if the description is only useful for blind users.
  • Use a figure element with a link to the long description in the figcaption element (some visual clutter)
  • Use the details element as a perceivable disclosure widget from which the user can obtain additional information about the graph. (some visual clutter)
  • Use a normal link on the image with a rel=longdesc attribute to programmatically tie the link to the image.

Other approaches:

  • Provide a separate text link that is not programmatically tied to the image for all users
  • Provide a link on the image with no programmatic association for all users
  • Provide a normal link that is not programmatically tied to the image, positioned off screen just for blind users.

Describing an Email Banner

  • This does not appear to be a valid use case.
  • The banner image is for decoration and to provide a link to the homepage, providing a rather bleak long description for it appears to be accessibility theatre.
  • The only in the wild example cited appears to be by Laura.
  • If this is a valid use case, techniques for the logo description described above could be used instead of the longdesc attribute.

Describing Illustrations

  • Other sighted users who have difficulty understanding illustrations would also benefit from access to the long description
  • The use case appears to be unrealistically constructed to disallow using aria. Employees are assumed to be fine with using longdesc, which has a proven history of being misunderstood and misused by authors, but unable to learn a new technique that at least has the potential to be less confusing for authors.
  • If employees can't be trusted with AT-specific markup, just providing a normal link on the image appears to satisfy the use case. It does not provide a programmatic tie between the image and the link - beyond it being determinable as a linked image - but the use case doesn't appear to require this functionality specifically.
  • A normal link could be used with aria-describedby or rel=longdesc for determinability
  • A normal link also allows images on different pages to link to a single description.

Alternative techniques for describing illustrations

These techniques meet the use case's requirements:

  • Use aria-describedby to point to a link positioned off screen with CSS if the description is only useful for blind users.
  • Use a normal link on the image with rel=longdesc

Other approaches:

  • Use a normal link on the image without rel=longdesc if programmatic determinability is a hypothetical requirement
  • Use normal structural markup to provide the text content, and style the pages with CSS to avoid the need to use bitmap images
  • Use the details element as a perceivable disclosure widget from which the user can obtain additional information about the illustration.

Facilitating etext Image Descriptions

  • This does not appear to be a valid use case.
  • It's unclear how longdesc "facilitates the creation, storage and retrieval of long descriptions in a repository system"; or how longdesc is a requirement for a database system that presumably stores the images and the long description URLs as separate relational entities.
  • It's unclear whether "Must adhere to e-text standards" is a relevant requirement. The use case links to the Open eBook™ Publication Structure 1.0.1 but this standard is from 2001, when it appeared to be reasonable to expect that UAs would add support for the longdesc attribute. Most current ebook and Digital Talking Book software and hardware do not currently support longdesc. This standard needs to be updated to more accurately reflect current best practices.
  • Emails from the DIAGRAM project are cited, but these emails do not appear to list specific requirements
  • It's unclear why a normal link with rel=longdesc would not provide a superior solution. A solution based on progressive enhancement would appear to be a far more effective and practical option that can work for all users now, and provide programmatically-determined functionality (eg in-situ replacements) in future software/hardware.
  • The use case assumes that being invisible is a desirable requirement, and that only blind users need long descriptions of images. Other users, including people with cognitive disabilities and foreign students who are not native language speakers could also benefit from being able to access long text alternatives.

Describing etext Images

  • This does not appear to be a valid use case.
  • It's unclear why a repository would require non-technical contributors to attempt to use the longdesc attribute, whether the repository system does actually publish the longdesc code and so could easily be adapted to use a different publishing pattern, or why alternative techniques like using a figure element with a link to the long description in the figcaption, or a link on the image optionally with rel=longdesc would not work as well or better.
  • Providing long descriptions in Digital Text Books does appear to be a potential use case for providing an in-situ replacement of the image with a text alternative; but given the poor support for longdesc currently available, a progressively enhanced solution like using rel=longdesc on a normal link on the image appears to be a more robust solution that can be used now, and still support programmatically-determined functionality in the future if required.

Describing a Newspaper Image

  • 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"
  • A lightbox function could provide a link to the full article on the lightbox image using a normal link with rel=longdesc, or within a figcation at the bottom of the lightbox, or with a normal link associated with the image using aria-describedby.
  • There are no in the wild examples for this use case.

Details

No change to the spec.

Impact

Positive Effects

  • Authors will use other techniques they are already familiar with (e.g. a normal descriptive text link, or a link on the image) optionally progressively enhanced with AT-specific markup (e.g. aria-describedby or rel="longdesc") if required. These techniques still work when authors get the AT-specific markup wrong.
  • Authors will avoid making the mistake of providing the long description text in the longdesc attribute value instead of a link.
  • Authors will only have to learn one generally applicable technique like aria-describedby if they need to programmatically tie their long text alternatives to other elements like images, tables and SVG.
  • Users will not have to upgrade their software or receive additional training just to get access to long descriptions: progressive enhancement of normal links ensures no one is locked out.
  • Long descriptions using rel=longdesc or aria-describedby will be available to everyone right now, while still supporting in-situ replacement in future user agents where this could be useful like DTB.
  • HTML5 will send a clear message that longdesc cannot be relied on to provide long descriptions, as most developers and accessibility practitioners already know, and that the time has come to move on to more perceivable and robust solutions for providing long descriptions like aria-describedby and rel=longdesc.

Negative Effects

  • None

Conformance Classes Changes

No change to spec.

Risks

  • Obsoleting longdesc may be perceived by parts of the web community as removing accessibility, instead of replacing a failed technique with better techniques.
  • People who are unaware that the current spec still requires implementations to expose longdesc to Assistive Technologies may perceive this as breaking back compatibility.
  • The W3C Web Accessibility Initiative (WAI) may need more time to get its WCAG2 techniques and Education and Outreach ducks in order. But anyone actually using longdesc today must accept that it has limited support, independent of what W3C accessibility advice says.
  • Teachers, Documentation specialists and "regulators" (people setting organisational or corporate policies as well as governments) who rely on W3C accessibility advice may be discombobulated to learn that longdesc has never been a reliable technique for providing long descriptions.

References

  • Links included inline.

Contributors

Matt Turvey mcturvey@gmail.com