W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 2005

Issues summary for Guideline 1.1 (html)

From: Wendy Chisholm <wendy@w3.org>
Date: Mon, 10 Jan 2005 18:53:37 -0500
Message-ID: <41E31581.40907@w3.org>
To: wai-gl <w3c-wai-gl@w3.org>
The summary of the 28 issues for Guideline 1.1 is attached as an HTML 
document and included as text below.  I've grouped the issues into the 
following 5 groups:
Close without action,
Adopt proposal and close,
Requires further action or discussion,
Needs clarification from the reviewer,
Elephants.

Best,
--wendy

                           text-equiv issues summary

   [1]Guideline 1.1 (text-equiv) issues.

      [1] http://trace.wisc.edu/bugzilla_wcag/issuereports/text-equiv_issues.php

Overview of issues

     * [2]Close without action
          + 170, 373, 664, 665, 791, 890, 951, 1004, 1024, 1078, 1082
            (although we should discuss first), 1232, 1321, 1322
     * [3]Adopt proposal and close
          + 404 - new examples,
          + 437 - slight change to example title,
          + 588 - addition to first benefit,
          + 663 - an additional benefit
     * [4]Requires further action or discussion
          + 587 - wendy repropose definitions of text, non-text content,
            and Unicode,
          + 666 - metadata,
          + 937 - propose that these are techniques for General
            techniques and not for inclusion in the guidelines,
          + 1079 - contains a clarification, but not sure it is an
            improvement
          + 1207 - closing issue 587 should close this issue
     * [5]Needs clarification from the reviewer
          + 1080 - unclear if the reviewer feels a change is needed and
            if so, what should be changed. i.e., not sure how to address.
          + 1104 - unclear where the link is. Believe this is an HTML
            Techniques issue and this is a comment about the "noembed"
            technique.
          + 1138 - unclear how text altneratives can have a higher
            priority when they are (and always have been) highest
            priority.
     * [6]Elephants
          + 895 - provide text alternatives for scripts, applications,
            etc. ala Checkpoint 6.3 from WCAG 1.0? related to baseline
            issue.
          + 1075 - Text alternatives that are not explicitly associated
            are sometimes okay. potential rewording of existing
            criterion.

