Publisher requirements for extended descriptions

Status: These requirements have been submitted to ARIA WG [1]

NOTE: These requirements are for all non-legacy user agents.

Publishers require a semantically meaningful way to add rich image and non-image descriptions to HTML. The requirements for that method's internals are listed below:

1. Not restricted to images. (Examples: Google Map with historic overlay, dynamic visualization of data.)
2. Capable of holding full semantic markup: headings, lists, etc.
3. The same method for different types of objects. (Content creators do not wish to use different methods for tables, images, visualizations, 3-D printer plans, etc.)
4. Reusable. (Content creators can link to the same long description from multiple webpages.)
5. Maintaining a connection between the source object and its rich description that is fully unambiguous, where the nature of both source and description are exposed as such to AT and user agent.
6. Offering a large number of very lengthy enhancements in a single page without bloating the size and complexity of the source page.
7. Access to description content:
   1. Description content should not viewable in browser chrome.
   2. The description content should, by default, be invisible on the page.
   3. Description content should be made available to user through AT.
   4. There should be an option to display description content on page on demand.
8. Not dependent on Javascript. Many reading systems do not accept files that contain JavaScript.

Regarding the interaction between that method and user agents/reading systems, our requirements are:

1. Not required to be visible in the HTML. (Examples: Art book, historical reproduction, legally restricted manuscript)
2. Discoverable by screen reader users.
3. Discoverable and available on demand to non-screen reader users (Potential users: magnification users who can't see enough of a map with historic overlay at once to parse the information, ESL student)
4. Skippable by screen reader users.

A brief summation of why some of the proposed solutions will not address these problems,

• anchor tag in the page:
  • Doesn't work on an element which is already a link.
  • No meaningful connection between the source object and its rich description.
  • Changes the visual design.

• SVG:
  • Should be used be for vector graphics, which is a very long way from replacing every photograph, visualization, and dynamic visual application on the Web.
  • ARIA work on SVG is at least 18 months from completion

• longdesc:
  • Useable for ONLY images
  • Potential browser objections

• Describedby:
  • Doesn't allow extended markup.

• Details:
  • Doesn't allow to make pages full of a large number of detailed enhancements without bloat. Use cases given in our original note were a chapter of a biology textbook, and markup of a complex picture book.
  • As currently written, it seems like details would necessarily either change the visual design, or have no meaningful connection between the source object and its rich description.
  • <details> is designed to have expanded detailed information be connected to a visible summary element. It is possible to write a details element, set it to visually hidden off the screen, and then give it role aria-label pointing to the element it describes. This seems error-prone and does not provide access for all users. There would then need to be a way for non-screen reader users to access that offscreen element. Alternately, if a decision is made to hide it from non-screen reader users, then it would need to be keyboard focusable by screen reader users while offscreen, while not reachable with the keyboard by non-screen reader users.
  • Details is not currently supported by all browsers.

Other suggestions include web annotations and components, both of which are too far from completion to consider at this time. Content negotiation may be a viable option, but it does not solve the issue of how the content is marked up.