[w3c-wai-wg] <none>

Some proposed HTML extensions from Greg Lowney at Microsoft.

For WAI consideration.  (ps he is out for the next two weeks)

I'll include these as notes in the compilation I'm trying to find time to finish up reflecting everything at the meeting... (and what has happened since - as notes)

(Word doc attached is a formatted copy of this.)

Gregg Van


HTML Extensions for Accessibility
Gregory C. Lowney
Senior Program Manager
Accessibility and Disabilities Group
Microsoft Corporation
August 3, 1997
Executive Summary
This document proposes five extensions for HTML that would let authors create HTML documents that easily translate into other formats, especially those that enable access for people with certain types of disabilities.
The proposals fall into two categories: (a) ways to allow authors to provide hints about how to order the document content for different renderings, and (b) ways to allow the author to provide customized appearance without sacrificing the standard tags and the structural information they provide.
The specific recommendations are (1) orientation of tables, (2) hand-tuned ordering of document elements when rendered for different output formats, (3) customized bullet images for unordered list item, (4) customized appearance of buttons, and (5) invisible fieldsets.
Several proposals are in the early design phase, and are provided as a starting point for discussion.
There are many other potential enhancements to HTML that would benefit accessibility. This document is not a comprehensive list, but merely presents a few options currently being considered. 
Goals
This document proposes five extensions for HTML that would let authors create HTML documents that easily translate into other formats, especially those that enable access for people with certain types of disabilities. 
These recommendations are based on the author's experience in creating a filtering system that produces "universal versions" of arbitrary Web pages. These universal pages generally contain the same content, but are formatted to present the information in ways that are more accessible. (The filter is described on http://microsoft.com/enable/about.htm,) The recommendations directly address difficulties in performing this operation on a wide range of existing Web pages.
The following enhancements let authors provide information about how to order document elements when rendering the page in alternate forms:
* ORIENTATION: an attribute for tables that provides information about the order in which the contents of the table should be read.
* CUSTOM ORDERING: constructs allow the author to provide hand-tune the order in which document elements should be presented when rendered for different output formats.
The following enhancements let authors provide customized appearance without sacrificing the standard tags:
* LIST IMAGES: the ability for the author to provide an image that should serve as the bullet for an unordered list item. This allows authors to display customized appearance without sacrificing the LI tag and the structural information it provides.
* CUSTOMIZED BUTTONS: allow authors to present buttons with entirely customized appearance. This allows authors to display customized appearance without sacrificing the BUTTON tag and the standardized information it provides.
* INVISIBLE FIELDSETS: make it easy to use FIELDSET for grouping purposes without interfering with the normal visual presentation. This will allow grouping of items for the purpose of aural output.
Several of the proposals (custom ordering and invisible fieldsets) are in the early design phase, and are provided as a starting point for discussion.
There are many other potential enhancements to HTML that would benefit accessibility. This document is not a comprehensive list, but merely presents a few options currently being considered. 
Ordering Information for Different Renderings
In some cases it is most necessary or beneficial to change the order in which elements are presented when the document is rendered in different formats. (Such formats include purely aural output for people who are blind or in eyes-free situations, and simplified HTML designed to make sense when read serially by older blind-access utilities that don't have direct access to the structural information in the document.) This ordering often needs to be hand-tuned to be most effective. The following extensions are designed to allow authors to add such hints in a standardized fashion.
Table Orientation
In most cases we don't need additional information to read tables in the proper order. The utility interpreting the table can often infer the proper order of simple from the presence of TH tags, or when the contents of certain cells are bold or end in colon. However, I believe that there are a significant number of cases-including complex or "abused" table-where more information is needed.  I proposed an ORIENTATION attribute for tables, which I distributed in email during 1996. It is described in more detail in the attached document.


Customized ordering and filtering for different presentations
Sometimes the order in which things appear should vary depending on the media or options. I've run into this in building the filter that makes the accessible version of my public web site. For example, the toolbar often comes at the top of the normal page, but should come at the bottom of the page when it is being presented aurally, so the user doesn't have to wade through the same junk on every page before they get to the real contents.  In my table orientation proposal I suggest a way to deal with this when you want to read a table in non-default order, but that is not always enough of a solution.  For example, you may have three table rows with the first being the toolbar, and want to read them in the order 2, 3, 1.  Is there any way to put in hints as to a preferred ordering?  
My filter uses comment tags following a private convention.  The following proposals would define a standard for providing such hints.
Simple Solution: Single Index Ordering
I could imaging putting INDEX=<number> onto almost anything, where the INDEX values define the order in which objects within the parent container should be read when serialized. This would be used for speech output and for turning out an ASCII text, Braille, or simplified HTML version of the Web page. Thus one could set index values to force table rows or columns to be read in a hand-tuned order. It could also be used on DIV or FIELDSET to change the order in which arbitrary blocks of HTML are read.
General Solution: Multiple Orderings by ID
Caution: this section is not yet thought out as well as the others, and still needs discussion with HTML experts to find out how media-specific style sheets might apply toward this goal.
This is a more general solution, which would allow the author to define any number of alternate presentations, specifying which elements should appear in each and the order in which they should appear. Ordinarily the browser would ignore these and, as today, use the order of elements in the source as the presentation order. However the browser or translation tool could choose to use the order defined for any of the alternate presentations included in the document. 
We would define a standard set of presentation types, including voice-output and serial-html. Any number of PRESENTATION blocks could be allowed anywhere in the document, or they could be restricted to the HEAD section. Within a PRESENTATION block, ELEMENT tags are used to reference blocking or non-blocking elements within the document. The order in which they are referenced within the PRESENTATION block defines the order in which they are rendered in that particular presentation.
Example:
<HEAD>
<PRESENTATION TYPE="serial-html">
	<ELEMENT NAME="content">
	<ELEMENT NAME="text-toolbar">
	<ELEMENT NAME="text-navbar">
	<ELEMENT NAME="footer">
</PRESENTATION>
...
</HEAD>

<BODY>

<DIV ID="toolbar"> <!-- navigation bar goes here --> </DIV>
<DIV ID="navbar"> <!-- main content goes here --> </DIV>
<DIV ID="content"> <!-- credits goes here --> </DIV>
<DIV ID="footer"> <!-- navigation bar goes here --> </DIV>

<COMMENT
The following are hidden in the default presentation by the style sheet, and so their position in the document is irrelevant. 
</COMMENT>
<DIV ID="text-navbar" CLASS="text-only"> <!-- alternate navigation bar goes here --> </DIV>
<DIV ID="text-toolbar" CLASS="text-only"> <!-- alternate toolbar bar goes here --> </DIV>

</BODY>

Customized Appearance of Standard Elements
The structural information provided by standard HTML tags allows tools to convert the document to alternate presentations. These include converting the document into Braille, or reading it aloud to users who are blind or operating in eyes-free situations. Today, HTML authors who want to customize the default appearance of the page often need to avoid using the standard tags, and so this structural information is lost. The following recommendations would allow authors to customize the appearance of their document while still using standardized tags.
Image attribute for List Items
A minor enhancement would be to support SRC attribute on LI tags. This would allow the author to provide a image to represent the bullet, yet still use the LI tag to provide the accompanying structural information.
This first proposed syntax is very flexible, allowing the author to use a full-featured IMG tag to represent the bullet. The ID attribute on the IMG tag is referenced by the new BULLET attribute on the LI tag.
<IMG ID="bullet1" SRC="redball.gif" HEIGHT=20 WIDTH=20 ALT="*">
<UL>
<LI BULLET="bullet1">This is an example</LI>
</UL>

A second, simpler syntax would simply add a SRC attribute to any LI tag. This would allow the author to provide a image to represent the bullet, but does not allow providing additional information specified on an IMG tag.
Customized Buttons
Provide a way for the author to present buttons with entirely customized appearance. Using BUTTON you can provide an image, but it goes on the face of the button. I would add an attribute that allows hiding the normal 3D border etc., leaving only the image. Ideally the user could provide two images, one for the normal and one for the depressed state. 
In the first possible syntax, the normal button appearance is omitted if the UPSRC attribute is provided. The DOWNSRC attribute is optional.
<BUTTON UPSRC="button1.gif" DOWNSRC="button2.gif" ...>

In the second possible syntax, the author can only provide a single image, using the SRC attribute that is already standardized. Or, the author can provide no image in which case the text enclosed by the starting and ending tags is used. By adding BORDER=0 the normal button appearance is omitted from either option.
<BUTTON SRC="button1.gif" BORDER=0 ...>Press Here</BUTTON>
<BUTTON SRC="button1.gif" BORDER=0 ...>Press Here</BUTTON>

Invisible Fieldsets
The FIELDSET tag provides an easy way to group together controls on a form that are logically related. This relationship can be very useful when reformatting the document. For example, a blind user could be allowed to navigate through groups of options until they find the area that they want to pursue in more detail. As another example, a blind user may better understand the purpose of a "Settings" button when they are told that it is related to "Color" selection control. (That can already be achieved to some extent by providing a more detailed name for the button using the TITLE attribute.) 
However, today FIELDSET is always displayed visually as a grouping rectangle, and in some cases the author will not want to clutter the visual display in this way. They should have an easy way to include an invisible FIELDSET element, which would serve to identify this grouping without altering the visual presentation. 
It may be possible to do this today using the CLASS attribute and style sheets to hide the FIELDSET, but it is considered cumbersome (and may not be entirely effective). A new HIDDEN attribute would be a more convenient method.
Example:
<FIELDSET HIDDEN TITLE="Color Options">
<INPUT ....>
<BUTTON ....>
</FIELDSET>

[end of document]






Gregg 

-- ------------------------------
Gregg C. Vanderheiden Ph.D.
Professor - Dept of Industrial Engineering
Director - Trace R & D Center
s-151 Waisman Center
University of Wisconsin- Madison  53705
mailto:gv@trace.wisc.edu,    WWW & FTP at  Trace.Wisc.Edu
for a list of our Listserves send "index" to listproc@trace.wisc.edu