Close without action

  [7]Issue 170 - accessibility of advertising

      [7] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=170

   Issue: What do we want to require and at what level in terms of
   accessibility for advertising which is pushed onto a web site?

   [8]Notes from 18 Sept 2003 telecon suggest, "The suggestion was that
   sites be allowed to claim conformance even if advertisements did not
   conform as long as the advertisements did not block access to the rest
   of the content." However, that was at a time when we were trying to be
   extremely explicit. More recently, we have decided to provide the
   basics (with broad caveats where necessary), but to leave the
   case-by-case issues to policy makers. Also, Level 1 success criteria
   in Guideline 1.1 is written in such a way that if the developers of a
   site feel that ads are functional, they can provide a label. If ads
   are something that can be skipped, mark it so that it can be ignored.

      [8] http://lists.w3.org/Archives/Public/w3c-wai-gl/2003JulSep/0569.html

   Propose: No change. Close this issue.

  [9]Issue 373 - add using text-to-speech to 1.1 benefits

      [9] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=373

   In a previous version, the first benefit said, "...have the text read
   aloud to them" which could be interpreted as, "read by a person." The
   issue is a request to clarify that it is read through speech
   synthesis.

   The 19 November draft says, "People who are blind, have low vision,
   have cognitive disabilities or have trouble reading text for any
   reason can have the text read aloud to them by assistive technology."
   The phrase, "by assistive technology" should clarify this issue.

   Propose: No change. Close this issue.

  [10]Issue 664 - importance of text description of visual appearance of images
  used buttons

     [10] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=664

   The comment is specific to a previous version of Example 1. The
   reviewer believes it is "important to provide a textual description of
   the appearance of an image used to represent a button in order to
   allow effective communication between a person using the textual
   description and a person using the visual presentation. For example,
   it poses a significant problem when a person who is blind tells a
   coworker to click on the "delete button" when the sighted user sees a
   picture of a garbage can-and vice versa."

   Propose: Close this issue. Respond to the reviewer that a text
   alternative fulfills our purpose which is to ensure that the content
   is perceivable and usable to someone with a disability. How they use
   that information to interact with others should be their
   responsibility.

  [11]Issue 665 - a screen reader might read...

     [11] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=665

   Several comments on a previous example. Significant changes were made
   to the 19 November draft to provide a clearer example.

   Propose: Close this issue.

  [12]Issue 791 - Benefits - first benefit is not applicable to this guideline

     [12] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=791

   The reviewer says that Guideline 1.1 does not benefit people who have
   difficulty reading text and that the first benefit should read,
   "People who are blind, have low vision, or have cognitive disabilities
   can have the text read aloud to them by assistive technology."

   Some people with reading disabilities use tools that both read text
   aloud and highlight the words being read. Wouldn't it be confusing if
   their tools read, "image" for images? Part of someone's reading
   disability could be the inability to recognize visual information in
   general. Therefore, they might need assistance determining the purpose
   of the non-text content.

   Propose: no change. close issue.

  [13]Issue 890 - Clarification for border and spacer images

     [13] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=890

   The primary theme of the reviewer's comment (about the 11 March 2004
   WD) is that "This guideline does not seem to leave any room for a null
   alt attribute." Recent drafts include the new criterion: "Non-text
   content that does not provide information, functionality, or sensory
   experience is marked such that it can be ignored by assistive
   technology."

   Propose: no change. close issue.

  [14]Issue 951 - Ease of access

     [14] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=951

   Reviewer says, "This checkpoint states a requirement for
   text-equivalent content, but it is also important to stress the need
   for <em>ease of access</em> to this content."

   Propose: This is a user agent issue. Close the issue, no changes.

  [15]Issue 1004 - Clarifications for 1.1, level 1 criterion

     [15] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1004

   Proposals from September should address the issues. Were incorporated
   into 19 November draft.

   Propose: close the issue.

  [16]Issue 1024 - Text alternatives should be meaningful

     [16] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1024

   Another request for clarifying "null alt-text" which is covered by,
   "Non-text content that does not provide information, functionality, or
   sensory experience is marked such that it can be ignored by assistive
   technology."

   Propose: Close this issue.

  Issue 1078 - duplicate of 1075

   duplicate.close.

  [17]Issue 1082 - A success criterion is needed that covers when a large
  amount of text is needed to ensure equivalency.

     [17] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1082

   Reviewer says that to provide long descriptions of non-text content
   (e.g., a chart - you may have an entire page of description) and you
   may want to include it on the same page, not via longdesc
   (html-specific). However, the current wording of the success criterion
   wouldn't allow in-page description because the text alternative must
   be explicitly associated with the non-text content.

   The reviewer proposes:

     "Each instance of non-text content has at least one text
     alternative of fewer than 150 characters that is explicitly
     associated it...."

     and adding another Level 1 success criteria: "Text alternatives of
     more than 150 characters are provided either inline or via an
     adjacent text link."

   There are several issues with the proposal:
    1. It is English specific.
    2. 150 is either arbitrary or influenced by an existing tool.
    3. It is HTML specific. Other technologies do not provide multiple
       ways to associate text alternatives and it is the goal of the
       XHTML WG that img will be replaced by something more generic (ala
       object) so that any object can be embedded in the same way (this
       goes back to the original discussions of img and reactions to
       [18]Andreesen's proposal and subsequent proposals about a "fig"
       element to include figures.)

     [18] http://www.webhistory.org/www.lists/www-talk.1993q1/0182.html

   The Techniques Task Force has been wrestling for months with [19]a
   test for short alt-text and have been unable to resolve the issue.
   Perhaps a discussion by the WCAG WG will shed light, but it seems like
   a rat hole.

     [19] http://www.w3.org/WAI/GL/WCAG20/tests/test3.html

   I believe that the existing success criterion say that the text
   alternative should be as long as needed to satisfy the criterion.
   Then, it is up to technology-specifics to determine if it is long or
   short.

   Propose: no change. close.

  [20]Issue 1232 - Issue Summary for guideline 1.1 (text-equiv)

     [20] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1232

   voila!

  [21]Issue 1321 - Alt text for graphics should be lower priority

     [21] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1321

   The reviewer writes:

     it is my opinion that using Alt tags for graphics, should be a
     Priority 2, or 3 as I've run into too many companies/businesses
     that think just because they have alt tags on their images that
     their site is accessible. And they don't have to do anything more
     to achieve true accessibility.

   While some organizations do not understand the breadth of techniques
   for making content accessible, if alt-text is moved to level 2 or 3 it
   is less likely to be implemented and it doesn't mean that people will
   shift their focus to other techniques. Instead, the web community
   needs to better educate developers about the wide range of techniques
   that are needed to make content accessible.

   Propose: Decline. Close this issue.

  Issue 1322 is duplicate of 1321.

   Close.

