W3C home > Mailing lists > Public > w3c-wai-hc@w3.org > October to December 1997

status update

From: Al Gilman <asgilman@access.digex.net>
Date: Mon, 13 Oct 1997 18:11:58 -0400 (EDT)
Message-Id: <199710132211.SAA13610@access2.digex.net>
To: w3c-wai-hc@w3.org (HC team)
Cc: jbrewer@w3.org
I have revised the status and plan page.  Please review this carefully
I do believe it is time to take our ideas to the Interest Group.
I hope I have not done too much violence in attempting to characterize
what is agreed and not agreed.  

-- Al

X-URL: http://www.access.digex.net/%7Easgilman/web-access/HC-plan.html

               Plan of Work for HTML4/CSS2 Accessibility Review
   Last revised October 13. 1997; ( [1] previous version)
   This web page provides a guide to the scope of our October 15 report
   to the WAI IG. I have attempted to capture points of consensus and
   characterize points of dispute. Suggested action plans are included
   where we have not reached consensus. You may comment on the suggested
   resolutions on the group email list.
How to use this document

   Monitor [2] http://www.w3c.org/WAI/group/HC/ and
   [3] http://www.access.digex.net/%7Easgilman/web-access/HC-plan.html to
   know the latest state of our work progress and plans.
   Where this document refers to messages in the email archives, please
   take advantage of the thread index to read related discussion before
   and after the cited message.
   Post email to w3c-wai-hc@w3.org to improve the state of our work
   Copy the HC chairs <asgilman@access.digex.net,dd@w3.org> on all
   correspondence in which you are discussing work allocation between
   working groups.
                              Document Prototype
   The following subsections provide a template for the eventual report

   Mission -- Daniel Dardailler on [4] the reason for this Working Group 
   Method -- Dave Raggett on [5] how to get our point across.
