- From: Al Gilman <asgilman@access.digex.net>
- Date: Mon, 13 Oct 1997 18:11:58 -0400 (EDT)
- 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
progress.
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
Overview
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.
Status:
Consensus
* Some of the TABLE recommendations, will be a significant help with
this problem. In particular, browser functions to list the table
contents.
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.
Status:
Consensus
* 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.
Status:
Consensus
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
help.
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
caption.
* 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.
Status:
Consensus
* 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
equivalent).
* 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
links.
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
Status:
Consensus
* 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.
References
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