Adopt proposal and close

  [22]Issue 404 - More examples for text-equiv checkpoint

     [22] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=404

   Requests to clarify 1.1 via examples, particularly null alt-text.

   There are currently 5 examples for Guideline 1.1:

   Success Criteria Corresponding Examples
   Level 1 #1 - For all non-text content that is functional, such as
   graphical links or buttons, text alternatives identify the purpose or
   function of the non-text content.

   [Existing] Example 1: an image used as a button.
   A magnifying glass icon is used to link to the search page of a Web
   site. A screen reader identifies the button as a link and speaks the
   text alternative, "Search."
   Level 1 #2 - For all non-text content that is used to convey
   information, text alternatives convey the same information.

   [Existing] Example 2: a data chart.
   A bar chart compares how many widgets were sold in June, July, and
   August. The short label says, "Figure one - Sales in June, July and
   August." The longer description identifies the type of chart, provides
   a high-level summary of the data comparable to that available from the
   chart, and provides the data in a table.
   Level 1 #2 - For all non-text content that is used to convey
   information, text alternatives convey the same information.

   [Existing] Example 3: a recording of a speech
   The link to an audio clip says, "Chairman's speech to the assembly." A
   link to a text transcript is provided immediately after the link to
   the audio clip.
   Level 1 #3 - For non-text content that is intended to create a
   specific sensory experience, such as music or visual art, text
   alternatives identify and describe the non-text content.

   [Existing] Example 4: a recording of a symphony.
   The link to an audio file says, "Beethoven's 5th Symphony performed by
   the Vienna Philharmonic Orchestra."
   Level 1 #2 - For all non-text content that is used to convey
   information, text alternatives convey the same information.

   [Existing] Example 5: an animation that illustrates how a car engine
   works.
   An animation shows how a car engine works. There is no audio and the
   animation is part of a tutorial that describes how an engine works.
   All that is needed is a description of the image. From "How car
   engines work: Internal combustion"
   Level 1 #4 - Non-text content that does not provide information,
   functionality, or sensory experience is marked such that it can be
   ignored by assistive technology. [Proposed] Example 6: a pair of
   images used to create a visual effect.
   Two images are used to create curved edges on a "tab" interface. The
   images do not provide information, functionality, or a sensory
   experience and are marked such that they can be ignored by an
   assistive technology.
   Level 1 #5 - Any text alternatives are explicitly associated with the
   non-text content. There are issues with this criterion. Propose that
   we do not create an example for it since it would be
   technology-specific.
   Level 1 #6 - For live audio-only or live video-only content, such as
   internet radio or Web cameras, text alternatives describe the purpose
   of the presentation or a link is provided to alternative real-time
   content, such as traffic reports for a traffic Web camera [Proposed]
   Example 7: an internet radio station.
   A radio station broadcasts over the internet. The station's Web site
   describes the type of music played, a schedule of the shows, and the
   "current song" is updated each time the DJ starts a new track.
   Interviews are recorded and published in the archives. Transcripts of
   the archived interviews are provided ala Guideline 1.2. [@@ expect
   this will be controversial. Also, I'm describing a typical internet
   radio site, not necessarily all of the things needed to make it
   accessible. May be confusing.]

   [Proposed] Example 8: a traffic Web camera.
   A Web site allows end-users to select from a variety of Web cameras
   positioned throughout a major city. After a camera is selected, the
   image updates every 2 minutes. A short text alternative identifies the
   Web camera as, "TraffiCam." The site also provides a table of travel
   times for each of the routes covered by the Web cameras. The table is
   updated every 2 minutes.

   Did not propose examples for criteria other than Level 1 since only
   other criterion is level 3 and is real-time captioning.

  [23]Issue 437 - Interpretation of Example 4

     [23] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=437

   The reviewer misinterprets what was example 4 (now is example 3: a
   recording of a speech) thinking that it was a video recording, when it
   is only an audio clip. Therefore, since it is only audio it doesn't
   need captions and a transcript is the appropriate solution (as
   described in the example).

   Propose: Change the "title" of this example from "a recording of a
   speech" to "an audio recording of a speech (no video)" and close the
   issue.

  [24]Issue 588 - addition to first benefit under 1.1

     [24] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=588

   Add "...or otherwise transformed to different presentation format
   (e.g. font, text size)" to the first bullet under Benefits.

   Propose: Accept the edit so that the first benefit reads: People who
   are blind, have low vision, have cognitive disabilities or have
   trouble reading text for any reason can have the text read aloud to
   them by assistive technology or otherwise transform the presentation
   of the text to meet their needs (e.g., change the font face, the text
   size, or the background and foreground colors).

  [25]Issue 663 - additional benefits for 1.1

     [25] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=663

   The reviewer proposes eight additional benefits for guideline 1.1 that
   are not accessibility-related but demonstrate how providing text
   altneratives can have additional benefits. Instead of providing such a
   detailed list, propose a benefit that summarizes the additional
   benefits and that general techniques will either link to a resource
   that describes additional benefits in more detail or include a more
   thorough discussion.

   Propose: Add another benefit: Additionally, text alternatives support
   the ability to search for non-text content and to repurpose content in
   a variety of ways.

