WAI-CG Consensus Recommendations on Alternative Text in HTML 5

Wed, 10 Jun 2009 18:32:08 -0700 

Dear Colleagues:

Attached herewith, at long last, is a report we've titled: "WAI
CG Consensus Resolutions on Text alternatives in HTML 5." It is
the result of many long teleconferences and draft documents produced by
members of several WAI Working Groups--and accepted as a consensus
position by the WAI-CG itself. We regret that our process took so long,
but we did do our best to be comprehensive. We believe we've addressed
all of the major concerns and requirements that have been expressed on
behalf of @alt. We hope this report can now serve as a useful basis for
wider consideration, especially with the HTML WG.

This document is also available at the following URI;
http://www.w3.org/2009/06/Text-Alternatives-in-HTML5

We look forward to working with you to make HTML 5 the best
accessibility solution yet.

Janina Sajka,   Phone:  +1.202.595.7777;
                sip:[email protected]
Partner, Capital Accessibility LLC      http://CapitalAccessibility.Com

Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada
Learn more at http://ScreenlessPhone.Com

Chair, Open Accessibility       [email protected] 
Linux Foundation                http://a11y.org

Chair, Protocols & Formats
Web Accessibility Initiative    http://www.w3.org/wai/pf
World Wide Web Consortium (W3C)
Title: WAI CG Consensus Resolutions on Text alternatives in HTML 5

WAI CG Consensus Resolutions on Text alternatives in HTML 5

A Report of the WAI-CG Task Force on Alternative Text
Task Force Facilitator: Janina Sajka, PFWG Chair
Date: 10 June 2009

About This Task Force

This report provides WAI consensus recommendations for alternative text support in HTML 5. On January 14, 2009 the WAI-CG created a Task Force on Alternative Text, to consider the various alternative text approaches discussed over the past few years, and to develop consensus WAI recommendations for appropriate handling of alternative text in HTML5. These recommendations have been reviewed by the following WAI Working Groups: Authoring Tools Working Group (AUWG), Protocols & Formats Working Group (PFWG), User Agent Working Group (UAWG), and Web Content (WCAG WG).

NOTE: Suggestions for use of elements, attributes, and attribute values are provided in context of those features we currently understand HTML to provide.

Goals

The following background information is provided to help in understanding the specific recommendations below. It can also serve as context and guiding principles should markup solutions that differ from those recommended below be considered.

Context

  • @alt is a very important accessibility attribute (it is supported by all browsers, most authoring tools and is the most well known accessibility technique among authors).
  • Having @alt "required" in HTML 4.01 raised public awareness of Web accessibility in general.
  • automatic validators can detect the presence/absence of @alt but in general cannot certify the correctness of the text string.

Principles underlying the advice below

  1. The working group recommends that HTML5 provide mechanisms for both short and long text alternatives.
    • These are different concepts with different uses and both should be provided as separate functions. Short descriptions are read automatically when the item is encountered. Long descriptions are read only on user request.
  2. A short text alternative (using one of the mechanisms) should be required for validity but the long description should not be required.
  3. We recommend continued inclusion of the alt attribute as one of the valid mechanisms to provide shorttext alternatives.
  4. We recommend aria-labelledby as a second valid mechanism for short text alternatives.
  5. We recommend
    • that HTML5 state that "For guidance on accessibility requirements for text alternatives authors should consult WCAG 2.0."
    • and that HTML should not provide any guidance that conflicts with WCAG.

Specific recommendations regarding Short Text Alternatives