Review of the issues

  Preserving the logical reading order of text.
   [6] Example of problems as documented in the TRACE guidelines.
     * Some of the TABLE recommendations, will be a significant help with
       this problem. In particular, browser functions to list the table
    Lacking consensus
     * Explicit markup of elements containing fragments of a text could
       offer some relief in cases not covered by the TABLE proposals. How
       best to do this has not been brought to consensus.
   Suggested resolution (from chair -- Last Call):
     Browser functions to crack tables referred to Browser Guidelines WG
   for refinement.
     Explicit order-of-reading markup of text fragments referred to
   Markup Guidelines working group for consideration. [7]  LINK and META
   enhancements to be implemented in in HTML4 to give them enough
   capability to work with.
   For background, search [8] The HC list archives for "order". Browse
   both quarters; the thread runs over.
  Making [9] SELECT structures with lots of OPTIONs comprehensible.
     * SELECTs with lots of OPTIONS get unwieldy
     * FORMs and particularly long SELECTs are areas where blind users
       have trouble.
    Lacking consensus
     * [10] original proposal
     * [11] OPTGROUP alternative
     * Interleaved marker [12] like LH alternative
     * We should vs. should not propose something which will affect
       algorithms in graphical browsers?
     * This problem is vs. is not a high priority item for the disabled,
       among the things we want to ask browser venders to add
       functionality for?
   Recommended disposition (from chair, Last Call):
     * Take the issue to WAI Interest Group as open, seek clarification
       of criticality and required functionality.
  Making TABLEs comprehensible.
   The [13] baseline operational concept in the HC mail archives should
   be regarded as having a rough consensus of support. The implication is
   that the HTML should contain enough information for browsers to
   perform these functions.
     Browsers which have a function to break tables down to an alternate
   presentation will be a big help. Attention centers on a hierarchical
   list presentation.
     The same transformation does not work for all tables. For example,
   some should be read row-wise, and some Column-Wise. Marking tables to
   [14]  classify them in ways that would aid reading order choices would
     For non-visual browsing, a "probe" or "query cell" capability is
   desirable that draws in information closely related to the cell
   contents in addition reading the cell contents.
     A scope attribute should be added to the TH element to give a
   general indication of what TD cells a TH cell governs.
     The wording in the HTML Spec describing the summary attribute should
   be clearer about how authors should populate it.
    Lacking consensus
     The AXES and AXIS attributes in the current draft address the needs
   of non-visual browse modes and should be incorporated in HTML.
   Alternatively, the needs of non-visual browse modes are not addressed
   unless associations of a cell with
    1. descriptions of the information type of the cell and
    2. conditions under which the current-cell contents are valid
   are distinguished clearly in any markup which attempts to give a more
   semantic view of the information than the table layout gives by
   itself. Recommended disposition (from chair -- Last Call):
     * Seek table reformatting functions from browser providers; refer
       issue to WAI Browser Guidelines group for further work.
     * add [15] SCOPE attribute to TH element.
     * Clarify summary attribute to say that where there is a caption,
       the summary should be written as if it will be said after the
     * address classes of tables (read by columns, read by rows, etc.) in
       the markup guidelines using the existing CLASS attribute. Refer to
       WAI Markup Guidelines group for further development, in
       cooperation with the Browser Guidelines Working Group.
     * Remove AXIS and AXES attributes from HTML4 pending further work by
       WAI FP activity.
     * Implement [16] LINK and META enhancements in HTML4 to support
       experimentation by the WAI activities.
  Improving the effectiveness of inline and offline text associated with images
  and other non-textual objects.
    Background -- for reference: variety of practices integrating image
    descriptions and image alternatives with images in hypertext literature.
    See the GL group area.
    Hypertext [inline] alternative to image when image has multiple sensitive
    regions mapped over it.
   Suggested resolution (from chair -- Last Call):
     * Work with LONGDESC on IMG; normally inlined in the absense of
       image display
     * Include images targeted to FRAMEs
     * OBJECT contents scanned for links with AREA on them which function
       like a MAP entry when the image DATA of the object is displayed.
  Associating HTML contents with external resources.
     * Data publishers may wish to link TABLE to a resource (URL) which
       clarifies data usage in the table.
     * It is not safe to assume that all tables in one HTML document are
       to be associated with the same such data dictionary (or rough
     * Audio output [in general, not just for persons with disabilities]
       will want access to pronunciation dictionaries.
     * Acronyms and foreign languages are other applications for such
    Lacking consensus
     * Whether better to use REL="dictionary" and CLASS="abbreviations"
       or REL="abbreviation-dictionary"
     * Whether the capability to indicate this is needed in HTML or
       whether RDF will eliminate the need to so mark the HTML.
   Recommended resolution:
     Seek review from RDF group
     Implement at least enough LINK and META enhancements to ensure that
   dictionaries, including data dictionaries, can be TARGETed to an
   arbitrary HTML container element.
  Image used as list bullet
     * images so used should have textual alternatives.
    Lacking consensus
     * All images should be in HTML, no images should be applied as part
       of a style
   Recommended disposition (from chair -- Last Call):
     * No change required to HTML.
     * Continue work with CSS group in Markup Guidelines activity of WAI.
  Range of MEDIA values
   Recommended disposition (from chair -- Last Call):
     * add another top-level media type named either CONSOLE or TTY
     * change wording around list of predefined MEDIA values to make the
       list extensible. A browser _may_ ignore media indications that do
       not match this list.
     * Refer further work on how browser should handle this to browser
       guidelines group
  Controlling dynamic features
   Gregg Vanderheiden copied over a good summary by Kelly Ford. For more
   information search the webwatch-l digest archive for related posts.
   Recommended disposition: Refer to Browser Guidelines and Markup
   Guidelines for further consideration.


   1. http://www.access.digex.net/%7Easgilman/web-access/plan2.html
   2. http://www.w3c.org/WAI/group/HC/
   3. http://www.access.digex.net/~asgilman/web-access/HC-plan.html
   4. http://www.w3.org/WAI/group/HC/callhc.txt
   5. http://lists.w3.org/Archives/Public/w3c-wai-hc/1997JulSep/0057.html
   6. http://trace.wisc.edu/text/guidelns/htmlgide/htmlgide.htm#layout.tables
   7. http://lists.w3.org/Archives/Public/w3c-wai-hc/1997OctDec/0063.html
   8. http://lists.w3.org/Archives/Public/w3c-wai-hc/
   9. http://lists.w3.org/Archives/Public/w3c-wai-ig/1997JulSep/0031.html
  10. http://lists.w3.org/Archives/Public/w3c-wai-ig/1997JulSep/0031.html
  11. http://lists.w3.org/Archives/Public/w3c-wai-hc/1997OctDec/0020.html
  12. http://lists.w3.org/Archives/Public/w3c-wai-hc/1997OctDec/0057.html
  13. http://lists.w3.org/Archives/Public/w3c-wai-hc/1997OctDec/0003.html
  14. http://www.w3.org/WAI/group/FP/table.txt
  15. http://lists.w3.org/Archives/Public/w3c-wai-hc/1997JulSep/0065.html
  16. http://lists.w3.org/Archives/Public/w3c-wai-hc/1997OctDec/0063.html
Received on Monday, 13 October 1997 18:12:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:35:00 UTC