Requires further action or discussion

  [26]Issue 587 - definition of text equivalent

     [26] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=587

   Comment about the definition of text equivalent,

     This is not a definition. I would first define "text" as code
     representing written language, that is a one-to-one mapping of
     alphabetic and numeric symbols. Then define "text-equivalent" as
     text that serves to communicate substantially equivalent content as
     another representation such as an image.

   While this comment is about the June 2003 draft, we use the same
   definition in the 19 November 2004 draft (although the term has
   changed from "text equivalent" to "text alternative"). The reviewer
   suggests to define "text" and then define "text equivalent." In
   September 2004, I [27]proposed definitions for text, unicode, and
   non-text content (for [28]issue 673). Richard and Martin responded, so
   i [29]proposed a modification. [30]Gregg had a concern about ASCII
   art. We discussed at the [31]09 Sept 2004 telecon.

     [27] http://lists.w3.org/Archives/Public/w3c-wai-gl/2004JulSep/0602.html
     [28] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=673
     [29] http://lists.w3.org/Archives/Public/w3c-wai-gl/2004JulSep/0672.html
     [30] http://lists.w3.org/Archives/Public/w3c-wai-gl/2004JulSep/0605.html
     [31] http://w3.org/2004/09/09-wai-wcag-irc#T20-29-45

   Propose: Action wendy: propose new definitions of text, non-text
   content, and Unicode based on previous discussions. After we agree on
   definitions and close issue 673, propose a definition of text
   alternative based on new definitions of text, non-text content, and
   Unicode.

  [32]Issue 666 - UA support for obtaining textual descriptions and extraneous
  links

     [32] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=666

   The comment is in response to the following phrase from an example "A
   link to a text transcript is provided immediately after the clip."
   Reviewer says that (when supported) metadata should be used to
   associate the link with the content it is the alternative for. This
   relates to the issue about excplicitly linking content with text
   alternatives. It seems more techniquey than a suggestion for a change
   in success criterion. Therefore, not sure what to do with it. Since it
   doesn't require a change in SC - close it? Move it to a general
   techniques issue? Also, it seems related to the metadata SC that Liddy
   and Jutta volunteered to write/propose.

   Propose: discuss. assign an action item to follow-up with Liddy and
   Jutta about metadata.

  [33]Issue 937 - Examples for Guideline 1.1

     [33] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=937

   Comment provides examples/ideas for the level 3 criterion in the March
   2004 WD, "A text document (for example, a movie script) is provided
   that includes all important visual information, dialogue, and other
   important sounds."

   Propose: include these examples in the General techniques. No change
   to guideline.

  [34]Issue 1079 - Clarification of text

     [34] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1079

   Reviewer suggests modifying "Text-alternatives are explicitly
   associated with non-text content..." to "Each instance of non-text
   content has at least one text alternative that is explicitly
   associated with it...."

   Propose: Discuss. Not sure it is better.

  [35]Issue 1207 - clarify that text description is not required

     [35] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1207

   The reviewer requests that we make it clear that a description is not
   neede for every image. Suggests that we might provide clarification in
   the definitions of "text description" or "text equivalent." Think this
   is related to the definition of "text alternative" and that it relates
   to [36]issue 587.

     [36] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=587

   Propose: Closing issue 587 should close this issue.