NOTE: These recommendations assume that ARIA features referenced in this document are included in HTML 5.

  1. <img> is only valid when at least one of the following is true:
    • @alt is present (empty or non-empty) OR
    • @aria-labelledby is present (non-empty only) OR
    • the <img> is located within a <figure> that has a non-empty <legend> OR
    • @role="presentation"
    NOTE: The intent here is twofold.
    1. to allow different methods to be used for providing short text alternatives (e.g. ALT or LABELLEDBY or LEGEND)
    2. to note that short text alternatives are not needed for content that is "presentational" as defined by ARIA
  2. That
    • the proper use of @role="presentation" be taken from ARIA 1.0
    • and that an <img> without a @role attribute is assumed to be the equivalent of <IMG @role="img"> (and would follow the rules in #1 above)

    NOTE: 'Presentation' should not be defined to be broader than what is defined by ARIA

  3. For cases in which it is appropriate for user agents to ignore the presence of an image (e.g. when the image is used for decoration, for formatting, or when the image is invisible), one or both of the following may be used:
    • @role="presentation"
    • @alt="" (also see (4))

    INTENT: That it is VALID to use either ROLE and/or ALT="" to mark "presentational" content.

  4. alt="" WITHOUT an accompanying role="presentation" triggers a non-critical validator warning recommending use of role="presentation" (but @alt="" remains technically valid)

    INTENT: To encourage the use of role=presentation - by encouraging (but not requiring) its use even when alt="" is used.

  5. We suggest new mechanisms for short text alternatives (e.g. aria-labelledby, <legend>) should be capable of handling structured content. Our primary concern is that short text alternatives be able to supportinline text structure, such as abbreviations, language changes, emphasis, etc.

    RATIONALE: It would be helpful for the short alternative text mechanism to support structured text.

Recommendations regarding Long Text Alternatives

NOTE: Long text alternatives go beyond short text alternatives and allow users (at their request) to get detailed information about non-text content.

  1. Long text alternatives (e.g. aria-describedby ) should not be required for validity (though they may be required by WCAG 2.0 for some types of non-text content).

    RATIONALE: A long text alternative is not always required for accessibility. A short text alternative is often sufficient. So a long text alternative should not be required for validity.

  2. Mechanisms for long text alternatives should be capable of handling structured content.
    • Our primary concern with long text alternatives is that they be able to support block and inlinetext structure, such as abbreviations, language changes, emphasis, tables, headings, etc. However it is not necessarily limited to these and could include rich media types.

    RATIONALE: Current LONGDESC can support structured content. This should not belost with any new mechanisms.

  3. Because we are confident that aria-describedby will be supported by assistive technologies at least as well as longdesc when HTML5 becomes a W3C Recommendation:
    • IF
      • aria-describedby is incorporated in HTML5
      • and aria-describedby allows pointing to long text alternatives that are off of the page (by pointing to a link on the page)
    • THEN
      • we believe it is acceptable to obsolete longdesc in HTML5.

    RATIONALE: It is important that a long text mechanism exist which is capable of pointing off page. Long descriptions are often too lengthy and detailed to be included on the main page. If aria-describedby can point off page (by pointing to a link on the page) then it would remove any need for continued support of LONGDESC which isnot widely used by authors at this time. (NOTE: it is understood that aria-describedby cannot point off page directly.)

Recommendations regarding auto-generated alternative text

We have reached the following consensus concerning "automatically generated" alternative text:
In order to address both the validity and human generation concerns, we do not oppose the creation of 'autogenerated' and 'missing' attributes where either one of these could be used to make an image that does not have any human-generated text alternatives valid. (Note: It is important that this marker is not included in the alternative text string itself.)"

Please refer to Use Case #2 below.

ADDENDUM - Use Cases

We believe some sample authoring workflows will be helpful. Two are provided here.

Use Case 1 (author for whom "alt" is the paramount accessiblity feature)

  1. creates a web page with images
  2. @alt given value when user remembers
  3. in a few cases, the user wants the images to be ignored so he uses alt=""
  4. an accessibility check or validity check before publishing reveals a few missed @alts, the user returns and fixes them
  5. the validity checker suggests the use of role="presentation" in addition to alt="".
  6. the user takes the advice and adds the role="presentation"

Use Case 2 (author using a photo sharing site)

  1. author logs into the photo sharing site
  2. author uses the uploader feature to upload 50 pics of a vacation (XYZ0001.png, XYZ0002.png,..., XYZ0050.png) into an album the author calls "Paris 2009".
  3. a prompt appears asking the author to write descriptive labels for each image to facilitate text searching and access by people with disabilities.
  4. the author logs off without adding individual text alternatives.
  5. the photo sharing site assigns the @alt strings "Photo 1 of 50 of album Paris 2009"
  6. 6. when the author logs back in they still see indicators on the images and/or the album that reminds them that theimages are still lacking descriptive labels.

DISCUSSION:

  • the page will be HTML5_valid because it includes @alt
  • the feature will meet the PROPOSED ATAG2 requirement because the "After authoring session ended" repair used contextual information not available to the user agent.
  • the page will NOT meet WCAG 2.0 because the text alternative does not serve the equivalent purpose

Reply via email to