Needs clarification from the reviewer

  [37]Issue 1080 - Image button alt text should contain same text as the image
  itself.

     [37] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1080

   The reviewer writes (about the July 2004 draft),

     For an image button containing text, the alt text should match the
     text in the image. SC 1a says that for graphical buttons, the text
     alternative should describe the purpose or function of the button.
     Does alt text that matches the text in the image button meet this
     success criteria?

   The wording of SC 1a (now Level 1 Criterion #1) does not say,
   "describe" it says, "identify" the purpose or function. Believe that
   if the alt-text matches the text in the image, it will ususally meet
   the success criterion. There may be instances where more information
   is necessary if markup doesn't help give clue about purpose and if the
   image text is unclear.

   Propose: Ask Andi if she feels this needs a clarification and if so,
   what needs to change? If no change proposed, close the issue.

  [38]Issue 1104 - NOEMBED not widely used or recognized.

     [38] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1104

   Need clarification from Andi. The link after the SC is, "How to
   provide text alternatives for all non-text content." Is this a General
   techniques issue or HTML Techniques?

  [39]Issue 1138 - Higher priority for text alternatives for non-text content?

     [39] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1138

   The reviewer says,

     the Guidelines should place special emphasis, in the form of
     elevated prioritisation, on the following matters already covered:

     - the need to provide a text equivalent for every non-text element

   Text alternatives are Level 1, except for a collated text transcript
   (level 3). Need clarification from reviewer.

   Propose: I have an action to request clarification from the reviewer.

Elephants

  [40]Issue 895 - Propose solution for text alternatives of accessible non-text
  content

     [40] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=895

   Major elephant. Related to baseline discussion.

  [41]Issue 1075 - Text alternatives that are not explicitly associated are
  sometimes okay

     [41] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1075

   Reviewer says, "if a technology doesn't support explicitly associating
   a text alternative with non-text content, it should still be
   conforming to provide a text equivalent another way."

   Potential elephant. Needs discussion and likely someone to volunteer
   to draft a proposal.



-- 
wendy a chisholm
world wide web consortium
web accessibility initiative
http://www.w3.org/WAI/
/--



Received on Monday, 10 January 2005 23:53:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:35 GMT